e100 + VLANs?

e100 + VLANs?

[Michael Tokarev]

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.

This appears to be a classical problems in this case -
something forgot to allocate extra 4 bytes for the
packets.

There's at least one bugreport from 2008 (!) about this
very issue: http://bugs.centos.org/view.php?id=2719
which is still open.

The kernel I tried this on was 2.6.32, I checked git log
for drivers/net/e100.c - there was no changes up to
current version which may be related to this issue.

The question: is this a driver problem or hardware? If
it's the driver, can it be fixed? And if it's hardware,
can the driver notify the user somehow - like, by refusing
to enable VLAN (sub)devices maybe?

Yesterday it was actually a bit more complicated for me,
since the card in question was used to connect to our
ISP, and they use fixed MAC address per port, so I had
to find another NIC which is a) able to work with VLAN
tags properly, and b) is able to change its mac address.
Lucky I had a VIA RhineIII which does both :)

Thanks,

/mjt

Re: e100 + VLANs?

[Eric Dumazet]

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.
> 
> This appears to be a classical problems in this case -
> something forgot to allocate extra 4 bytes for the
> packets.
> 
> There's at least one bugreport from 2008 (!) about this
> very issue: http://bugs.centos.org/view.php?id=2719
> which is still open.
> 
> The kernel I tried this on was 2.6.32, I checked git log
> for drivers/net/e100.c - there was no changes up to
> current version which may be related to this issue.
> 
> The question: is this a driver problem or hardware? If
> it's the driver, can it be fixed? And if it's hardware,
> can the driver notify the user somehow - like, by refusing
> to enable VLAN (sub)devices maybe?
> 
> Yesterday it was actually a bit more complicated for me,
> since the card in question was used to connect to our
> ISP, and they use fixed MAC address per port, so I had
> to find another NIC which is a) able to work with VLAN
> tags properly, and b) is able to change its mac address.
> Lucky I had a VIA RhineIII which does both :)
> 

Since you have two cards (and probably two machines), maybe you could
try to track if the problem is a bad transmit or a bad receive ?

tcpdump on both machines, and ping -s 2000 from both sides...

e100 driver seems VLAN enabled at a first glance.

Re: e100 + VLANs?

[Jeff Kirsher]

[-- Attachment #1: Type: text/plain, Size: 1968 bytes --]

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.
>> > 
>> > This appears to be a classical problems in this case -
>> > something forgot to allocate extra 4 bytes for the
>> > packets.
>> > 
>> > There's at least one bugreport from 2008 (!) about this
>> > very issue: http://bugs.centos.org/view.php?id=2719
>> > which is still open.
>> > 
>> > The kernel I tried this on was 2.6.32, I checked git log
>> > for drivers/net/e100.c - there was no changes up to
>> > current version which may be related to this issue.
>> > 
>> > The question: is this a driver problem or hardware? If
>> > it's the driver, can it be fixed? And if it's hardware,
>> > can the driver notify the user somehow - like, by refusing
>> > to enable VLAN (sub)devices maybe?
>> > 
>> > Yesterday it was actually a bit more complicated for me,
>> > since the card in question was used to connect to our
>> > ISP, and they use fixed MAC address per port, so I had
>> > to find another NIC which is a) able to work with VLAN
>> > tags properly, and b) is able to change its mac address.
>> > Lucky I had a VIA RhineIII which does both :)
>> > 
> Since you have two cards (and probably two machines), maybe you could
> try to track if the problem is a bad transmit or a bad receive ?
>
> tcpdump on both machines, and ping -s 2000 from both sides...
>
> 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?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: e100 + VLANs?

[David Lamparter]

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...


-equi

Re: e100 + VLANs?

[Michael Tokarev]

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

Re: e100 + VLANs?

[Eric Dumazet]

Le lundi 10 octobre 2011 à 18:57 +0400, Michael Tokarev a écrit :
> 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.

What the 'partner' setup looks like ?

ip link
ip addr
ip ro

Re: e100 + VLANs?

[David Lamparter]

