I'm hoping I can find someone able and willing to test this patch. That requires someone still using netatalk 2.2.x with DDP, or some other DDP userspace application. This feels like a longshot.
When netatalk 2.2.x starts up with DDP and sets the Appletalk node address, the kernel AARP code sends a probe packet for the address. It then receives its own probe packet and interprets that as some other node also trying to claim the address. It increments the address, tries again, and fails again ad nausium. Eventually the kernel module gives up and returns to netatalk which terminates with an error that it cannot get a node address. Well, most of the time. There seems to be some sort of race condition where occasionally a self collision won't happen. Restart netatalk enough times and it will probably work. The device Ethernet MAC address is copied into the AARP packet, so the fix is to disregard all received packets that have a sender address that matches the device hardware address. This is more than just probe packets, but there is no legitimate situation where an Appletalk node sends AARP packets to itself. Craig McGeachie (1): appletalk: ignore aarp probe broadcasts that loopback. net/appletalk/aarp.c | 4 ++++ 1 file changed, 4 insertions(+) -- 2.17.1
