• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

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

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.
 
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.
 
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)?
 
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.
 
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.
Click to expand...
So, let‘s say we re-use the host‘s MAC address for the AppleTalk interface, this would work with WiFi? 😃
 
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 said:
So, let‘s say we re-use the host‘s MAC address for the AppleTalk interface, this would work with WiFi?
Click to expand...
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?
 
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.
 
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.
 
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.
 
I went down the rabbit hole of this hoping I could create an All-in-One AppleTalk solution with a linux box acting both as Access Point + Netatalk server.

Unfortunately, it seems like the issue lies in the actual WiFi chipset firmware as the kernel and the driver do construct right ethernet frames with no weird shenanigans. I'm gonna try to get one of the "blessed" WiFi Access Points and see if I can spot anything different in how the traffic is being constructed.
 
Just get any variety of modern Apple AirPort. Works just fine. They are all that I use and pass AppleTalk without issue.
 
@Maku, the Linux kernel should have no problem routing AARP frames, the translation from Wifi to Ethernet happens there, not in the device driver. Those are the wireless routers that always seem to work too. I have no problem running a RPi400 with netatalk as an AppleTalk WiFi client as long as the access point on the other end properly translates the packets.

Note that you may be having other networking issues.... like multicast is broken.
 
NJRoadfan said:
@Maku, the Linux kernel should have no problem routing AARP frames, the translation from Wifi to Ethernet happens there, not in the device driver. Those are the wireless routers that always seem to work too. I have no problem running a RPi400 with netatalk as an AppleTalk WiFi client as long as the access point on the other end properly translates the packets.
Click to expand...
My goal was to make the RPi the Access Point through use of `hostapd`.
 
The RPi's hardware is not the issue here. You'd have to sniff the network and see if AARP multicast packets are making it over WiFi to the Pi. The Airport should have no problem doing this.
 
NJRoadfan said:
The RPi's hardware is not the issue here. You'd have to sniff the network and see if AARP multicast packets are making it over WiFi to the Pi. The Airport should have no problem doing this.
Click to expand...
AARP are produced by RPi - it's running the Netatalk server and I can see them being passed to the RPi Broadcom driver (using bpftrace) - they never reach any other client on the network. Again, RPi is the "Access Point" in question here.

I can see the traffic just fine on the wired network on all of my wired computers. Any computer connected over WiFi to the RPi does not receive them.

Network is setup as such:

RPi eth0 wired to Mac Studio
RPi wlan0 broadcasting (in AP mode) to MacBook Pro

Mac Studio sees the DDP packets (as seen in the screenshot), the MacBook Pro does not.
Screenshot 2024-08-19 at 6.48.42 PM.png
 
You must log in or register to reply here.

Similar threads

pl212
Finding FiberTalk: DuPont's AppleTalk-over-Fiber Hardware
Replies
5
Views
1K
cy384
cy384
bigmessowires
alternatives for WPA2 networking under OS9
2
Replies
25
Views
6K
bigmessowires
bigmessowires
C
A very brief introduction to AppleTalk for people who know IP
Replies
18
Views
12K
cheesestraws
C
C
Developing a portable user-land AppleTalk stack
2 3 4
Replies
70
Views
115K
robin-fo
robin-fo
J
looking for Device Driver development resources
Replies
4
Views
1K
Crutch
Crutch
Back
Top