On Mon, Oct 10, 2011 at 05:05:52PM +0200, Eric Dumazet wrote:
> > 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... ;)

Hmm. Looks like broken VLAN TX offload, but the driver doesn't even
implement VLAN offload. Maybe it's broken in its non-implementation...

Your "partner" is a known-good setup and can be assumed to be working
correctly? This is over a crossover cable, no evil switches involved?

> > 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.
> 
> What the 'partner' setup looks like ?
> 
> ip link
> ip addr
> ip ro

'local' setup too please :)


-David

Re: e100 + VLANs?

[Eric Dumazet]

Le lundi 10 octobre 2011 à 17:13 +0200, David Lamparter a écrit :
> On Mon, Oct 10, 2011 at 05:05:52PM +0200, Eric Dumazet wrote:
> > > 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... ;)
> 
> Hmm. Looks like broken VLAN TX offload, but the driver doesn't even
> implement VLAN offload. Maybe it's broken in its non-implementation...
> 
> Your "partner" is a known-good setup and can be assumed to be working
> correctly? This is over a crossover cable, no evil switches involved?
> 
> > > 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.
> > 
> > What the 'partner' setup looks like ?
> > 
> > ip link
> > ip addr
> > ip ro
> 
> 'local' setup too please :)

But here, the remote cleary sends an answer without VLAN tag ;)

Maybe its a tg3 (we had a buggy driver until very recent change), or
tcpdump is not up2date...

Re: e100 + VLANs?

[David Lamparter]

On Mon, Oct 10, 2011 at 05:23:55PM +0200, Eric Dumazet wrote:
> Le lundi 10 octobre 2011 à 17:13 +0200, David Lamparter a écrit :
> > On Mon, Oct 10, 2011 at 05:05:52PM +0200, Eric Dumazet wrote:
> > > > 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... ;)
> > 
> > Hmm. Looks like broken VLAN TX offload, but the driver doesn't even
> > implement VLAN offload. Maybe it's broken in its non-implementation...
> > 
> > Your "partner" is a known-good setup and can be assumed to be working
> > correctly? This is over a crossover cable, no evil switches involved?
> > 
> > > > 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.
> > > 
> > > What the 'partner' setup looks like ?
> > > 
> > > ip link
> > > ip addr
> > > ip ro
> > 
> > 'local' setup too please :)
> 
> But here, the remote cleary sends an answer without VLAN tag ;)

Huh? The remote sends the ARP request to ff:f..f:ff, which has a VLAN
tag in both dumps - but the packet sent from the e100 only has a tag in
its own tcpdump... so it might pretty much wind up on the wire without a
tag due to some TX bug...

-David

Re: e100 + VLANs?

[Eric Dumazet]

Le lundi 10 octobre 2011 à 17:28 +0200, David Lamparter a écrit :

> Huh? The remote sends the ARP request to ff:f..f:ff, which has a VLAN
> tag in both dumps - but the packet sent from the e100 only has a tag in
> its own tcpdump... so it might pretty much wind up on the wire without a
> tag due to some TX bug...
> 

I read the reverse from the mail.

But this is probably the reverse :

MAC address of partner : 00:1f:c6:ef:e5:1b  (ASUSTek prefix)

MAC address of e100 : 00:90:27:30:6d:1c

Re: e100 + VLANs?

[Michael Tokarev]

10.10.2011 19:13, David Lamparter wrote:
> On Mon, Oct 10, 2011 at 05:05:52PM +0200, Eric Dumazet wrote:
>>> 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... ;)
> 
> Hmm. Looks like broken VLAN TX offload, but the driver doesn't even
> implement VLAN offload. Maybe it's broken in its non-implementation...
> 
> Your "partner" is a known-good setup and can be assumed to be working
> correctly? This is over a crossover cable, no evil switches involved?

There are just two machines involved, both connected to the
same _switch_ - no, it is not over cross-over cable.  It's a
good idea to test one, I'll try it tomorrow (will insert a
second "known good" nic into another machine).

The second machine, the "partner", has this NIC:

02:00.0 Ethernet controller: Atheros Communications L1 Gigabit Ethernet (rev b0)

