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

[NJRoadfan]

It is common knowledge that one can't natively use the AppleTalk protocol (also known as DDP) over WiFi. The notable exception is very early access points, particularly Apple's AirPort series, had special packet handling to allow it to work. When WiFi became popular, AppleTalk printers were still somewhat common and it was expected to work. Nowadays, not so much.

The common explanation is that EtherTalk Phase 2 uses SNAP packets for data transfer and all WiFi traffic uses SNAP as well and converting to a wired interface screws things up. My question is, what exactly is getting mangled in the packets at the access point? I'm assuming an AirPort equipped Macintosh generate perfectly acceptable AppleTalk packets and the problem happens when the access point translates the packets into wired Ethernet. The reason I'm asking is that open source Wifi access point firmware is a thing (ddwrt, OpenWRT, Tomato, etc.) and fixing this problem might be possible. I know at least one ddwrt supported router (The Linksys WRT54G) apparently supports AppleTalk no problem with its original firmware.

 

[slipperygrey]

I probably can't explain it in any better detail than was a Google search can provide, but I think it has to do with the translation from Ethernet packets to Wi-Fi frames, where if the AP assumes that all packets are Ethernet leads to mangled DDP. Quoting this CNET article from 2009:

The reason this problem (lack of AppleTalk support) manifests with some third-party wireless routers is that certain Ethernet packets (the individual units of data sent over the network) including IP-over-Ethernet use a specific format: 12 bytes of destination and source addresses, plus a two byte "type" field. AppleTalk packets, however, use a "SNAP" frame, which is a slightly different format.

All wireless 802.11 packets, those used by WiFi hardware, are actually SNAP frames.

So, when you have a device connected via wire -- a printer connected via an Ethernet cable, for instance, it is sending regular Ethernet packets. The wireless router then has to translate the packets into SNAP format. In reverse, it has to change SNAP packets back into regular Ethernet packets.

The problem, as they say, is a loss in translation. Some SNAP packets need to be specially handled, or else they will end up mangled and unable to be transferred. Some wireless hardware has problems with this translation process, causing the inability to access wired AppleTalk devices over the wireless network.

 

[cheesestraws]

It is common knowledge that one can't natively use the AppleTalk protocol (also known as DDP) over WiFi

This is common knowledge, but it isn't actually true, at least not in absolute terms. It's more "cheaply made APs assuming that everything is unicast IP and not wanting to put in the effort to make it work properly, and the shortcuts they take with IP mangle other stuff". Plenty of non-Apple APs handle AppleTalk absolutely fine - it's just that enough home-focussed ones don't that you can't rely on it if you're using someone else's wifi (or making a product that will sit on someone else's wifi network). It's much less black and white than a lot of people seem to think.

So it's not that DDP doesn't work on many WiFi routers, it's that everything that isn't IP or part of the IP protocol suite may well not work properly - and even lesser-used bits of that are ropy (see the problems people have had with AirTalk + IP multicast on home routers!).

The common explanation is that EtherTalk Phase 2 uses SNAP packets for data transfer and all WiFi traffic uses SNAP as well and converting to a wired interface screws things up

Part of the problem was that Apple made a subtle design error in how EtherTalk Phase II was implemented. If you have a protocol that has both SNAP and ethertype encapsulations defined for it, you are meant to treat the two as basically interchangeable. IIRC, Apple instead used whether SNAP encapsulation or ethertype encapsulation is used to signal the version of the protocol - Phase I EtherTalk uses ethertypes, Phase II uses SNAP.

This is a problem when you bridge from a network that always uses SNAP to Ethernet, because essentially you lose the version information. EtherTalk Phase I and Phase II frames look the same. But what's worse, if you just follow the "normal" rules for bridging SNAP to Ethernet, guided by the protocol number tables you've downloaded from IANA, when you bridge that back to Ethernet you end up with frames that look like Phase I frames, with an appletalk ethertype.

But it's probably not right to see this as the core of the issue: the core of the issue is "there was no incentive to make it work reliably for AP manufacturers, so they didn't".

The reason I'm asking is that open source Wifi access point firmware is a thing (ddwrt, OpenWRT, Tomato, etc.) and fixing this problem might be possible

I think it's eminently fixable - or the open source firmwares might not have the issue to start with, even. There is no deep technical problem here, as far as I know. If a WiFi router just special-cases IP's ethertype to SNAP and just pass other SNAP packets on verbatim onto Ethernet, Phase II will work fine. And nobody cares about Phase I, right?

 

