AppleTalk Issues with Unifi Switch

[flo]

I recently installed Netatalk 2.3 on Debian within a VM on an Intel Mac and tried to have my Classic Macs connect to it via AppleTalk over Ethernet using Unifi managed switches. Unfortunately, the computers could never "see" each other. I tried to narrow things down by setting up various AFP servers on the Classic Macs (AppleShare Pro on A/UX 3, Personal File Sharing MacOS 9.2) but haven't been able to figure out the root cause of the issue. Using Wireshark on a Mac connected to a hub together with the Classic Macs or on the host Mac of the VM shows the appropriate AppleTalk packets (NBP, AARP, ZIP), but any computer beyond the first Unifi switch is not able to discover the Classic Macs (e.g. using Chooser, Trawl). It looks like the AppleTalk packets are not forwarded by the switch. It does work, though, when the computers are connected only using the hub (which is not surprising).

My understanding is that AppleTalk / EtherTalk should work fine on layer 2 switches, and I assume the Unifi switches are layer 2. At least I could not find any information otherwise -- as far as I understand, any layer 3 routing functions like inter-VLAN routing have to go via the Unifi Security Gateway and are not handled by the switch itself.
The last time I tried a few years ago I was actually able to use AppleTalk in my Ethernet network, but it might be that I still had a combination of AirPort Extremes and some DSL modem + hub for networking at that time.

I read quite a lot of material on AppleTalk packets, SNAP, etc... but I could not find anything leading in the right direction. Any the documentation on the Unifi switches doesn't seem to go into too much detail, either. Maybe I am overlooking something really obvious? Any hints would be highly appreciated!

 

[NJRoadfan]

You should be seeing multicast frames from the AppleTalk protocols (DDP and AARP) over the switch at a minimum (Destination MAC of: 09:00:07:FF:FF:FF). A switch should treat those as "relay on all ports". I wouldn't be surprised if the firmware on the switch makes the silly assumption that everything over Ethernet must be IPv4, ARP, and IPv6.

Note: Wireshark does not show AARP packets if you have the filter set to "atalk". You need to set the filter to "aarp" to see that traffic. All AppleTalk traffic should show as "IEEE 802.3 Ethernet", not "Ethernet II".

 

[halkyardo]

Huh, interesting, I’ve got a Unifi switch (an older 8-port, can’t remember the exact model) between my vintage Macs and a Netatalk 2.x server and as far as I’m aware it’s never been any trouble. I’ll have a poke around and see if I can find any options that might affect it.

 

[flo]

Thanks both for the quick response!

I did a check with a MacBook running Wireshark connected to the hub with a Q800 + A/UX 3 + AppleShare Pro and iMac MacOS 9.2. ("Trawl" on the iMac can see both the Quadra and the iMac, and I can connect to the AFP share on the Quadra.)
When booting the Quadra, I get several AARP packets like the following:

2 0.189688 Apple_f4:25:13 AppleTalk-broadcast-address AARP 60 Is there a 65474.1