and it is a known-good implementation - it worked with and without vlan
tags (we had a weird mixed tagged/untagged setup) for over 2 years without
any issues, and which works now as well - it's our main server which is
in two VLANs, connected to an interface marked as tagged in the switch.
It communicates with the other machine when that other machine uses
already mentioned VIA RhineIII NIC - which I used to replace this non-working
E100.

So it's 2 machines, one with 2 nics - VIA Rhine (working) and e100 (non-working),
both connected to two "tagged" ports in the switch.  And another, with atl1 NIC,
also connected to a "tagged" port in the switch.

>>> 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.
>>
>> What the 'partner' setup looks like ?
>>
>> ip link
>> ip addr
>> ip ro

> 'local' setup too please :)

The setup is quite complex - there are numerous tunnels and virtual
interfaces.  Here are the relevant parts. (Note that `ip addr'
includes information present in `ip link'):

The "Partner" machine, with just one NIC, atl1, ip addr:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:1f:c6:ef:e5:1b brd ff:ff:ff:ff:ff:ff

3: tls-vlan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master tls-br state UP
    link/ether 00:1f:c6:ef:e5:1b brd ff:ff:ff:ff:ff:ff
Our main vlan, LAN, #1.

4: tls-br: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 00:1f:c6:ef:e5:1b brd ff:ff:ff:ff:ff:ff
    inet 192.168.177.15/26 brd 192.168.177.63 scope global tls-br
A bridge that connects this VLAN#1 and other stuff (virtual machines etc)

6: dmz-vlan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master dmz-br state UP
    link/ether 00:1f:c6:ef:e5:1b brd ff:ff:ff:ff:ff:ff
That's DMZ segment, VLAN#2
...

21: test@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 00:1f:c6:ef:e5:1b brd ff:ff:ff:ff:ff:ff
    inet 10.48.11.1/24 scope global test

This is vlan#5, my test vlan.


The machine with two (working, via-rhine, and non-working, e100):

2: ethx: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:90:27:30:6d:1c brd ff:ff:ff:ff:ff:ff
This is via-rhine, with the MAC address of E100 -- the one which works.

13: eth-tls@ethx: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 00:90:27:30:6d:1c brd ff:ff:ff:ff:ff:ff
    inet 192.168.177.5/26 brd 192.168.177.63 scope global eth-tls
Our main VLAN#1 (here it's w/o bridge)

14: eth-dmz@ethx: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 00:90:27:30:6d:1c brd ff:ff:ff:ff:ff:ff
    inet 192.168.177.225/29 brd 192.168.177.231 scope global eth-dmz
DMZ VLAN#2

4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:90:27:30:6d:1c brd ff:ff:ff:ff:ff:ff

The non-working e100.  Here it has the same MAC address as ethx above,
because I explicitly changed ethx to have this MAC, since the $ISP has
it hardcoded for our port on their side.  The tests were done with the
two addresses being original as set up by the hardware, and later on
I also tried to set this MAC to be 00:90:27:30:6d:1d (note the last
digit) - all the same result, packets sent over the iface above shows
on the receiving side as having no vlan tag.

24: test@eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 00:90:27:30:6d:1c brd ff:ff:ff:ff:ff:ff
    inet 10.48.11.2/24 scope global test

And finally this is the test vlan#5.

tcpdump was run on eth2 here and on eth0 on the first machine.

On both machines tcpdump is of version 4.1.1.

Here's offload information for e100 nic:

# ethtool -k eth2
Offload parameters for eth2:
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off
ntuple-filters: off
receive-hashing: off

It supports (or appears to) some offloading, in particular I
can enable GSO offload, and it even works somehow.


Now, I enabled another pair of VLAN interfaces on these two NICs,
with VLAN#6, and configured both ports in the switch to be parts
of VLAN6 too (tagged).  And voila, everything now works in there.

Two ifaces added, "partner", atl1:

22: test6@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
    link/ether 00:1f:c6:ef:e5:1b brd ff:ff:ff:ff:ff:ff
    inet 10.48.6.1/24 scope global test6

this e100:

25: test6@eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
    link/ether 00:90:27:30:6d:1c brd ff:ff:ff:ff:ff:ff
    inet 10.48.6.2/24 scope global test6

Yesterday, the vlan ID where it didn't work was #4, and in #1 it all -
apparently - worked.

I created 2 more pairs of VLAN interfaces and added to the swithc --
it all works just fine.  Here:

# x=8; ip link add link eth2 name test$x type vlan id $x; ip addr add 10.48.$x.2/24 dev test$x; ip link set test$x up

(That's on the e100 side, similar was on atl1 side).  x=6, x=7 and x=8
works just fine.  x=5 does not, ARP replies arrives without VLAN tag
to the atl1 side.

Ok.  So now I can reproduce the initial problem.

So, `ping -s 1469' from atl1 side, so that the resulting packet side
is 1497 bytes (1468 is the largest size that works) -- the packets
does not arrive at e100 side at all - it's 100% quiet in tcpdump there.

When pinging from e100 side and tcpdump'ing on atl1 side (replies does
not come back to e100):

20:49:33.322646 00:90:27:30:6d:1c > 00:1f:c6:ef:e5:1b, ethertype 802.1Q (0x8100), length 1515: vlan 8, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1497)
    10.48.8.2 > 10.48.8.1: ICMP echo request, id 5785, seq 72, length 1477
20:49:33.322691 00:1f:c6:ef:e5:1b > 00:90:27:30:6d:1c, ethertype 802.1Q (0x8100), length 1515: vlan 8, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 23781, offset 0, flags [none], proto ICMP (1), length 1497)
    10.48.8.1 > 10.48.8.2: ICMP echo reply, id 5785, seq 72, length 1477

So it appears that on e100 side, the _receive_ buffer is too small
somehow.

I'll do some more experiments with VLAN#5 tomorrow, in a clean environment
(maybe using direct cable connection - not cross-over, since GigE should
autodetect this stuff (hopefully)).

Thanks!

/mjt

Re: e100 + VLANs?

[Michael Tokarev]

10.10.2011 20:51, Michael Tokarev wrote:
> 10.10.2011 19:13, David Lamparter wrote:
>> On Mon, Oct 10, 2011 at 05:05:52PM +0200, Eric Dumazet wrote:
>>>> 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... ;)
>>
>> Hmm. Looks like broken VLAN TX offload, but the driver doesn't even
>> implement VLAN offload. Maybe it's broken in its non-implementation...
>>
>> Your "partner" is a known-good setup and can be assumed to be working
>> correctly? This is over a crossover cable, no evil switches involved?
> 
> There are just two machines involved, both connected to the
> same _switch_ - no, it is not over cross-over cable.  It's a
> good idea to test one, I'll try it tomorrow (will insert a
> second "known good" nic into another machine).

Ok, I found the issue - it was my misconfiguration of vlan5 in the
switch.  So tags are correctly set and processed by e100 NIC and
the driver.

I tried direct (without a switch) connection, and it shows the same
problem - the MTU issues, large packets does not work, exactly as
shown below...

> The second machine, the "partner", has this NIC:
> 
> 02:00.0 Ethernet controller: Atheros Communications L1 Gigabit Ethernet (rev b0)
> 
> and it is a known-good implementation - it worked with and without vlan
> tags (we had a weird mixed tagged/untagged setup) for over 2 years without
> any issues, and which works now as well - it's our main server which is
> in two VLANs, connected to an interface marked as tagged in the switch.
> It communicates with the other machine when that other machine uses
> already mentioned VIA RhineIII NIC - which I used to replace this non-working
> E100.
> 
> So it's 2 machines, one with 2 nics - VIA Rhine (working) and e100 (non-working),
> both connected to two "tagged" ports in the switch.  And another, with atl1 NIC,
> also connected to a "tagged" port in the switch.
[]
> Ok.  So now I can reproduce the initial problem.
> 
> So, `ping -s 1469' from atl1 side, so that the resulting packet side
s/side/size/

> is 1497 bytes (1468 is the largest size that works) -- the packets
> does not arrive at e100 side at all - it's 100% quiet in tcpdump there.
> 
> When pinging from e100 side and tcpdump'ing on atl1 side (replies does
> not come back to e100):
> 
> 20:49:33.322646 00:90:27:30:6d:1c > 00:1f:c6:ef:e5:1b, ethertype 802.1Q (0x8100), length 1515: vlan 8, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1497)
>     10.48.8.2 > 10.48.8.1: ICMP echo request, id 5785, seq 72, length 1477
> 20:49:33.322691 00:1f:c6:ef:e5:1b > 00:90:27:30:6d:1c, ethertype 802.1Q (0x8100), length 1515: vlan 8, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 23781, offset 0, flags [none], proto ICMP (1), length 1497)
>     10.48.8.1 > 10.48.8.2: ICMP echo reply, id 5785, seq 72, length 1477
> 
> So it appears that on e100 side, the _receive_ buffer is too small
> somehow.

