What is the technical reason why DDP AppleTalk doesn't work with WiFi?

[dougg3]

The "tunnel" exception is for AARP Phase 1 since if they undergo RFC1042 translation (first byte is over 0x600 and thus an EtherType), they are ambiguous with Phase 2 packets when translated back to Ethernet.

Ahh, yeah. I did understand this part of it and the ambiguity, but I guess the pedant in me was thinking the 0x600 rule was also introduced as part of 802.1H. I tried to skim RFC1042 but couldn't figure it out. Might be due to my lack of familiarity with Ethernet stuff. Either way, it doesn't really matter since it's broken in a lot of equipment regardless...

What I suspect is vendors taking shortcuts somewhere, assuming all traffic bound for Ethernet is going to be Ethernet II frames (since that is all that IPv4/v6 requires) and are just unconditionally cutting off the SNAP header

I definitely agree. Also, here's another link (it's the entire 802.11-2016 standard). See Annex M starting on PDF page 3469. Looks like the 802.11 standard actually includes these same translation tables for IPX and AppleTalk, so it's laid out pretty clearly for the vendors. What a shame that it's not always followed...

 

[cheesestraws]

I'd also note that there are two different documents in this thread, both from the IEEE, which make different statements about what's going on, whereas the mailing list discussion (also on an IEEE mailing list!) I read back in the day said a third thing again - one of the documents above says it's only AARP, one of the documents above says its a general LLC/SNAP problem, and the mailing list posts I found back in the day were talking about it as if it's specifically Phase I / Phase II ambiguity related.

So I'm not sure from the above that anyone knows what's actually going on. Maybe time to get some packet captures...

 

[NJRoadfan]

OK, packet sniffing results are in. Test setup is as followed:
-RPi400 running netatalk connected to WiFi only
-A HP LaserJet printer connected via Ethernet with AppleTalk turned on.
-A desktop connected via Ethernet running WireShark

My WiFi router is having no problems passing DDP traffic. The SNAP packets are being preserved and I see ZIP and RTMP traffic coming over no problem. The problem is... AARP. My Wifi router is unconditionally converting the SNAP packets coming from WiFi to Ethernet II frames (aka EtherTalk Phase I style AARP). It is likely flat out ignoring the header as being less than 0x600, and only seeing that the OUI portion of the SNAP header is 0x00 0x00 0x00 and assuming it is an Ethernet II frame. My next test is a router running OpenWRT and Linux...... we'll see what happens.

 

[NJRoadfan]

Swapping out my main router for a GL.iNet "pocket router" running the latest release of OpenWRT and...... IT WORKS! AARP Phase 2 packets are being moved between WiFi and Ethernet retaining their SNAP headers. The RPi400 running netatalk on WiFi only is being seen by Ethernet connected machines. I can netboot an emulated Apple IIgs from it as well.

 

[cheesestraws]

Good finds!

 

[NJRoadfan]

@slipperygrey might want to note this in the netatalk 2 documentation, although I have only tested one OpenWRT router from one vendor. Others here have used GL.iNet routers without a problem so there is a chance most of their products are AppleTalk compatible.