Frame 2: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface en4, id 0
IEEE 802.3 Ethernet
Destination: AppleTalk-broadcast-address (09:00:07:ff:ff:ff)
Source: Apple_f4:25:13 (08:00:07:f4:25:13)
Length: 36
Trailer: 080007f42513080007f4
Logical-Link Control
DSAP: SNAP (0xaa)
SSAP: SNAP (0xaa)
Control field: U, func=UI (0x03)
Organization Code: 00:00:00 (Officially Xerox, but
Type: AARP (0x80f3)
AppleTalk Address Resolution Protocol (probe)
Hardware type: Ethernet (0x0001)
Protocol type: AppleTalk LLAP bridging (0x809b)
Hardware size: 6
Protocol size: 4
Opcode: probe (3)
Sender MAC address: Apple_f4:25:13 (08:00:07:f4:25:13)
Sender ID: 65474.1
Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
Target ID: 65474.1

Connecting the MacBook to another port of the Unifi Switch (US-8-60W) results in no AARP traffic when booting the Quadra. Both ports (hub and MacBook) are on the default LAN and I can see IP traffic from other network devices.

I now also somehow suspect some Unifi setting... I searched through my old e-mails and buying the Unifi network equipment was actually before I did my first try with Netatalk back in 2021. At that time, I had some mail exchange with the maintainer to suggest some bug fixes and I found a screenshot where nbplkup showed both the (then) Debian AFPServer as well as my Q800 and PM7100 (which since yesterday produces the "car crash" startup sound... another topic to look into...).

I will try around some more with the Unifi management interface and let you know if I find anything.

 

[eharmon]

You might try disabling any sort of Proxy ARP features, if they're present.

 

[flo]

Yesterday, I disabled various functions on the Unifi switches, e.g. Threat Detection, Deep Packet Inspection, and (Rapid) Spanning Tree Protocol. The first two I assumed might only work on well-formed IP packets and especially Thread Detection & Prevention might discard everything else. I also read that some older devices might have issues with RSTP. Unfortunately, no success with disabling either of the options.

Interestingly, the Unifi management interface continues to recognize the MAC address of the Q800 ethernet and shows the computer as connected to the right switch / port and (correctly) without an IP address.

 

[flo]

You might try disabling any sort of Proxy ARP features, if they're present.

As far as I could see, Unifi only has Proxy ARP functions for WLAN. I could not find any options for wired Ethernet.

 

[flo]

SOLVED -- IGMP Snooping has to be deactivated in Unifi network settings.

Here's my chain of try & error (and luck):

I logged into the switch via SSH and the commands --> "cli" --> "show mac-addr-table" and checked the MAC addressing table:

VLAN ID MAC Address Interface IfIndex Status
------- ------------------ --------------------- ------- ------------
1 00:30:65:E1:E9:60 0/6 6 Learned
1 08:00:07:F4:25:13 0/2 2 Learned

So the switch is aware of the computers (Q800, iMac) and their respective MAC addresses. Still, the Macs cannot "see" each other. So maybe the initial AARP broadcasts do not make it across the switch? Indeed, WireShark does not show any AARP or other AppleTalk-related traffic across the switch.

I had another look at the destination MAC address of the AARP packets described in one of my earlier posts:

Destination: AppleTalk-broadcast-address (09:00:07:ff:ff:ff)
Address: AppleTalk-broadcast-address (09:00:07:ff:ff:ff)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)

Would the switch interpret the "AppleTalk-broadcast-address" as a regular MAC address, and since it appears there is no computer connected to the switch with this MAC address, it is not forwarded but discarded?

"Inside AppleTalk, 2nd Edition" mentions in section 3-8: "ELAP [(EtherTalk Link Access Protocol)] [...] registers itself with the underlying data link to receive all packets address to that multicast hardware address." So I assume the computers should tell the switch somehow that they want to receive packets for this MAC address, and the switch should have this MAC address stored as well in its MAC address table?

I read that the switch "learns" about the MAC addresses by examining the source MAC address of each transmission and this way build its MAC address table. In case there is an unknown MAC address, the switch should perform unicast "flooding", transmitting the packet with the unknown MAC address on all its ports. This did not happen as verified with WireShark.

I then looked for some information what Unifi switches would do with (unicast) MAC flooding and I happened to come across a screenshot of a Netgear switch showing an option for "block unknown multicast traffic" under the "IGMP snooping" option. I thought it might be worth a try to deactivate this option in the Unifi network settings; if Netgear devices perform some kind of multicast blocking, then maybe the Unifi switches do something similar with multicast (or even unicast flooding) traffic.

Now, I can access my AppleShare Pro file server via Ethernet across the switch on my iMac.

 

[halkyardo]

SOLVED -- IGMP Snooping has to be deactivated in Unifi network settings.

<snip>

I then looked for some information what Unifi switches would do with (unicast) MAC flooding and I happened to come across a screenshot of a Netgear switch showing an option for "block unknown multicast traffic" under the "IGMP snooping" option. I thought it might be worth a try to deactivate this option in the Unifi network settings; if Netgear devices perform some kind of multicast blocking, then maybe the Unifi switches do something similar with multicast (or even unicast flooding) traffic.

Now, I can access my AppleShare Pro file server via Ethernet across the switch on my iMac.

That's some good detective work! Sorry I never got around to digging into my network setup to investigate, but just to confirm, I tried turning IGMP snooping on on my network, and indeed, AppleTalk immediately stopped working.