So, is that a hardware limitation?

Thank you!

/mjt

Re: e100 + VLANs?

[Eric Dumazet]

[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]

> So, is that a hardware limitation?

Its a driver bug

This comes from fact that sizeof(struct rfd) = 16

and VLAN_ETH_FRAME_LEN is 1518

driver mixes VLAN_ETH_FRAME_LEN and 1500+4+sizeof(struct rfd)   (1520, not 1518)

It therefore misses 2 bytes for large frames (VLAN tagged)

Fix is to remove VLAN_ETH_FRAME_LEN references for good...

diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index c1352c6..3287d31 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -435,6 +435,7 @@ struct rfd {
        __le16 actual_size;
        __le16 size;
 };
+#define RFD_BUF_LEN (sizeof(struct rfd) + ETH_DATA_LEN + VLAN_HLEN)

 struct rx {
        struct rx *next, *prev;
@@ -1075,7 +1076,7 @@ static void e100_get_defaults(struct nic *nic)
        /* Template for a freshly allocated RFD */
        nic->blank_rfd.command = 0;
        nic->blank_rfd.rbd = cpu_to_le32(0xFFFFFFFF);
-       nic->blank_rfd.size = cpu_to_le16(VLAN_ETH_FRAME_LEN);
+       nic->blank_rfd.size = cpu_to_le16(RFD_BUF_LEN);

        /* MII setup */
        nic->mii.phy_id_mask = 0x1F;
@@ -1881,7 +1882,6 @@ static inline void e100_start_receiver(struct
nic *nic, struct rx *rx)
        }
 }

-#define RFD_BUF_LEN (sizeof(struct rfd) + VLAN_ETH_FRAME_LEN)
 static int e100_rx_alloc_skb(struct nic *nic, struct rx *rx)
 {
        if (!(rx->skb = netdev_alloc_skb_ip_align(nic->netdev, RFD_BUF_LEN)))
@@ -2058,7 +2058,7 @@ static void e100_rx_clean(struct nic *nic,
unsigned int *work_done,
                pci_dma_sync_single_for_device(nic->pdev,
                        old_before_last_rx->dma_addr, sizeof(struct rfd),
                        PCI_DMA_BIDIRECTIONAL);
-               old_before_last_rfd->size = cpu_to_le16(VLAN_ETH_FRAME_LEN);
+               old_before_last_rfd->size = cpu_to_le16(RFD_BUF_LEN);
                pci_dma_sync_single_for_device(nic->pdev,
                        old_before_last_rx->dma_addr, sizeof(struct rfd),
                        PCI_DMA_BIDIRECTIONAL);

[-- Attachment #2: patch --]
[-- Type: application/octet-stream, Size: 1434 bytes --]

diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index c1352c6..3287d31 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -435,6 +435,7 @@ struct rfd {
 	__le16 actual_size;
 	__le16 size;
 };
+#define RFD_BUF_LEN (sizeof(struct rfd) + ETH_DATA_LEN + VLAN_HLEN)
 
 struct rx {
 	struct rx *next, *prev;
@@ -1075,7 +1076,7 @@ static void e100_get_defaults(struct nic *nic)
 	/* Template for a freshly allocated RFD */
 	nic->blank_rfd.command = 0;
 	nic->blank_rfd.rbd = cpu_to_le32(0xFFFFFFFF);
-	nic->blank_rfd.size = cpu_to_le16(VLAN_ETH_FRAME_LEN);
+	nic->blank_rfd.size = cpu_to_le16(RFD_BUF_LEN);
 
 	/* MII setup */
 	nic->mii.phy_id_mask = 0x1F;
@@ -1881,7 +1882,6 @@ static inline void e100_start_receiver(struct nic *nic, struct rx *rx)
 	}
 }
 
-#define RFD_BUF_LEN (sizeof(struct rfd) + VLAN_ETH_FRAME_LEN)
 static int e100_rx_alloc_skb(struct nic *nic, struct rx *rx)
 {
 	if (!(rx->skb = netdev_alloc_skb_ip_align(nic->netdev, RFD_BUF_LEN)))
@@ -2058,7 +2058,7 @@ static void e100_rx_clean(struct nic *nic, unsigned int *work_done,
 		pci_dma_sync_single_for_device(nic->pdev,
 			old_before_last_rx->dma_addr, sizeof(struct rfd),
 			PCI_DMA_BIDIRECTIONAL);
-		old_before_last_rfd->size = cpu_to_le16(VLAN_ETH_FRAME_LEN);
+		old_before_last_rfd->size = cpu_to_le16(RFD_BUF_LEN);
 		pci_dma_sync_single_for_device(nic->pdev,
 			old_before_last_rx->dma_addr, sizeof(struct rfd),
 			PCI_DMA_BIDIRECTIONAL);

Re: e100 + VLANs?

[Michael Tokarev]

11.10.2011 15:25, Eric Dumazet wrote:
>> So, is that a hardware limitation?
> 
> Its a driver bug
> 
> This comes from fact that sizeof(struct rfd) = 16
> 
> and VLAN_ETH_FRAME_LEN is 1518
> 
> driver mixes VLAN_ETH_FRAME_LEN and 1500+4+sizeof(struct rfd)   (1520, not 1518)
> 
> It therefore misses 2 bytes for large frames (VLAN tagged)
> 
> Fix is to remove VLAN_ETH_FRAME_LEN references for good...
> 
> diff --git a/drivers/net/e100.c b/drivers/net/e100.c
> index c1352c6..3287d31 100644

Hmm.  This does not _exactly_ work.

I applied it on top of 2.6.32, patch applied but with some fuzz - I checked
manually and it appears to be ok.

Now, with this patch applied, I see on the e100 side:

00:1f:c6:ef:e5:1b > 00:90:27:30:6d:1c, ethertype 802.1Q (0x8100), length 1504: vlan 6, p 0, ethertype IPv4, truncated-ip - 1 bytes missing! (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1487)
    10.48.6.1 > 10.48.6.2: ICMP echo request, id 27613, seq 6, length 1467

when pinging it with -s 1459 (1487 total size).

I added extra +40 for RFD_BUF_LEN define and recompiled
(this resulted in RFD_BUF_LEN=1560, - I've added a printk
just to be sure).

Now I see the same effect as before the patch:  maximum
packet size that goes and can be seen on the e100 side
is 1468(1496) (ping), which results in this on e100 side:

15:54:44.830941 00:1f:c6:ef:e5:1b > 00:90:27:30:6d:1c, ethertype 802.1Q (0x8100), length 1514: vlan 6, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1496)
    10.48.6.1 > 10.48.6.2: ICMP echo request, id 28735, seq 4, length 1476
15:54:44.831025 00:90:27:30:6d:1c > 00:1f:c6:ef:e5:1b, ethertype 802.1Q (0x8100), length 1514: vlan 6, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 12010, offset 0, flags [none], proto ICMP (1), length 1496)
    10.48.6.2 > 10.48.6.1: ICMP echo reply, id 28735, seq 4, length 1476

(and it works).  With -s 1469, no ICMP packets can be seen
on e100 side.

So it still may be the hardware... :)

Thank you!

/mjt

Re: e100 + VLANs?

[Eric Dumazet]

Le mardi 11 octobre 2011 à 15:59 +0400, Michael Tokarev a écrit :

> Hmm.  This does not _exactly_ work.
> 
> I applied it on top of 2.6.32, patch applied but with some fuzz - I checked
> manually and it appears to be ok.
> 
> Now, with this patch applied, I see on the e100 side:
> 
> 00:1f:c6:ef:e5:1b > 00:90:27:30:6d:1c, ethertype 802.1Q (0x8100), length 1504: vlan 6, p 0, ethertype IPv4, truncated-ip - 1 bytes missing! (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1487)
>     10.48.6.1 > 10.48.6.2: ICMP echo request, id 27613, seq 6, length 1467
> 
> when pinging it with -s 1459 (1487 total size).
> 
> I added extra +40 for RFD_BUF_LEN define and recompiled
> (this resulted in RFD_BUF_LEN=1560, - I've added a printk
> just to be sure).
> 
> Now I see the same effect as before the patch:  maximum
> packet size that goes and can be seen on the e100 side
> is 1468(1496) (ping), which results in this on e100 side:
> 
> 15:54:44.830941 00:1f:c6:ef:e5:1b > 00:90:27:30:6d:1c, ethertype 802.1Q (0x8100), length 1514: vlan 6, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1496)
>     10.48.6.1 > 10.48.6.2: ICMP echo request, id 28735, seq 4, length 1476
> 15:54:44.831025 00:90:27:30:6d:1c > 00:1f:c6:ef:e5:1b, ethertype 802.1Q (0x8100), length 1514: vlan 6, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 12010, offset 0, flags [none], proto ICMP (1), length 1496)
>     10.48.6.2 > 10.48.6.1: ICMP echo reply, id 28735, seq 4, length 1476
> 
> (and it works).  With -s 1469, no ICMP packets can be seen
> on e100 side.
> 
> So it still may be the hardware... :)

