All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: David Lamparter <equinox@diac24.net>
Cc: jeffrey.t.kirsher@intel.com,
	Eric Dumazet <eric.dumazet@gmail.com>,
	netdev <netdev@vger.kernel.org>
Subject: Re: e100 + VLANs?
Date: Mon, 10 Oct 2011 18:57:15 +0400	[thread overview]
Message-ID: <4E9307CB.4050704@msgid.tls.msk.ru> (raw)
In-Reply-To: <20111010101954.GB2840382@jupiter.n2.diac24.net>

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 à 14:08 +0400, Michael Tokarev a écrit :
>>>>> 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 Ethernet 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 output of
>> lspci -vvv for the network card?
> 
> I'm opening the lore box here, but early e100 cards AFAIK have a 
> 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 Pro 100 (rev 02)
	Subsystem: Intel Corporation EtherExpress PRO/100B (TX)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 66 (2000ns min, 14000ns max)
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at fe200000 (32-bit, prefetchable) [size=4K]
	Region 1: I/O ports at 2400 [size=32]
	Region 2: Memory at fc000000 (32-bit, non-prefetchable) [size=1M]
	[virtual] Expansion ROM at 30100000 [disabled] [size=1M]
	Kernel driver in use: e100


I tried to set it up to talk to another machine in order to find
out where the packets gets lost.  But had another complication
on the way: it does not "want" to work with 802.1Q VLANs anymore
at all... ;)

When pinging this NIC from another machine over VLAN5, I see
ARP packets coming to it, gets recognized and replies going
back, all on vlan 5.  But on the other side, replies comes
WITHOUT a VLAN tag!

From this NIC's point of view, capturing on whole ethX:

00:1f:c6:ef:e5:1b > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request 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), length 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

From 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), length 46: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request 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 60: Ethernet (len 6), IPv4 (len 4), Reply 10.48.11.2 is-at 00:90:27:30:6d: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

  reply	other threads:[~2011-10-10 14:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-08 10:08 e100 + VLANs? Michael Tokarev
2011-10-08 16:24 ` Eric Dumazet
2011-10-08 18:34   ` Jeff Kirsher
2011-10-10 10:19     ` David Lamparter
2011-10-10 14:57       ` Michael Tokarev [this message]
2011-10-10 15:05         ` Eric Dumazet
2011-10-10 15:13           ` David Lamparter
2011-10-10 15:23             ` Eric Dumazet
2011-10-10 15:28               ` David Lamparter
2011-10-10 15:50                 ` Eric Dumazet
2011-10-10 16:51             ` Michael Tokarev
     [not found]             ` <4E932278.8010802@tls.msk.ru>
2011-10-11  9:51               ` Michael Tokarev
2011-10-11 11:25                 ` Eric Dumazet
2011-10-11 11:59                   ` Michael Tokarev
2011-10-11 12:04                     ` Eric Dumazet
2011-10-11 12:56                       ` Michael Tokarev
2011-10-11 15:29                         ` David Lamparter
2011-10-11 23:38                           ` Jesse Brandeburg
2011-10-13  9:22                             ` Michael Tokarev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E9307CB.4050704@msgid.tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=equinox@diac24.net \
    --cc=eric.dumazet@gmail.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.