[NJRoadfan]

So it is lazy programmers making assumptions that everything is IP traffic (again). Basically everyone stuck with Ethernet II frames and is still using them, even IPv6. I haven't tried IPX over WiFi, but I'd bet its busted too. Old routers probably treated IP as an exception (convert to Ethernet II framing) while everything else retained their LLC/SNAP headers.

In theory this means two WiFi clients would be able to communicate with each other over AppleTalk with no issues. Go figure.

 

[cheesestraws]

So it is lazy programmers making assumptions that everything is IP traffic (again). Basically everyone stuck with Ethernet II frames and is still using them, even IPv6. I haven't tried IPX over WiFi, but I'd bet its busted too.

Yeah, this is my understanding - though it's just as likely programmers' management objecting to them spending time fixing something there's no perceived value to. But whichever, the end result is the same.

The good news though is this means there isn't any technical impediment to running AppleTalk over WiFi, especially if one is prepared to never use Phase I.

 

[NJRoadfan]

Further, there appears to be two standards for transition bridging Ethernet and WiFi, namely 802.1H and RFC1042. Older access points, particularly from Cisco, allow one to configure this. I haven't seen it in equipment in a long time. Maybe one supports Phase II properly vs. the other?

 

[cheesestraws]

I don't know the details of 802.1H, but RFC1042 explicitly only cares about IP, the name of the RFC is "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks" (here) (edit: a subsequent quick skim demonstrates it does work with other things, kinda.)

This presentation may contain the key: https://www.ieee802.org/1/files/public/docs2009/H-nolish-draftintro-0109-v01.ppt. One of the slides in here says of RFC1042:

"Certain protocols are interpreted differently on an end station depending upon if they are raw EtherType or LLC/SNAP encapsulated. Thus a frame transiting between two Ethernet LANS via an intervening 802.3 LAN would always lose its LLC/SNAP encapsulation, thus changing the meaning of the data flow between the end stations." where 802.3 can also mean 802.11.

This presentation (which also says that 802.11 kind of forked 802.1H) has done nothing to change my opinion that this was a complete mess and it's the messiness that's the problem, not anything structural about DDP.

 

[dougg3]

I saved this doc a while ago when I was researching AppleTalk 802.11 stuff. It kinda sorta explains the relevant part of 802.1H and recommends an extension to it for IPX.

https://mentor.ieee.org/802.11/dcn/05/11-05-0159-00-0apf-integration-function-detailed-description.doc

 

[cheesestraws]

I saved this doc a while ago when I was researching AppleTalk 802.11 stuff. It kinda sorta explains the relevant part of 802.1H and recommends an extension to it for IPX.

Oh, that's a good find. I was working from conversations on mailing lists, mostly: that document is a lot clearer (and points the finger firmly at AARP which I didn't know)

 

[Mk.558]

I wanted to test this out a bit further since I still had some questions.

To help understand what is going on I have a simple image here.



This shows the layout of the network. The WRT54G is set for WiFi Client Bridge: it connects to a WiFi network and works as a bridge. Now the WRT54G is claimed to support AppleTalk but I don't know how to interpret that. AppleTalk over TCP/IP? Regular AppleTalk? I would test it with my mac mini G4 but for some strange reason it doesn't have an AirPort card installed. I...didn't know you could do that...I thought they all came with one. I don't have an AirPort base station either and I don't think I've ever even seen one.