Yes, my patch was not needed, I was not sure sizeof(struct rfd) was
included or not in the rfd.size setting (apparently its not needed)

Any counters increase in "ethtool -S eth0" ?

Re: e100 + VLANs?

[Michael Tokarev]

11.10.2011 16:04, Eric Dumazet wrote:
> Le mardi 11 octobre 2011 à 15:59 +0400, Michael Tokarev a écrit :
[]
>> (and it works).  With -s 1469, no ICMP packets can be seen
>> on e100 side.
>>
>> So it still may be the hardware... :)
>
> Yes, my patch was not needed, I was not sure sizeof(struct rfd) was
> included or not in the rfd.size setting (apparently its not needed)

Ok, good to know!

> Any counters increase in "ethtool -S eth0" ?

None at all.  Number of interrupts gets increased by 2 about every
2 seconds, even when the other side is doing ping -f, or not pinging
at all.

So it looks like the card merely ignores these packets.

So little result for so much efforts... :(

But it is not really that bad I think - it is an obsolete hardware.

Thank you for all the help!

/mjt

Re: e100 + VLANs?

[David Lamparter]

On Tue, Oct 11, 2011 at 04:56:23PM +0400, Michael Tokarev wrote:
> So it looks like the card merely ignores these packets.
> 
> So little result for so much efforts... :(
> 
> But it is not really that bad I think - it is an obsolete hardware.

The knowledge and code for this is actually around line 1142 of e100.c:
        if (nic->mac >= mac_82558_D101_A4) {
                config->fc_disable = 0x1;       /* 1=Tx fc off, 0=Tx fc on */
                config->mwi_enable = 0x1;       /* 1=enable, 0=disable */
                config->standard_tcb = 0x0;     /* 1=standard, 0=extended */
                config->rx_long_ok = 0x1;       /* 1=VLANs ok, 0=standard */

where rx_long_ok is the configuration bit to enable frame reception
for >1514 byte frames. I guess your card is < mac_82558_D101_A4...

(cf. "Intel 8255x 10/100 Mbps Ethernet Controller Family Open Source
Software Developer Manual" page 78/86 - "Long Receive OK. This bit is
reserved on the 82557 and should be set to 0. When this bit is set on
the 82558 or 82559, the device considers received frames that have
a data field longer than 1500 bytes as good frames.")


-David

Re: e100 + VLANs?

[Jesse Brandeburg]

[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]

On Tue, 11 Oct 2011 08:29:18 -0700
David Lamparter <equinox@diac24.net> wrote:

> On Tue, Oct 11, 2011 at 04:56:23PM +0400, Michael Tokarev wrote:
> > So it looks like the card merely ignores these packets.
> > 
> > So little result for so much efforts... :(
> > 
> > But it is not really that bad I think - it is an obsolete hardware.
> 
> The knowledge and code for this is actually around line 1142 of e100.c:
>         if (nic->mac >= mac_82558_D101_A4) {
>                 config->fc_disable = 0x1;       /* 1=Tx fc off, 0=Tx fc on */
>                 config->mwi_enable = 0x1;       /* 1=enable, 0=disable */
>                 config->standard_tcb = 0x0;     /* 1=standard, 0=extended */
>                 config->rx_long_ok = 0x1;       /* 1=VLANs ok, 0=standard */
> 
> where rx_long_ok is the configuration bit to enable frame reception
> for >1514 byte frames. I guess your card is < mac_82558_D101_A4...
> 
> (cf. "Intel 8255x 10/100 Mbps Ethernet Controller Family Open Source
> Software Developer Manual" page 78/86 - "Long Receive OK. This bit is
> reserved on the 82557 and should be set to 0. When this bit is set on
> the 82558 or 82559, the device considers received frames that have
> a data field longer than 1500 bytes as good frames.")

David, thank you for posting that, while you were typing I was
researching the same thing, so FWIW, I concur with your conclusion.

ouch, OP your hardware is really really old:
> 00:12.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 02)
> Subsystem: Intel Corporation EtherExpress PRO/100B (TX)

rev 2 is D100_C, which is 82557.

the hardware is NOT capable of long receives (i.e. vlan packets).
If it was then they should generally fit in the receive buffer and be
handled and not discarded.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: e100 + VLANs?

[Michael Tokarev]

On 12.10.2011 03:38, Jesse Brandeburg wrote:
[..]
>> The knowledge and code for this is actually around line 1142 of e100.c:
>>         if (nic->mac >= mac_82558_D101_A4) {
>>                 config->fc_disable = 0x1;       /* 1=Tx fc off, 0=Tx fc on */
>>                 config->mwi_enable = 0x1;       /* 1=enable, 0=disable */
>>                 config->standard_tcb = 0x0;     /* 1=standard, 0=extended */
>>                 config->rx_long_ok = 0x1;       /* 1=VLANs ok, 0=standard */
>>
>> where rx_long_ok is the configuration bit to enable frame reception
>> for >1514 byte frames. I guess your card is < mac_82558_D101_A4...
>>
>> (cf. "Intel 8255x 10/100 Mbps Ethernet Controller Family Open Source
>> Software Developer Manual" page 78/86 - "Long Receive OK. This bit is
>> reserved on the 82557 and should be set to 0. When this bit is set on
>> the 82558 or 82559, the device considers received frames that have
>> a data field longer than 1500 bytes as good frames.")
> 
> David, thank you for posting that, while you were typing I was
> researching the same thing, so FWIW, I concur with your conclusion.
> 
> ouch, OP your hardware is really really old:
>> 00:12.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 02)
>> Subsystem: Intel Corporation EtherExpress PRO/100B (TX)
> 
> rev 2 is D100_C, which is 82557.
> 
> the hardware is NOT capable of long receives (i.e. vlan packets).
> If it was then they should generally fit in the receive buffer and be
> handled and not discarded.

Can this knowlege be added to the driver somehow, so that others
will not hit the same trap as I did? :)  _If_ there's any value
in that (I guess there aren't many users with that hardware left),
and if that's easy to do ofcourse... ;)

Thanks!

/mjt