From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tokarev Subject: Re: e100 + VLANs? Date: Mon, 10 Oct 2011 18:57:15 +0400 Message-ID: <4E9307CB.4050704@msgid.tls.msk.ru> References: <4E90212D.8030009@msgid.tls.msk.ru> <1318091046.5276.22.camel@edumazet-laptop> <4E9097C0.2030307@gmail.com> <20111010101954.GB2840382@jupiter.n2.diac24.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: jeffrey.t.kirsher@intel.com, Eric Dumazet , netdev To: David Lamparter Return-path: Received: from isrv.corpit.ru ([86.62.121.231]:54331 "EHLO isrv.corpit.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751118Ab1JJO5R (ORCPT ); Mon, 10 Oct 2011 10:57:17 -0400 In-Reply-To: <20111010101954.GB2840382@jupiter.n2.diac24.net> Sender: netdev-owner@vger.kernel.org List-ID: 10.10.2011 14:19, David Lamparter wrote: > On Sat, Oct 08, 2011 at 11:34:40AM -0700, Jeff Kirsher wrote: >> On 10/08/2011 09:24 AM, Eric Dumazet wrote: >>> Le samedi 08 octobre 2011 =C3=A0 14:08 +0400, Michael Tokarev a =C3= =A9crit : >>>>> Yesterday I tried to use 802.1Q VLAN tagging with an (oldish) >>>>> e100-driven network card, identified by lspci like this: >>>>> >>>>> 00:12.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Eth= ernet Pro 100 (rev 02) >>>>> >>>>> Just to discover that it does not quite work: packets of >>>>> size 1497+ bytes gets lost. > [...] >>> e100 driver seems VLAN enabled at a first glance. >> Eric is correct, that e100 does support VLANs. >> >> In addition to Eric's suggestion, can you also provide all the outpu= t of >> lspci -vvv for the network card? >=20 > I'm opening the lore box here, but early e100 cards AFAIK have a=20 > hardware limit at 1500 (+18 src/dst/proto) bytes. At least, Juniper's > JUNOS does not support full-sized .1Q on their e100 control plane > interfaces... Thank you all for the suggestions and feedback. The card may indeed be quite old, I don't know where it come from and when. Here's lspci -vvv for it: 00:12.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet P= ro 100 (rev 02) Subsystem: Intel Corporation EtherExpress PRO/100B (TX) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- St= epping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=3Dmedium >TAbort- SERR- ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), lengt= h 60: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Reque= st who-has 10.48.11.2 tell 10.48.11.1, length 42 00:90:27:30:6d:1c > 00:1f:c6:ef:e5:1b, ethertype 802.1Q (0x8100), lengt= h 46: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Reply= 10.48.11.2 is-at 00:90:27:30:6d:1c, length 28 =46rom the partner point of view, also on whole ethX: 00:1f:c6:ef:e5:1b > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), lengt= h 46: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Reque= st who-has 10.48.11.2 tell 10.48.11.1, length 28 00:90:27:30:6d:1c > 00:1f:c6:ef:e5:1b, ethertype ARP (0x0806), length 6= 0: Ethernet (len 6), IPv4 (len 4), Reply 10.48.11.2 is-at 00:90:27:30:6= d:1c, length 46 So, the tag gets eaten somewhere along the way... ;) And I can't really recreate the situation which I had - I know some packets were flowing, so at least ARP worked. Now it does not work anymore. Hmm.... ;) Thank you! /mjt