The Main PC is running a VirtualBox instance of Ubuntu 10.4.4 LTS (don't ask) which is serving up an instance of Netatalk 2.1.6.



The SE/30 was able to reach out to the internet, actually all I did was fire up Fetch 2.1.2 and call up ftp.belnet.be and it worked.

The test point was to figure out if the Netatalk instance could be seen by which machine. All machines could FTP into the SE/30 which was running NetPresenz 4.1.

Here's the results. The mac mini G4 did not detect the netatalk box in the Chooser, but calling up 192.168.0.95 got it connected. The SE/30 predictably, could see nothing except the mac mini G4. The take-away is that if you use AFP over TCP/IP, then you can use WiFi on non-compatible routers.

 

[Mk.558]

I realized after this post was made I basically contributed nothing to the discussion.

oh well.

 

[NJRoadfan]

Your WiFi router doesn't appear to be properly passing DDP AppleTalk packets. You would be able to see the netatalk box from the other side in Chooser. On the netatalk machine, type "nbplkup", it will list all devices the machine can see on the network. Anything on the other side of the WiFi bridge will likely not appear.

 

[Mk.558]

yeah I wish I had another device such as an early AirPort device test if the WRT54G router does it correctly. It was a popular router for many years and is/was cheap and commonplace: and I'm keeping mine because of the flashable firmware which adds stuff like the WiFi Repeater and WiFi Client Bridge. The bridge function would be a boon for older computers, but it's also only a 802.11b/g router and nobody really uses 802.11g anymore much.

 

[chelseayr]

@Mk.558 not to be too offtopic here but the airport/bt combo card was an optional extra initially but then at one point apple made it standard option instead

 

[Mk.558]

Gotcha. Maybe I got one of the early ones. Doesn't matter to me anyways because when 9.2.2 is not compatible with the WiFi/BT cards anyways, and I use ethernet because as long as it works, it works every single time.

 

[NJRoadfan]

Been researching OpenWRT and how it does its interface bridging. It appears to use the Linux kernel bridging functions to do its magic (no surprise). There may be some hope of using something like ebtables to properly forward AppleTalk SNAP packets between WiFi and Ethernet.

Also, this appears to be where the kernel handles SNAP packet translation between Ethernet and 802.11 WiFi: https://github.com/torvalds/linux/blob/90450a06162e6c71ab813ea22a83196fe7cff4bc/net/wireless/util.c

Doing more digging, some WiFi NIC drivers are special handling IPX and AARP SNAP packets too. I'm noticing only references to AARP though, not the main DDP AppleTalk packets.

 

[NJRoadfan]

OK, now I know why this makes people's head spin. According to the IEEE document linked above, all EtherTalk Phase 2 packets should be treated as 802.2 SNAP frames and simply copied between WiFi and Ethernet without any changes (see page 5 and 6). The problem is EtherTalk Phase 1 (Ethernet II) AARP packets as they would be ambiguous to Phase II packets when converted to/from 802.2 SNAP on WiFi. This still doesn't explain why WiFi and AppleTalk is broken particularly with netatalk boxes on Linux as the kernel doesn't support EtherTalk Phase I at all!

The Linux kernel's Wifi stack and drivers seems to handle this translation correctly. Perhaps some piece of code somewhere is stripping the SNAP headers off of all traffic and assuming the last two bytes are the EtherType? I can totally see that happening for..... reasons.

 

[Mk.558]

I'm intrigued by Phase I. What notable piece of equipment even used/still uses Phase I? AFAIK the only stuff that would be early enough to use it would be the Apple Ethernet NB card (which only had a 10BASE-2 jack and a AUI connector for a 10BASE-5 drop cable), but you'd have to specifically install EtherTalk Phase I drivers from the AppleShare File Server 2.0 (or 1.0? Never been able to find 1.0 anywhere) suite.

 

[dougg3]

Perhaps some piece of code somewhere is stripping the SNAP headers off of all traffic and assuming the last two bytes are the EtherType? I can totally see that happening for..... reasons.

My brain's pretty fried so I apologize if I'm repeating what you already said, but I think this is what the IEEE document is saying -- "dumb" equipment out there, if only following the RFC1042 rules, is going to strip the SNAP header off of AARP Phase 2 packets when translating from 802.11 to Ethernet because the header starts with AA-AA-03-00-00-00. But smart equipment will notice "oh, the next two bytes are 80-F3 so this is an AARP Phase 2 packet and I need to preserve the SNAP header when sending this over Ethernet".

It looks like ieee80211_get_8023_tunnel_proto in the file you linked is doing the correct check, but we'd probably have to sniff some traffic on both sides to know for sure if Linux is doing the correct thing. My money would be on the blame lying on the access point in the 802.11 to Ethernet conversion process with AARP Phase 2 packets...

 

[NJRoadfan]

I got tripped up by the IEEE paper as well. AARP Phase 2 should be preserving the SNAP header, since the first byte on the header is under 0x600, which tells a packet bridge following RFC1042, "This is SNAP", and to leave things alone. 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. Adding the extra 0xF8 to the SNAP header basically tells the packet bridge "hey this is a Phase 1 AARP Ethernet II packet, not a Phase II AARP SNAP packet."

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, since moving a pointer a few bytes is the lazy programmer thing to do. I have to get Wireshark up and running with the access points I have here to check.