A2SERVER: support MacIP via macipgw if possible

[IvanExpert]

I gave up on this long ago, but I got an email this week suggesting its viability, so it's well worth re-exploring for those not blessed with an Uthernet card.

[knghtbrd]

I don't have the hardware to accomplish this. If someone wants to lend/give what I need (which at the moment includes a Mac capable of Internet), I'm game to try it. If someone else wants to step in and make it work, I'll be happy to incorporate the patch!

[IvanExpert]

Any functioning A2SERVER setup with any LocalTalk-to-Ethernet bridge should be all the hardware needed. No Mac is required. But at any rate, I'll check this out on my end.

[pneubauer]

I can look at this. Do you have macipgw building on the Pi?

[jasonking3]

Yeah, I have been using it for a couple weeks now with an AsanteTalk bridge and I haven't had to make any changes to the code in that time. I would appreciate if others could give it a try.

https://github.com/zero2sixd/macipgw

[IvanExpert]

Yes, @zero2sixd emailed me, and I'm eager to check it out too. I have to dust off my IIgs and find my bridges and all that. Thanks for doing this!

[pneubauer]

Thanks! I'll try it, but it will take me a bit of time to setup the necessary hardware.

[jasonking3]

OK. I think some of the main issues will be around how to handle the defaults for routing, NAT, etc. Take a look at the readme for some notes on how I set it up for testing.

[knghtbrd]

As my IIgs has pathetically bare RAM, insufficient for Marinetti, so I still can't really help with this just now. At some point I'll need a 4MB card, but cash is right now.

And I thought MacIP would be Mac software as I'd never heard of it before. If it runs right on the Pi, so much the better. I'm still working on baselines for A2CLOUD and Raspple II, but I'd argue A2SERVER is probably in a state that new features are quite doable at this point.

Joseph Sent via mobile

On Oct 26, 2015, at 15:28, Jason King notifications@github.com wrote:

Yeah, I have been using it for a couple weeks now with and AsanteTalk bridge it I haven't had to make any changes to the code in that time. I would appreciate it others could give it a try.

https://github.com/zero2sixd/macipgw

— Reply to this email directly or view it on GitHub.

[IvanExpert]

@zero2sixd, Having difficulty getting macipgw to run. Downloaded latest version, using Debian 7.8.0 i386 (A2SERVER virtual machine running in Virtualbox); typed 'make', and it built without issue. But, when I execute it, no matter what I type, including the example in the Readme, I get "unknown option" followed by usage text. Any ideas? And do you prefer that I file this in the issues section for for your macipgw project?

[jasonking3]

I had that same issue in my initial port to raspbian and I think maybe my fix was a little too quick. The original argument handling in the FreeBSD version wasn't correct for Linux and I made a "quick" fix that worked for me on raspbian, but apparently it's not very generic. I committed some changes just now so that it is using more generic Linux argument handling code. Can you try again?

[IvanExpert]

Will do. In theory Raspbian should be no different than Debian, but theories are theories.

On Oct 28, 2015, at 12:13 PM, Jason King notifications@github.com wrote:

I had that same issue in my initial port to raspbian and I think maybe my fix was a little too quick. The original argument handling in the FreeBSD version wasn't correct for Linux and I made a "quick" fix that worked for me on raspbian, but apparently it's not very generic. I committed some changes just now so that it is using more generic Linux argument handling code. Can you try again?

— Reply to this email directly or view it on GitHub.

[IvanExpert]

Gave it a whirl and it worked this time, with the same issues that I saw before when I tried the FreeBSD VM, which is that Marinetti 3.0b1 configured for MacIP gets a connection, and IP and DNS and gateway all look fine, but I can't actually telnet anywhere, it just waits forever. Almost sweet.

I will try on an actual Mac to see whether it's Marinetti that's broken; if so, I'll try using it with IPNetRouter, or excavate my Gatorbox, to see if it works in any context.

Tested using Windows GSport in a Parallels VM, netbooting from A2SERVER in a VirtualBox VM. Both VM's were bridged to the wired Ethernet interface on a Mac.

On Oct 28, 2015, at 12:13 PM, Jason King notifications@github.com wrote:

I had that same issue in my initial port to raspbian and I think maybe my fix was a little too quick. The original argument handling in the FreeBSD version wasn't correct for Linux and I made a "quick" fix that worked for me on raspbian, but apparently it's not very generic. I committed some changes just now so that it is using more generic Linux argument handling code. Can you try again?

— Reply to this email directly or view it on GitHub.

[jasonking3]

OK. I am using a Mac with System 7.5.5 and AsanteTalk bridge with good results, so the Mac should work. Some things to look at:

• Can you ping or telnet to the .1 address of your macip network? This should at least get you to the Linux host.
• Do you see the packets arriving in the debug messages of macipgw? Do they have the right src/dst IP addresses?

[IvanExpert]

Okey doke. I have not tried my classic Mac yet, or even a real GS, but I'm pretty sure I previously tried my real GS with the macipgw FreeBSD-based VM and had the same results. At any rate, I'll try my classic Mac next and go from there.

I don't seem to actually have a usable ping tool on the IIgs, but I am unable to telnet to 192.168.1.1 (MacIP network range, not my LAN range), whereas I'm otherwise able to telnet when I use an Ethernet interface (using the actual address in my LAN range), so it's not the target machine. I see no packets arriving in MacIPgw, so I don't think much is happening.

Next steps will be to verify with real Mac to make sure that macipgw works, and then if that works, I'll try my real IIgs; and if that works, then it's a GSport issue; if it doesn't, then I'll try getting IIgs MacIP going with another MacIP gateway, so we can see whether IIgs MacIP works at all, or whether it's some specific incompatibility between it and macipgw.

If you've got any other suggestions, I'm happy to try.

[jasonking3]

The only other thing I would do is try tcpdump on the Ethernet interface to see if the frames are being sent by the IIgs, just not received by macipgw due to some error in the protocol or implementation. But, that is probably going above and beyond. If I can find the time, I'll replicate what you did and look at the tcpdump trace.

I would be very interested in your results for the Mac, since that is working for me on both a Mac Classic w/System 7 and a PowerBook 5300 w/System 7.5.5.

[IvanExpert]

I can just never remember the syntax for tcpdump. If you provide me with the command, I'll run it. (In the A2SERVER vm, right?)

I'll also report about the Mac.

On Oct 31, 2015, at 12:59 PM, Jason King notifications@github.com wrote:

The only other thing I would do is try tcpdump on the Ethernet interface to see if the frames are being sent by the IIgs, just not received by macipgw due to some error in the protocol or implementation. But, that is probably going above and beyond. If I can find the time, I'll replicate what you did and look at the tcpdump trace.

I would be very interested in your results for the Mac, since that is working for me on both a Mac Classic w/System 7 and a PowerBook 5300 w/System 7.5.5.

— Reply to this email directly or view it on GitHub.

[jasonking3]

After a bunch of work, I tracked this down to an error in the MacIP implementation of Marinetti. This statement from the MacIP IETF draft kind of sums up what is happening:

The implementation SHOULD record the full AppleTalk address returned in the NBP response (including the returned socket) and use it in subsequent transactions with the Server. It SHOULD not simply assume that the Server is on DDP socket 72. However, there are many existing implementations that make this assumption.

Marinetti makes this assumption. macipgw returns that it is listening on port 128 for DDP, but that is ignored by Marinetti and it sends the DDP (w/IP encapsulated) packets to port 72, which promptly drops them. I will look at the feasibility of just using port 72 in macipgw instead of 128. That should fix this problem though their may be others I encounter after that.

[IvanExpert]

Wow, fantastic detective work. If you make this change and it works it could be a huge benefit for IIgs users.

On Nov 4, 2015, at 4:50 PM, Jason King notifications@github.com wrote:

After a bunch of work, I tracked this down to an error in the MacIP implementation of Marinetti. This statement from the MacIP IETF draft kind of sums up what is happening:

