| 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
| ||
|
Message-Id: <20081217120301.a6eba80f.akpm@linux-foundation.org> Date: Wed, 17 Dec 2008 12:03:01 -0800 From: Andrew Morton <akpm@...ux-foundation.org> To: netdev@...r.kernel.org, linux-usb@...r.kernel.org Cc: bugme-daemon@...zilla.kernel.org, mh+kernel-bugzilla@...schlus.de, Peter Korsgaard <jacmet@...site.dk>, petkan@...rs.sourceforge.net Subject: Re: [Bugme-new] [Bug 12242] New: ADMtek ADM8515 "Pegasus II" does not properly handle incoming 802.1q frames near MTU (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@...zilla.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@...ox.com > ReportedBy: mh+kernel-bugzilla@...schlus.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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists