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

[cheesestraws]

What a mess!

This is great information though, thankyou for gathering it...

 

[NJRoadfan]

Just tested a Netgear R7800 router with stock firmware. Works fine with AARP over WiFi.

 

[gsteemso]

I distinctly recall a discussion to the effect that some Apple software failed to set -- um. Either the EtherType or the SNAP packet type, can't remember. It cleared it instead of using the AppleTalk identifier, so wifi routers tended to drop them as invalid, or something to that effect. The details have blurred after all this time.

 

[NJRoadfan]

Wi-Fi routers aren't dropping the packets, they are incorrectly translating them. AARP Phase 2 SNAP frames are being converted to Ethernet II frames by the router when they shouldn't be touched at all.

 

[robin-fo]

Did anybody ever get AppleTalk to work over WiFi from a (recent) macOS host? (e.g. Linux VM running Netatalk or Qemu with System 7)? I have no issues when bridging to an Ethernet port, but WiFi appears to have issues. When running Linux natively, AppleTalk works over WiFi. Sadly, I can't see any way to run AppleTalk under modern macOS "natively" (i.e. without using tuntap/vmnet)?

 

[NJRoadfan]

Any emulator or VM that uses layer 2 packet injection/filters is going to have trouble with a host running WiFi. See: https://www.virtualbox.org/manual/ch06.html#network_bridged

VirtualBox specifically calls out that macOS only supports IP networking over a bridged connection with a wifi host. I don't know if it works on Windows, but I suspect it doesn't. Tools such as WireShark have the same limitations. When testing WiFi for this thread, I had to pull out my Powerbook G4 to get a "native" Macintosh WiFi client running AppleTalk.

 

[robin-fo]

Oh, that‘s interesting!

Bridging to a wireless interface is done differently from bridging to a wired interface, because most wireless adapters do not support promiscuous mode. All traffic has to use the MAC address of the host's wireless adapter, and therefore Oracle VM VirtualBox needs to replace the source MAC address in the Ethernet header of an outgoing packet to make sure the reply will be sent to the host interface. When Oracle VM VirtualBox sees an incoming packet with a destination IP address that belongs to one of the virtual machine adapters it replaces the destination MAC address in the Ethernet header with the VM adapter's MAC address and passes it on. Oracle VM VirtualBox examines ARP and DHCP packets in order to learn the IP addresses of virtual machines.

So, let‘s say we re-use the host‘s MAC address for the AppleTalk interface, this would work with WiFi?

 

[NJRoadfan]

I don't know the specifics, but it sounds like VirtualBox is translating WiFi packets into Ethernet II packets. Its also likely this only works with IPv4 and v6 traffic only.

 

[robin-fo]

So, let‘s say we re-use the host‘s MAC address for the AppleTalk interface, this would work with WiFi?

Sadly this didn't work quite as well as I hoped :/

I've set the MAC address of my UTM Mac OS 9 Virtual Machine to the same value as the WiFi MAC address of my host, so that Mac OS 9 could be interpreted as being Sonoma's "AppleTalk Stack". With this, I can now see AppleTalk packets on my MacBook Air running Ubuntu, but my M1 Mac with UTM doesn't receive the AARP requests sent by the Linux MBA. Maybe the WiFi interface ignores multicast addresses?

 

[NJRoadfan]

Could be the VM is mis-handling AARP SNAP packets just like access points do. Look for Ethernet II packets with EtherType 0x80F3 in the VM if you can.

 

[robin-fo]

The AARP packets sent by the Linux MBA don‘t even reach the en0 WiFi interface on the Sonoma MBP and I couldn‘t spot any obscure packets on Wireshark. So my guess is that they were filtered out during the 802.11 to Ethernet II conversion? The VM is attached through vmnet in bridged mode and I never had issues with it when bridged to wired Ethernet.

I wonder what would happen if Linux would send AARP frames to ff:ff:ff:ff:ff:ff instead of the AppleTalk multicast address.. Isn‘t there an option for a router to enable this when replying to a ZIP GetNetInfo packet? (Need to check Inside AppleTalk…) Maybe this works just for Zone Multicasts.

 

[NJRoadfan]

I'm assuming the Ubuntu machine is running netatalk natively? If both the MBA and MBP are connected to the same access point, there should be no issue with packet conversion on that leg. The packets will remain 802.11 style SNAP packets end-to-end. WireShark may not be able to see all (any?) traffic on WiFi interfaces. See: https://wiki.wireshark.org/CaptureSetup/WLAN

If the M1 MBP was natively running Linux with netatalk, it could likely see the other machine.

As for multicast, Phase 2 uses dedicated addresses, while Phase 1 just blasted everything over the ff:ff:ff:ff:ff:ff broadcast address. Its not likely that.