The implementation SHOULD record the full AppleTalk address returned in the NBP response (including the returned socket) and use it in subsequent transactions with the Server. It SHOULD not simply assume that the Server is on DDP socket 72. However, there are many existing implementations that make this assumption.

Marinetti makes this assumption. macipgw returns that it is listening on port 128 for DDP, but that is ignored by Marinetti and it sends the DDP (w/IP encapsulated) packets to port 72, which promptly drops them. I will look at the feasibility of just using port 72 in macipgw instead of 128. That should fix this problem though their may be others I encounter after that.

— Reply to this email directly or view it on GitHub.

[IvanExpert]

Also it's possible Andrew Roughan or Ewen Wannop would be able and willing to update MacIP in Marinetti.

On Nov 4, 2015, at 4:50 PM, Jason King notifications@github.com wrote:

After a bunch of work, I tracked this down to an error in the MacIP implementation of Marinetti. This statement from the MacIP IETF draft kind of sums up what is happening:

The implementation SHOULD record the full AppleTalk address returned in the NBP response (including the returned socket) and use it in subsequent transactions with the Server. It SHOULD not simply assume that the Server is on DDP socket 72. However, there are many existing implementations that make this assumption.

Marinetti makes this assumption. macipgw returns that it is listening on port 128 for DDP, but that is ignored by Marinetti and it sends the DDP (w/IP encapsulated) packets to port 72, which promptly drops them. I will look at the feasibility of just using port 72 in macipgw instead of 128. That should fix this problem though their may be others I encounter after that.

— Reply to this email directly or view it on GitHub.

[jasonking3]

It turns out that, while the client MacIP implementation should not assume 72, there are several places in the draft that say the gateway should listen on 72 - so I just made the change and....it worked! I had to enter the IP address, and DNS server manually in the TCP/IP control panel, though I left the gateway IP address set to "Search network".

[IvanExpert]

Psyched that I am that we're so close to this, I am sad to report that I was still unable to get this to fly within GSport (Windows version, in Parallels running on Mac host) netbooting from A2SERVER (VirtualBox running on same Mac host), with both VM's briding to wired Ethernet port. AppleTalk is definitely working ok since it's netbooting, and the TCP/IP control panel finds the MacIP gateway fine (as it did before). I put in the MacIP gateway address for the DNS server; I can try putting in 8.8.8.8 to see if that helps, but this weekend I really plan to conquer lazy mountain and set up my IIgs and classic Mac so I can do some legit regression testing. (There are some timing issues to still resolve in the GSport AppleTalk implementation, remarkable though it is, so I'd like to rule those out.)

Jason, do you want to provide me with an exact line by line of what you're doing (particularly whatever you're starting macipgw with and anything else you're entering into A2SERVER), so that I can ensure I'm not doing something wrong on my end?

[jasonking3]

Hang in there Ivan - at least I know it can work now after my test. My test setup was this:

GSport running in a Linux VM on MacBook Pro (Linux VM running under VMware Fusion, but that shouldn't matter). Ethernet bridged to Thunderbolt Ethernet adapter. I plugged this adapter directly into the raspi with A2SERVER and macipgw installed. (This is where I do all of my development of macipgw.) This setup should work pretty similar to your all-VM setup if both VMs are bridged to the same physical adapter. The main thing will be how to route IP off of your A2SERVER VM, see below.

For the actual configuration of A2SERVER, I don't have to do much other than make sure appletalk routing is enabled with netatalk-router-on. If macipgw starts up and reports that it NBP-registers successfully, then we know that the appletalk stuff is working correctly.

But, you should be able to telnet to 192.168.1.1 at this point assuming your A2SERVER VM actually has telnetd installed and enabled. Please do this as a test because if this doesn't work, then we need to figure out why before doing the work below.

The real issue after this is that, even if macipgw is working correctly, without any further routing/NAT configuration you would only be able to telnet to the .1 IP address used in the macipgw command line. In my case, this would be 192.168.1.1. If you try to telnet to any other address, the telnet client on the IIgs will try to do name resolution and then it needs to reach the DNS server. In my case, I don't have a DNS server running on the raspi, so I point it to 8.8.8.8. So, to make this work on the raspi I a) turn on IP forwarding in the kernel, b) configure the wlan0 adapter to use my home WiFi network and c) NAT traffic originating from the tun0 interface (created by macipgw when you run it) to the wlan0 interface. This requires enabling iptables and using the config in the readme included with the code.

First, let's make sure you can telnet to your A2SERVER VM and then go from there. Make sure that if you're logged into the A2SERVER VM shell, you can telnet to 192.168.1.1 from there (just a local test to make sure telnet is actually working). Then configure the IIgs VM to use MacIP, give it an address of 192.168.1.2, open the telnet application and try to telnet to 192.168.1.1.

Here are some screenshots.

[IvanExpert]

Very helpful, I'll give it a whirl.

On Nov 6, 2015, at 11:12 AM, Jason King notifications@github.com wrote:

Hang in there Ivan - at least I know it can work now after my test. My test setup was this:

GSport running in a Linux VM on MacBook Pro (Linux VM running under VMware Fusion, but that shouldn't matter). Ethernet bridged to Thunderbolt Ethernet adapter. I plugged this adapter directly into the raspi with A2SERVER and macipgw installed. (This is where I do all of my development of macipgw.) This setup should work pretty similar to your all-VM setup if both VMs are bridged to the same physical adapter. The main thing will be how to route IP off of your A2SERVER VM, see below.

For the actual configuration of A2SERVER, I don't have to do much other than make sure appletalk routing is enabled with netatalk-router-on. If macipgw starts up and reports that it NBP-registers successfully, then we know that the appletalk stuff is working correctly.

But, you should be able to telnet to 192.168.1.1 at this point assuming your A2SERVER VM actually has telnetd installed and enabled. Please do this as a test because if this doesn't work, then we need to figure out why before doing the work below.

The real issue after this is that, even if macipgw is working correctly, without any further routing/NAT configuration you would only be able to telnet to the .1 IP address used in the macipgw command line. In my case, this would be 192.168.1.1. If you try to telnet to any other address, the telnet client on the IIgs will try to do name resolution and then it needs to reach the DNS server. In my case, I don't have a DNS server running on the raspi, so I point it to 8.8.8.8. So, to make this work on the raspi I a) turn on IP forwarding in the kernel, b) configure the wlan0 adapter to use my home WiFi network and c) NAT traffic originating from the tun0 interface (created by macipgw when you run it) to the wlan0 interface. This requires enabling iptables and using the config in the readme included with the code.

First, let's make sure you can telnet to your A2SERVER VM and then go from there. Make sure that if you're logged into the A2SERVER VM shell, you can telnet to 192.168.1.1 from there (just a local test to make sure telnet is actually working). Then configure the IIgs VM to use MacIP, give it an address of 192.168.1.2, open the telnet application and try to telnet to 192.168.1.1.

Here are some screenshots.

— Reply to this email directly or view it on GitHub.

[jasonking3]

Actually, I ran into weirdness when I tried the A2SERVER VM in the same setup above, but trying to bridge on a physical adapter of my MacBook. Not sure whether it is the A2SERVER VM or the bridging on the single physical adapter. Maybe let me fiddle with it for a bit before you spend more time on it.

[jasonking3]

Found it. You're compiling the kernel with CONFIG_IPDDP and it does this to the appletalk module:

if defined(CONFIG_IPDDP) || defined(CONFIG_IPDDP_MODULE)

static inline int is_ip_over_ddp(struct sk_buff *skb) { return skb->data[12] == 22; }

I need to receive DDP type 22 for macipgw to function, but with CONFIG_IPDDP enabled, the appletalk kernel module is eating those packets. Just recompile the kernel without CONFIG_IPDDP and it should work.

[IvanExpert]

Slick sharpshooting!

I'm using the stock kernel and AppleTalk module that installs with Debian 7, but I'll try recompiling without CONFIG_IPDDP and see how that improves things. That's something that would be under our control for distributing Raspple II and the VirtualBox VM, though it's obviously a trickier thing for those who wish to run the installer on an existing Linux. I'm gonna give this a whirl now, and also try on Raspbian (I don't know whether that's got CONFIG_IPDDP enabled or not; if so, we can probably request that it be turned off by default).

Ivan.

On Nov 7, 2015, at 6:38 PM, Jason King notifications@github.com wrote:

Found it. You're compiling the kernel with CONFIG_IPDDP and it does this to the appletalk module:

if defined(CONFIG_IPDDP) || defined(CONFIG_IPDDP_MODULE)

static inline int is_ip_over_ddp(struct sk_buff *skb) { return skb->data[12] == 22; }

I need to receive DDP type 22 for macipgw to function, but with CONFIG_IPDDP enabled, the appletalk kernel module is eating those packets. Just recompile the kernel without CONFIG_IPDDP and it should work.

— Reply to this email directly or view it on GitHub https://github.com/RasppleII/a2server/issues/34#issuecomment-154765350.

[roughana]

After iKarith brought it to my attention, I have raised a bug on the Marinetti MacIP LL for the issue identified by zero2sixd - however as a workaround exists I am not pursuing it with any urgency. If this becomes more desirable, please comment on the Marinetti bug to bring it to my attention. I do not monitor this project. And, the source for the MacIP LL is available, so anyone can have a go at this if they wish

[jasonking3]

@IvanExpert, my Raspbian install didn't even have the appletalk module. I used your install instructions for A2SERVER to install that, so we are probably good there. I guess you could do something similar for debian because the kernel itself doesn't really need to be rebuilt, just the appletalk module.

[IvanExpert]

Ok, I have verified that macipgw works! It turns out that it's iffy when running GSport in Virtualbox, and that was part of my problem, but a real GS, and running GSport in Parallels, seems to work fine with A2SERVER on Raspbian.

I think this is fantastic and adds the one capability I've long wanted for A2SERVER. Great work!

So it's all in one place for future , here's exactly what I did after building macipgw and put it in /usr/local/bin: sysctl -w net.ipv4.ip_forward=1 macipgw -d0x111 -n 8.8.8.8 192.168.1.0 255.255.255.0 (in another window): sudo /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE sudo /sbin/iptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT sudo /sbin/iptables -A FORWARD -i tun1 -o eth0 -j ACCEPT

These would need to be made permanent as part of startup to work as part of A2SERVER, of course.

Per the guidance in the macipgw Readme, and the following page: https://github.com/zero2sixd/macipgw/blob/master/README.md http://www.revsys.com/writings/quicktips/nat.html

[jasonking3]

That is great news Ivan. I’m happy to see that you have it working with A2SERVER. It’s been working well for Macs using A2SERVER on Raspbian too.

On Nov 22, 2015, at 2:33 PM, IvanExpert notifications@github.com wrote:

Ok, I have verified that macipgw works! It turns out that it's iffy when running GSport in Virtualbox, and that was part of my problem, but a real GS, and running GSport in Parallels, seems to work fine with A2SERVER on Raspbian.

I think this is fantastic and adds the one capability I've long wanted for A2SERVER. Great work!

So it's all in one place for future , here's exactly what I did after building macipgw and put it in /usr/local/bin: sysctl -w net.ipv4.ip_forward=1 macipgw -d0x111 -n 8.8.8.8 192.168.1.0 255.255.255.0 (in another window): sudo /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE sudo /sbin/iptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT sudo /sbin/iptables -A FORWARD -i tun1 -o eth0 -j ACCEPT

These would need to be made permanent as part of startup to work as part of A2SERVER, of course.

Per the guidance in the macipgw Readme, and the following page: http://www.revsys.com/writings/quicktips/nat.html http://www.revsys.com/writings/quicktips/nat.html — Reply to this email directly or view it on GitHub https://github.com/RasppleII/a2server/issues/34#issuecomment-158811748.

[knghtbrd]

Thanks guys for your help! This is implemented as of b5496b5.

[IvanExpert]

Ha, i just spent he last three hours on a plane implementing it myself. We can compare and see what makes sense.

On Dec 10, 2015, at 9:21 AM, Joseph Carter notifications@github.com wrote:

Thanks guys for your help! This is implemented as of b5496b5.

— Reply to this email directly or view it on GitHub.

[IvanExpert]

Actually, the commit you reference is, I think, my own from the 1.2.7 branch merge. MacIPGW's not in any of those changes yet, so I'm reopening this unless I'm missing something.

[knghtbrd]

My mistake, I thought you said that was in there. This is what happens when you "just wanna clean up some bugs before bed." Thanks for re-opening.

Joseph

[IvanExpert]

@zero2sixd, you were correct about the default on Debian Linux -- IPDDP is enabled in the AppleTalk module, and it prevents macipgw from working. It works on Raspbian out of the box because the that AppleTalk module has it disabled (inadvertently, it turns out, at my request, per: https://github.com/raspberrypi/linux/issues/386).

The installer now downloads a replacement binary for Debian 7 or 8 (x86), and otherwise tries to download source and recompile with IPDDP disabled, in https://github.com/RasppleII/a2server/blob/master/scripts/a2server-3-sharing.txt as of commit https://github.com/RasppleII/a2server/commit/c2bb79860ad8660c3a7b83123a04e1878a94ec62

[knghtbrd]

Can ipddp be disabled by a module parameter? (I haven't looked yet and am not at my computer now), if not can we submit a patch for that?

Joseph Sent via mobile

On Dec 19, 2015, at 09:53, IvanExpert notifications@github.com wrote:

@zero2sixd, you were correct about the default on Debian Linux -- IPDDP is enabled in the AppleTalk module, and it prevents macipgw from working. It works on Raspbian out of the box because the that AppleTalk module has it disabled (inadvertently, it turns out, at my request, per: raspberrypi/linux#386).

This code will recompile and replace the module without IPDDP in Debian. I'm going to work it into the A2SERVER installer (as a last resort if a suitable binary is unavailable from my server) but I'm stashing it here for now in case it is useful.

# recompile AppleTalk kernel without ipddp support for macipgw

sudo /etc/init.d/netatalk stop

kernelVersion=$(uname -r)
kernelMajorMinor=$(cut -d '.' -f 1-2 <<< $kernelVersion)

# kernel module compile adapted from from: http://askubuntu.com/a/338403/288003
sudo apt-get install linux-headers-$kernelVersion
sudo apt-get install linux-source-$kernelMajorMinor
cd /usr/src
kernelSrc=$(find linux-source-${kernelMajorMinor}*)
if [[ ${kernelSrc##*.} == "xz" ]]; then
    xzcat $kernelSrc | sudo tar x
elif [[ ${kernelSrc##*.} == "bz2" ]]; then
    sudo tar jxf $kernelSrc
elif [[ ${kernelSrc##*.} == "gz" || ${kernelSrc##*.} == "tgz" ]]; then
    sudo tar zxf $kernelSrc
fi
cd linux-source-$kernelMajorMinor
sudo make mrproper
sudo cp ../linux-headers-$kernelVersion/Module.symvers .
yes '' | sudo make oldconfig
sudo sed -i 's:^.*IPDDP.*$:# CONFIG_IPDDP is not set:gI' .config
sudo sed -i ':a;N;$!ba;s:# CONFIG_IPDDP is not set\n# CONFIG_IPDDP is not set:# CONFIG_IPDDP is not set:' /boot/config-$kernelVersion
sudo make prepare
sudo make modules_prepare
sudo make SUBDIRS=scripts/mod
sudo make SUBDIRS=net/appletalk modules
sudo cp net/appletalk/appletalk.ko /lib/modules/$kernelVersion/kernel/net/appletalk
sudo depmod
sudo modprobe appletalk

# cleanup
cd
sudo rm /usr/src/$kernelSrc
sudo rm -r /usr/src/linux-source-$kernelMajorMinor
sudo apt-get purge linux-source-$kernelMajorMinor
sudo sed -i 's:^.*IPDDP.*$:# CONFIG_IPDDP is not set:gI' /boot/config-$kernelVersion
sudo sed -i ':a;N;$!ba;s:# CONFIG_IPDDP is not set\n# CONFIG_IPDDP is not set:# CONFIG_IPDDP is not set:' /boot/config-$kernelVersion

— Reply to this email directly or view it on GitHub.

[IvanExpert]

I just looked at the Linux net/appletalk source files and there's no MODULE_PARM in any of them, so I don't think there are module parameters available to disable IPDDP. So we'll have to rely on my implementation (module replacement) for the time being.

As for submitting a patch, I don't have the skills to hack the module, nor am I deeply familiar with the arcana of the Linux submission process, but if someone else wants to do it, go for it. I suppose I could submit an enhancement request for the kernel maintainers if none of us wants to try to implement this.

(I'm going to consider myself done with this issue unless you want me to submit an enhancement request or you specifically request my help otherwise; if that's good enough for you, you can close the issue.)

[knghtbrd]

For reference, Debian's kernel handbook explains how you define kernel module arguments:

http://kernel-handbook.alioth.debian.org/ch-modules.html

Since it doesn't have that option, I suppose that's something we'll want to address at some point in the future. Obviously if it can be configured, there's already conditional support for it in the module. Since there's not an argument, nobody ever thought you'd want to be able to control that particular feature at runtime. Or possibly more likely, nobody cared enough.

[IvanExpert]

Yep, that's what I referenced. I'll leave it to you to decide if you want to leave this issue open, or open a new one, e.g. ("add disable IPDDP argument to AppleTalk module") for the future.

On Dec 20, 2015, at 11:07 AM, Joseph Carter notifications@github.com wrote:

For reference, Debian's kernel handbook explains how you define kernel module arguments:

http://kernel-handbook.alioth.debian.org/ch-modules.html http://kernel-handbook.alioth.debian.org/ch-modules.html Since it doesn't have that option, I suppose that's something we'll want to address at some point in the future. Obviously if it can be configured, there's already conditional support for it in the module. Since there's not an argument, nobody ever thought you'd want to be able to control that particular feature at runtime. Or possibly more likely, nobody cared enough.

— Reply to this email directly or view it on GitHub https://github.com/RasppleII/a2server/issues/34#issuecomment-166132554.

[IvanExpert]

Quick update that as of 1.2.8, Debian 7 and 8 64-bit are also supported with precompiled kernel modules available.

Though I would also mention here, out of lack of anywhere better, that unlike with Debian, you can't easily build a single kernel module on Raspbian, so we had better hope they don't enable IPDDP in its kernel (but I think that's unlikely). Their repo does not offer kernel headers, much to the aggravation of many. You have to get the exact commit for the firmware source via a nonobvious process, clone that, and then do an entire kernel build (hopefully cross compiling on a more capable machine so you can live to see it complete) just so that you can get the Modules.symvers file that would allow you to rebuild a single module. I've done this in the past when needing to provide a specific AppleTalk module to replace a defective or absent one (e.g. in early Raspbian, and later in Linux 3.12), so that's what would be required again should the need arise. I have a page on how at ivanx.com/raspberrypi; perhaps it should be added to a wiki here or something.

[knghtbrd]

I will just say that if someone wants to send either of us ODROID C1+ or better yet XU4 boards, I promise not to protest. ;)

That said, I doubt Raspbian will change their DDP module too much unless someone asks them to. I still think we'd be better off making it a run-time configuration option long-term, but it'll have to be long-term because I don't know offhand who to send a patch to and have an otherwise full plate here anyway.

[IvanExpert]

I'll leave to you to decide whether you want to close this; as far as I'm concerned, MacIPgw has been implemented for Debian and Raspbian and I'm happy.

[knghtbrd]

I think for our purposes, it's fixed. Improving things on the kernel end is outside our scope for the time being. A little documentation for setting it up is all that's needed on our side.