Reply-To: akpm@linux-foundation.org


(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Wed, 17 Dec 2008 09:46:09 -0800 (PST)
bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=12242
> 
>            Summary: ADMtek ADM8515 "Pegasus II" does not properly handle
>                     incoming 802.1q frames near MTU

It is my understanding that numerous drivers don't handle the larger
frames - each one needs to be specially tweaked to handle them.  Making
this a feature request.  I think.

>            Product: Drivers
>            Version: 2.5
>      KernelVersion: 2.6.27.9
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Network
>         AssignedTo: jgarzik@pobox.com
>         ReportedBy: mh+kernel-bugzilla@zugschlus.de
> 
> 
> Latest working kernel version: none, it's a new device which I didn't try
> against older kernels
> Earliest failing kernel version: unknown, bug appears with 2.6.27.9
> Distribution: Debian unstable
> Hardware Environment: hp compaq nc 8000, Centrino (1st generation?) 
> connected via USB
> Software Environment: vconfig, ip, ping
> Problem Description: 
> 
> 802.1q tagged ethernet frames are four bytes longer than a normal ethernet
> frame. The four bytes are added to the layer 2 ethernet header. Hence, the
> MTU
> the OS sees is identical to untagged frames, but the driver needs to be able
> to
> handle frames that are four bytes larger.
> 
> The pegasus driver does not handle this properly and eats frames that are
> larger than the largest expected untagged frame.
> 
> Test setup:
> 
> -------------------
> |     Box 1       |
> -------------------
>         | ADMtek ADM8515 Pegasus II interface, VLAN 401 tagged,
>         10.3.11.254/24
>         |
>         | Port 9, VLAN 401 tagged
> -------------------
> | Switch          |
> -------------------
>         | Port 3, VLAN 401 untagged
>         |
>         | On board e1000 Ethernet, 10.3.11.223/24
> -------------------
> | Box 2           |
> -------------------
> 
> Pinging box2 from box1 with ping -s 1468 10.3.11.223 works fine, tshark
> output
> on both boxes identical. Pinging box2 from box1 with ping -s 1469 10.3.11.223
> does not work, echo replies are sent out by box2, but box1 claims to not
> having
> received them:
> box1$ sudo tshark -i eth3.401 -np
> Running as user "root" and group "root". This could be dangerous.
> Capturing on eth3.401
>   0.000000  10.3.11.254 -> 10.3.11.223  ICMP 1510 Echo (ping) request
>   0.000860  10.3.11.223 -> 10.3.11.254  ICMP 1510 Echo (ping) reply
>   1.003772  10.3.11.254 -> 10.3.11.223  ICMP 1510 Echo (ping) request
>   1.004588  10.3.11.223 -> 10.3.11.254  ICMP 1510 Echo (ping) reply
>   2.007862  10.3.11.254 -> 10.3.11.223  ICMP 1510 Echo (ping) request
>   2.008689  10.3.11.223 -> 10.3.11.254  ICMP 1510 Echo (ping) reply
>   4.808346  10.3.11.254 -> 10.3.11.223  ICMP 1511 Echo (ping) request
>   4.997651 00:12:79:bb:77:0c -> 00:13:3b:00:00:65 ARP 60 Who has 10.3.11.254? 
> Tell 10.3.11.223
>   4.997679 00:13:3b:00:00:65 -> 00:12:79:bb:77:0c ARP 42 10.3.11.254 is at
> 00:13:3b:00:00:65
>   5.808121  10.3.11.254 -> 10.3.11.223  ICMP 1511 Echo (ping) request
>   6.808143  10.3.11.254 -> 10.3.11.223  ICMP 1511 Echo (ping) request
> 
> 
> box2$ sudo tshark -i eth0 -np
>   0.000000  10.3.11.254 -> 10.3.11.223  ICMP 1510 Echo (ping) request
>   0.000457  10.3.11.223 -> 10.3.11.254  ICMP 1510 Echo (ping) reply
>   1.003466  10.3.11.254 -> 10.3.11.223  ICMP 1510 Echo (ping) request
>   1.003492  10.3.11.223 -> 10.3.11.254  ICMP 1510 Echo (ping) reply
>   2.007561  10.3.11.254 -> 10.3.11.223  ICMP 1510 Echo (ping) request
>   2.007586  10.3.11.223 -> 10.3.11.254  ICMP 1510 Echo (ping) reply
>   4.808143  10.3.11.254 -> 10.3.11.223  ICMP 1511 Echo (ping) request
>   4.808167  10.3.11.223 -> 10.3.11.254  ICMP 1511 Echo (ping) reply
>   4.996845 00:12:79:bb:77:0c -> 00:13:3b:00:00:65 ARP 42 Who has 10.3.11.254? 
> Tell 10.3.11.223
>   4.997158 00:13:3b:00:00:65 -> 00:12:79:bb:77:0c ARP 60 10.3.11.254 is at
> 00:13:3b:00:00:65
>   5.807926  10.3.11.254 -> 10.3.11.223  ICMP 1511 Echo (ping) request
>   5.807949  10.3.11.223 -> 10.3.11.254  ICMP 1511 Echo (ping) reply
>   6.807969  10.3.11.254 -> 10.3.11.223  ICMP 1511 Echo (ping) request
>   6.807992  10.3.11.223 -> 10.3.11.254  ICMP 1511 Echo (ping) reply
> 
> All pings get through fine if box1 uses its built-in e1000 interface, so I
> guess it is pretty clear that the Pegasus driver is at fault here - it is not
> alone in this failure, the MCS 7830 driver (see #12003) has the same issue.
> 
> I discussed this on the LKML a few months ago, but unfortunately, without any
> result. I am filing this bug for future reference and do sincerely hope that
> somebody with appropriate knowledge will get around to fix it.
> 
> I can give ssh access to a box which has the device connected. I am also
> prepared to apply, compile and try patches against any recent 2.6 kernel, but
> do not have the expertise (and time) to handle any programming tasks myself.
> 
> Greetings
> Marc

Don't have the hardware docs to check but if its just a driver limit then editing drivers/net/usb/pegasus.h and making PEGASUS_MTU 8 larger and recompiling is probably sufficient. Might be worth testing that.

I have a Belkin F5D5050 which encounters this problem.  The newer Belkin F5D5055 also probably needs this driver; and many other implementations need it.  Appears that the driver has not been revised since over 10 years ago.

Please try the modification I indicated in comment #2 and report back if it works

No response, closing

I have tried the suggested patch and apologize for taking so long. Unfortunately, no change.

Greetings
Marc

Thanks - not much else I can do then as it seems that VPN frames don't actually come back from the chip to us in the first place. Will need someone with full copies of the docs to fix it, if the hardware can do it.

I have like device:
[root@roman ~]# lsusb
Bus 002 Device 002: ID 07a6:8515 ADMtek, Inc. AN8515 Ethernet

And it don't work full. No ethernet interface created. Into dmesg I have this:
[  877.944014] usb 2-1: new high speed USB device using ehci_hcd and address 2
[  878.078559] usb 2-1: New USB device found, idVendor=07a6, idProduct=8515
[  878.078563] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  878.078566] usb 2-1: Manufacturer: USBNT
[  878.078732] usb 2-1: configuration #1 chosen from 1 choice
[  878.464021] pegasus: v0.6.14 (2006/09/27), Pegasus/Pegasus II USB Ethernet driver
[  878.498739] pegasus 2-1:1.0: read_eprom_word failed
[  878.532856] pegasus 2-1:1.0: can't reset MAC
[  878.532901] pegasus: probe of 2-1:1.0 failed with error -5
[  878.532937] usbcore: registered new interface driver pegasus

The device tested and don't work at kernels 2.6.30 and 2.6.32.

maybe related to https://bugzilla.kernel.org/show_bug.cgi?id=9270 ?

Basically we don't have any info to add longer packed support.

Roman's bug appears unrelated tagged onto the old bug, so closing