[RFC 0/1] Appletalk AARP probe broken by receipt of own broadcasts.

[RFC 0/1] Appletalk AARP probe broken by receipt of own broadcasts.

[Craig McGeachie]

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

[RFC 1/1] appletalk: ignore aarp probe broadcasts that loopback.

[Craig McGeachie]

AARP probe packets are broadcast to dynamically discover if an Appletalk
node address is in use. The definition of AARP requires interpreting the
receipt of probe requests for the address being tested as the address being
in use, and then trying the next address. However, the node receives its own
Ethertalk broadcast, and incorrectly interprets that as another node trying
to claim the address.

Signed-off-by: Craig McGeachie <slapdau@gmail.com>
---
 net/appletalk/aarp.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/appletalk/aarp.c b/net/appletalk/aarp.c
index 49a16cee..f966cc01 100644
--- a/net/appletalk/aarp.c
+++ b/net/appletalk/aarp.c
@@ -757,6 +757,10 @@ static int aarp_rcv(struct sk_buff *skb, struct net_device *dev,
 	if (!ifa)
 		goto out1;
 
+	/* Ignore packets from myself. */
+	if (ether_addr_equal(ea->hw_src, dev->dev_addr))
+		goto out1;
+
 	if (ifa->status & ATIF_PROBE &&
 	    ifa->address.s_node == ea->pa_dst_node &&
 	    ifa->address.s_net == ea->pa_dst_net) {
-- 
2.17.1

Re: [RFC 0/1] Appletalk AARP probe broken by receipt of own broadcasts.

[Andrew Lunn]

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

Re: [RFC 0/1] Appletalk AARP probe broken by receipt of own broadcasts.

[Craig McGeachie]

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.

Re: [RFC 0/1] Appletalk AARP probe broken by receipt of own broadcasts.

[Andrew Lunn]

> 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.

Hi Craig

Ah. And how do you connect to the network? Please run some tcpdumps
and collect packets at various points. Make sure your network setup is
not duplicating packets, in particular, any bridges you might have in
order to connect the segments together.

> 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.

Basically, the same question applies for Multicast as for Broadcast.
I'm pretty sure the interface should not receiver the packet it
transmitted itself. But if something on the network has duplicated the
packet, it will receiver the duplicate. So before we add a filter,
lets understand where the packets are coming from.

	Andrew

Re: [RFC 0/1] Appletalk AARP probe broken by receipt of own broadcasts.

[Craig McGeachie]

On 20/08/18 02:41, Andrew Lunn wrote:
>> 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.
> 
> Hi Craig

Andrew,

My apologies. I've wasted your time. PEBKAC.

> Ah. And how do you connect to the network? Please run some tcpdumps
> and collect packets at various points. Make sure your network setup is
> not duplicating packets, in particular, any bridges you might have in
> order to connect the segments together.

Just for the record, in case anyone else experiences this later. It's
Fedora Core 29 with kernel 4.17.12-200.fc28.x86_64 running inside
Virtualbox 4.2.16. The host NIC is Realtek PCIe GBE. The virtual NIC is
Intel 82540EM. The Linux kernel driver for the virtual NIC is e1000. The
virtual NIC is connected to the physical NIC in bridged mode.

>> 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.
> 
> Basically, the same question applies for Multicast as for Broadcast.
> I'm pretty sure the interface should not receiver the packet it
> transmitted itself. But if something on the network has duplicated the
> packet, it will receiver the duplicate. So before we add a filter,
> lets understand where the packets are coming from.

Turns out the problem is WinPCAP running on the host system (Windows
10). I can reliably cause the problem by starting up anything using
WinPCAP on the host system. I can make the AARP packet echo go away by
shutting down everything that uses WinPCAP.

I don't have a real Apple IIgs (much as I might like one) so I've been
using GSport 0.31, which uses WinPCAP to generate Ethertalk packets over
the same physical NIC that the Linux virtual machine is bridged to.

I've also been using Wireshark on both the host system and guest system
to diagnose my problem. Ironically, using Wireshark on the host system
is one way to cause the packet echo. Wireshark on the guest system works
just fine.

Maybe running WinPCAP and the bridged virtual NIC on different physical
NICS would fix the problem.  I wouldn't know. My solution is run GSport
on a different computer. Using Win10pcap 10.2.5002 instead of WinPCAP
4.1.3 is not a fix. It has the same problem.

I have trouble believing this affects only Appletalk packets, but it's
probably unfounded speculation to consider anything else.

Anyway, thank you very much for your time Andrew.

Cheers,
Craig.

Re: [RFC 0/1] Appletalk AARP probe broken by receipt of own broadcasts.

[Andrew Lunn]

> Turns out the problem is WinPCAP running on the host system (Windows
> 10).

Hi Craig

It would be good to report this to the WinPCAP people. I hate it when
debug tools actually introduce bugs.

      Andrew

Re: [RFC 0/1] Appletalk AARP probe broken by receipt of own broadcasts.

[Craig McGeachie]

On 21/08/18 01:28, Andrew Lunn wrote:
>> Turns out the problem is WinPCAP running on the host system (Windows
>> 10).
> It would be good to report this to the WinPCAP people. I hate it when
> debug tools actually introduce bugs.

This will take me some time. I couldn't fairly blame WinPCAP. Firstly,
WinPCAP isn't really supported on Windows 10 (hence the fork,
Win10PCAP). Secondly, right now all that I know is that it's some
combination of WinPCAP and the virtual Intel 82540EM NIC. I'll have to
play around a bit; maybe try some of the other virtual NICs.

Then I think it would be good to have a more convenient test case than
"First, install netatalk 2.2.6." I'll see if I can make one.

Cheers,
Craig.