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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <43f861ad-1e40-7e6e-b90c-ce410c60df94@gmail.com>
Date:   Mon, 20 Aug 2018 20:48:39 +1200
From:   Craig McGeachie <slapdau@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Craig McGeachie <slapdau@...oo.com.au>
Subject: Re: [RFC 0/1] Appletalk AARP probe broken by receipt of own
 broadcasts.

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.