This makes sense - IGMP is the protocol used to manage IPv4 multicast groups, and IGMP snooping causes the switch to monitor IGMP packets and direct multicast traffic only to hosts that have joined the corresponding IP multicast group. The help text on my Unifi controller says that IGMP snooping "may drop any non-registered multicast traffic (such as PTPv2)" - presumably talking about multicast traffic that exists outside of IGMP's view of the world - such as AppleTalk.

 

[cheesestraws]

IGMP Snooping has to be deactivated in Unifi network settings.

Wow, that's grotty.

The help text on my Unifi controller says that IGMP snooping "may drop any non-registered multicast traffic (such as PTPv2)"

That's really unimpressive as an IGMP snooping implementation, tbh.

 

[eharmon]

Ugh, I almost wrote that suggestion but it seemed absurd that IGMP snooping would break it!

Ubiquiti software continues to leave me unimpressed. Wish there was a good alternative (there's similar products, but they just don't hit the same niche for me).

 

[NJRoadfan]

So my theory was partly true. Lazy programmers assuming everything is IP. Heck, IP multicast even has a reserved MAC range, but filtering requires work, and one can't be bothered with that! I can see why sysadmins would want it though. Many thought "chatty" protocols like AppleTalk were the devil and did everything they could to kill their broadcast traffic on their networks.

 

[flo]

Thank you all for your comments and suggestions!

Looking forward, I wonder how this issue could be solved in the future? I am not a network expert (I actually learned quite a bit the last days...), but would it make sense if Netatalk did some sort of IGMP multicast group registration on the network? Maybe this would at least allow Netatalk to be visible for other AppleTalk nodes on the network; probably the AppleTalk nodes would not be able to discover each other as we cannot really easily change the AppleTalk network stack on MacOS. Then again, how about e.g. a system extension that would send an IGMP multicast group registration during boot?

 

[cheesestraws]

Lazy programmers assuming everything is IP.

As someone who writes network data plane code (not, I should add, at ubiquiti or anywhere in the same market) - the worst of this is that it also actually makes the code quality worse and the software less maintainable and predictable! It's not a win for anyone other than the software engineering manager who pushed this decision through to make their metrics look better because they closed a feature off faster. I doubt it's the individual programmers being lazy, because this kind of shortcut actually makes working on the code worse, in most cases...

Rant, rant, grumble grumble. Why, yes, I have spent much of the last week trying to advocate for doing something important properly in packet processing software, why do you ask...

Then again, how about e.g. a system extension that would send an IGMP multicast group registration during boot?

This would probably be the first thing I would attempt (though please note I've only given this about 10 minutes thought so far, and I may be totally wrong). It'd be a bit more complicated than this, because there are multiple multicast MAC addresses in play (for example, for zone-directed broadcasts), and the IP stacks available for computers where you'd really want to do AppleTalk don't support multicast IP either. So I think what you'd want to do is craft a whole set of IGMP messages and send then out as raw Ethernet frames, to tickle the switch.

Fortunately I haven't heard of this happening with other switches - my own core switch has IGMP snooping turned on and very definitely does not do this - so if this works, a "Ubiquiti Enabler" might work for users of these switches?

 

[NJRoadfan]

Keep in mind that we are at the point where a developer for switch firmware likely wasn't old enough (or even born!) when anything other then IP traffic was present on Ethernet networks! How does one develop a test case that they don't even know about.

On a related note, this likely interferes with LToUDP packets as well since it would be classed as "unknown" multicast traffic.

 

[cheesestraws]

On a related note, this likely interferes with LToUDP packets as well since it would be classed as "unknown" multicast traffic.

LToUDP does proper IGMP, so it ought to work.

 

[flo]

For sake of completeness of this topic, I just happened to discover the same behavior with Dell switches:
Appletalk and Bonjour services are not working when connected to Dell Networking N series switch in a VLAN with IGMP snooping enabled

 

[NJRoadfan]

Wonder how much fun blocking a current protocol like multicast DNS has caused folks. Some stuff requires working mDNS and DNS-SD services, or else are impossible to use/configure.

 

[cheesestraws]

ouch.