Every package received via an ax88179_178a driven device (observed on Delock branded "62417" USB3 gigabit Ethernet adapter, reporting as "0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet" on lsusb) has two additional bytes appended to it. Wireshark interprets them as "VSS-Monitoring ethernet trailer". (Seems to be some kind of Ethernet management devices that append debug data to the frames they send). Apart from the odd lines in network captures, this confuses tools like `scan6` that can't cope with overlong frames (which might be a bug by itself, but still). I've tried stripping the abundant bytes away with `{ax_,}skb->len = pkt_len - 2` in the ax88179_rx_fixup function (both code paths are affected, the second is only triggered when more than a few package are exchanged); that partially works (the VSS lines disappear from wireshark, and `scan6` starts working), but negatively affects other connections (TLS and SSH connections break randomly); a proper fix would require understanding of which sizes in the skb do what, of how much wireshark can be trusted when it comes to a corrupt device, and a failure case that is easier to debug at packet inspection level than a failing SSH connection, none of which I have right now. I'd be happy to provide any further data or test any patches (or, given it's relatively cheap adapter, have a sample device sent to whomever wants to fix this).
Has this worked before in older kernel versions or not. If it has why not try bisecting it to see the introduced bad commit into the current kernel release.
there have always been the abundant bytes as long as i have used the device (around 3.16-ish); i only started digging down deeper now because i started using scan6 which relies/-d on the package lengths.
Try bisecting it seems to me that something screwed up when dealing with packets on the adaptor your using.
i don't have any good version to bisect it against. the driver was introduced between 3.8 and 3.9. i've just now tested kernel versions back to 3.11 for which i had a live image around, and the bug already existed there.
Ok that's a good start. Can you send me your dmesg and wireshark outputs.
Created attachment 223001 [details] dmesg from connecting to disconnecting the device
Created attachment 223011 [details] pcapng dump of traffic over the network interface during address configuration i've taken the liberty to filter out the masses of mdns packages that were originally part of the dump
Ok seems that this line can be removed: ax_skb->data = skb->data + 2; and try removing this line too, may need it still but let's see: skb_pull(skb, 2);
Using the driver from http://www.asix.com.tw/download.php?sub=driverdetail&PItemID=131 fixes the issue. Maybe their sources give a hint, what's wrong.
(In reply to ehlers from comment #9) > Using the driver from > http://www.asix.com.tw/download.php?sub=driverdetail&PItemID=131 fixes the > issue. Maybe their sources give a hint, what's wrong. Forget to mention, that I was testing with kernel v4.9.65
FYI this blog post covers this issue pretty well - https://blog.inoki.cc/2019/12/12/Bug_AX88179_178a_USB_Ethernet_adapter_Linux_Driver/