New: ADMtek ADM8515 "Pegasus II" does not properly handle incoming 802.1q frames near MTU

http://bugzilla.kernel.org/show_bug.cgi?id=12242

Summary: ADMtek ADM8515 "Pegasus II" does not properly handle
incoming 802.1q frames near MTU

           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: [email protected]
        ReportedBy: [email protected]

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