On 19/08/18 13:32, Andrew Lunn wrote:
On Sun, Aug 19, 2018 at 01:07:38PM +1200, Craig McGeachie wrote:
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.
Hi Craig
What Ethernet device are you seeing this problem with?
I'm not sure an Ethernet device should receive its own broadcasts.
This might be a driver bug, not an AARP bug.
Andrew
I run inside Virtualbox with the Realtek PCIe GBE Family Controller.
Assuming I'm reading /sys/class/net/enp0s3/driver correctly, it's using
the e1000 driver.
However, it might not be the ethernet driver's fault. I've been a bit
loose with terminology. Appletalk AARP probe packets aren't ethernet
broadcasts as such; they're multicast packets, via the psnap driver, to
hardware address 09:00:07:ff:ff:ff.
Cheers,
Craig.