The good thing is GL.iNet is exclusively using OpenWRT to power their routers. Plus they tend to be pretty cheap and they all support wireless bridge mode if you want to get old Ethernet only Macs (or newer Macs that don't support WPA2) onto your WiFi network.

 

[dougg3]

Nice test results! It does make me wonder about a potential product for people who don't have the ability to change to OpenWRT. A little device with 2 Ethernet ports that just passes all traffic through, but looks for AARP packets that have had the SNAP header stripped off and adds it back while passing the packets through.

Although I'm not sure if it would be worth it since people could just get a different/better router instead...

 

[NJRoadfan]

You wouldn't need a separate device. AARP packets are broadcast to all machines on the network, so its likely all you would need is a machine on the same network running a program that intercepts the "wrong" Ethernet II packets and rebroadcasts them with the correct SNAP header. This would break AARP Phase 1, but nobody is running that these days. It would also slightly increase chattiness as any WiFi client broadcasting AARP packets would see its traffic double (the original broken and the fixed packets).

Also, I haven't checked to see if SNAP AARP Phase 2 packets are being transferred correctly from Ethernet to WiFi. I don't see why it wouldn't as the router should see them as LLC/SNAP and leave them as-is.

 

[dougg3]

Ahh, that's an excellent point! That makes sense that it could just be rebroadcast. I forgot that since it's AARP it would be a broadcast.

 

[cheesestraws]

did you get a pcap, by any chance?

 

[NJRoadfan]

pcap of what in particular? The "mangled" packets coming from the WiFi router are formatted as AARP Phase 1 packets with Ethernet II framing.

[Ethernet Source MAC/Dest MAC (12 bytes)]-[0x80 0xF3]-[AARP Payload]

Note: the format of the actual AARP data is unchanged between Phase 1 and Phase 2, only the Ethernet header differs.

 

[robin-fo]

What's actually the difference between ARP and AARP except the EtherType/SNAP discriminator?

 

[NJRoadfan]

There doesn't appear to be much of a difference. Apple followed the ARP packet format when creating AARP and even padded the fields to match. Phase 2 request and probe packets use a specific Ethernet multicast address (090007FFFFFF) while Phase 1 blasts them out to the broadcast address like ARP does.

 

[robin-fo]

Could we have some kind of gateway to translate AARP to ARP and vice-versa to avoid the WiFi issues?

 

[NJRoadfan]

ARP is for IPv4 only.

A gateway that translates the "mangled" packets to the correct SNAP packets is possible, but there are complications if you are using Wi-Fi bridges to connect two Ethernet segments. You would have to run the gateway software on each Ethernet segment since AARP packets would get mangled in both directions traversing WiFi (assuming both bridge devices don't handle the packets correctly). You would have to be careful that your re-transmitted packets aren't reflected back by the other instances of the gateway software on the network. Otherwise you'll DoS your network in short order with a broadcast storm of AARP packets.

 

[NJRoadfan]

To add to the compatible router list, an old Linksys WRT-54G Rev 2 running DD-WRT 2.4 correctly handles AARP Phase 2 packets.

 

[slipperygrey]

@slipperygrey might want to note this in the netatalk 2 documentation, although I have only tested one OpenWRT router from one vendor. Others here have used GL.iNet routers without a problem so there is a chance most of their products are AppleTalk compatible.

The good thing is GL.iNet is exclusively using OpenWRT to power their routers. Plus they tend to be pretty cheap and they all support wireless bridge mode if you want to get old Ethernet only Macs (or newer Macs that don't support WPA2) onto your WiFi network.

This is definitely info that would benefit most netatalk2 users! Do you have a suggestion where to document it? Maybe we can start in the wiki?

 

[NJRoadfan]

Did another test today. This time with two WiFi devices. Pulled out the Powerbook G4 and it can see a netatalk box also connected via WiFi. No surprises here as 802.11 is strictly SNAP packets.

Watching WireShark traffic from the Ethernet side of things I noticed something interesting. It appears that the AppleTalk stack in the HP JetDirect card seems to respond to some of the mangled AARP Phase 2 packets. Its not enough for it to work with the WiFi clients though.

 

[NJRoadfan]

OK, time for some EtherTalk Phase 1 testing. The Kinetics Fastpath 4 has a ROM based routing program that activates whenever the unit is reset or the battery is removed. It only supports Phase 1 on the Ethernet side. The first thing it does when you turn on the Fastpath is spam the network with Phase 1 AARP probes. This information is handy for the 1 (turns Fastpath 4 off) 0 people running EtherTalk Phase 1 over WiFi.

-The Linux based DDWRT passes the test and modifies the OUI in the SNAP header per the IEEE documents.
-The buggy router does straight RFC1042 conversion BUT.... Phase 2 clients on WiFi still ignore the packets. Why? Because Phase 1 AARP packets use the Ethernet broadcast address of FF:FF:FF:FF:FF:FF as opposed to the AppleTalk multicast address.

 

[NJRoadfan]

So I decided to see what happens if you create a wireless bridge between a router that properly supports AARP and one that doesn't. The results were..... interesting, particularly for Phase 1 traffic.

-AARP Phase 1 Packet going from broken access point to working access point: The broken access point converts the Ethernet II based Phase 1 packet to SNAP with an OUI of all 0x00. The working access point retains the header! So you land up with AARP Phase 1 packets with SNAP headers on Ethernet..... oops.

-AARP Phase 1 Packet going from working access point to broken access point: In this case, the working access point gives the Ethernet II based Phase 1 packet a SNAP header with an OUI of 0x00 0x00 0xF8 (As per BTEP). I never see the packet on the other side of the bridge since my broken router doesn't seem to forward these packets to Ethernet.