Wrong padding of short packets send by a tagged-vlan interface?

Wrong padding of short packets send by a tagged-vlan interface?

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1732 bytes --]

Hello,

I have a problem that I'm not able to connect from selected linux hosts to 
a newly installed Netware 6.5 server. After two days of debugging I 
discovered that the problem seems to be caused by an insufficient padding 
of a .1q tagged packets.

Currently, if a packet is too short, it is extended to 60(+4) octets for 
both untagged and tagged ones. Unfortunately, when a .1Q tag is removed on 
a receive side, such packet is likely to be dropped as it may become too 
short (56 bytes):

This is a normal (working) ping with 84B (IP) + 14B (eth hdr) = 98B octets:
# ping -c 2 192.168.0.194
PING 192.168.0.194 (192.168.0.194) 56(84) bytes of data.
64 bytes from 192.168.0.194: icmp_seq=1 ttl=128 time=0.137 ms
64 bytes from 192.168.0.194: icmp_seq=2 ttl=128 time=0.141 ms

This is a shorter (working) ping with 46 (IP) + 14B (eth hdr) = 60B octets:
# ping -c 2 192.168.0.194 -s 18
PING 192.168.0.194 (192.168.0.194) 18(46) bytes of data.
26 bytes from 192.168.0.194: icmp_seq=1 ttl=128 time=0.137 ms
26 bytes from 192.168.0.194: icmp_seq=2 ttl=128 time=0.144 ms

This one does not work (45+14 = 59): 
# ping -c 2 192.168.0.194 -s 17
PING 192.168.0.194 (192.168.0.194) 17(45) bytes of data.

--- 192.168.0.194 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

I believe that my problem can be solved if we start padding .1Q packets 
with 4 more octets but I'm not able to find a proper place where to fix 
it.

I also found a very similar report:
  http://mail.opensolaris.org/pipermail/networking-discuss/2007-March/014585.html
  http://mail.opensolaris.org/pipermail/networking-discuss/2007-March/014588.html

Best regards,

 				Krzysztof Olędzki

Re: Wrong padding of short packets send by a tagged-vlan interface?

[Patrick McHardy]

Krzysztof Oledzki wrote:
> Hello,
> 
> I have a problem that I'm not able to connect from selected linux hosts 
> to a newly installed Netware 6.5 server. After two days of debugging I 
> discovered that the problem seems to be caused by an insufficient 
> padding of a .1q tagged packets.
> 
> Currently, if a packet is too short, it is extended to 60(+4) octets for 
> both untagged and tagged ones. Unfortunately, when a .1Q tag is removed 
> on a receive side, such packet is likely to be dropped as it may become 
> too short (56 bytes):
> 
> This is a normal (working) ping with 84B (IP) + 14B (eth hdr) = 98B octets:
> # ping -c 2 192.168.0.194
> PING 192.168.0.194 (192.168.0.194) 56(84) bytes of data.
> 64 bytes from 192.168.0.194: icmp_seq=1 ttl=128 time=0.137 ms
> 64 bytes from 192.168.0.194: icmp_seq=2 ttl=128 time=0.141 ms
> 
> This is a shorter (working) ping with 46 (IP) + 14B (eth hdr) = 60B octets:
> # ping -c 2 192.168.0.194 -s 18
> PING 192.168.0.194 (192.168.0.194) 18(46) bytes of data.
> 26 bytes from 192.168.0.194: icmp_seq=1 ttl=128 time=0.137 ms
> 26 bytes from 192.168.0.194: icmp_seq=2 ttl=128 time=0.144 ms
> 
> This one does not work (45+14 = 59): # ping -c 2 192.168.0.194 -s 17
> PING 192.168.0.194 (192.168.0.194) 17(45) bytes of data.
> 
> --- 192.168.0.194 ping statistics ---
> 2 packets transmitted, 0 received, 100% packet loss, time 999ms
> 
> I believe that my problem can be solved if we start padding .1Q packets 
> with 4 more octets but I'm not able to find a proper place where to fix it.

Nice catch, if this really is the problem :) For a fix I'd suggest to
add a skb_ether_pad() function that performs the necessary padding
depending on skb->protocol and change the ethernet drivers to use it
instead of skb_padto().

Re: Wrong padding of short packets send by a tagged-vlan interface?

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2078 bytes --]



On Mon, 7 Jul 2008, Patrick McHardy wrote:

> Krzysztof Oledzki wrote:
>> Hello,
>> 
>> I have a problem that I'm not able to connect from selected linux hosts to 
>> a newly installed Netware 6.5 server. After two days of debugging I 
>> discovered that the problem seems to be caused by an insufficient padding 
>> of a .1q tagged packets.
>> 
>> Currently, if a packet is too short, it is extended to 60(+4) octets for 
>> both untagged and tagged ones. Unfortunately, when a .1Q tag is removed on 
>> a receive side, such packet is likely to be dropped as it may become too 
>> short (56 bytes):
>> 
>> This is a normal (working) ping with 84B (IP) + 14B (eth hdr) = 98B octets:
>> # ping -c 2 192.168.0.194
>> PING 192.168.0.194 (192.168.0.194) 56(84) bytes of data.
>> 64 bytes from 192.168.0.194: icmp_seq=1 ttl=128 time=0.137 ms
>> 64 bytes from 192.168.0.194: icmp_seq=2 ttl=128 time=0.141 ms
>> 
>> This is a shorter (working) ping with 46 (IP) + 14B (eth hdr) = 60B octets:
>> # ping -c 2 192.168.0.194 -s 18
>> PING 192.168.0.194 (192.168.0.194) 18(46) bytes of data.
>> 26 bytes from 192.168.0.194: icmp_seq=1 ttl=128 time=0.137 ms
>> 26 bytes from 192.168.0.194: icmp_seq=2 ttl=128 time=0.144 ms
>> 
>> This one does not work (45+14 = 59): # ping -c 2 192.168.0.194 -s 17
>> PING 192.168.0.194 (192.168.0.194) 17(45) bytes of data.
>> 
>> --- 192.168.0.194 ping statistics ---
>> 2 packets transmitted, 0 received, 100% packet loss, time 999ms
>> 
>> I believe that my problem can be solved if we start padding .1Q packets 
>> with 4 more octets but I'm not able to find a proper place where to fix it.
>
> Nice catch, if this really is the problem :) For a fix I'd suggest to
> add a skb_ether_pad() function that performs the necessary padding
> depending on skb->protocol and change the ethernet drivers to use it
> instead of skb_padto().

Not all drivers use skb_padto:

# grep skb_padto -R e1000 e1000e bnx*.c
(empty)

Any idea where to change it in the above ones?

Best regards,

 				Krzysztof Olędzki

Re: Wrong padding of short packets send by a tagged-vlan interface?

[David Miller]

From: Krzysztof Oledzki <olel@ans.pl>
Date: Mon, 7 Jul 2008 23:40:58 +0200 (CEST)

> Not all drivers use skb_padto:
> 
> # grep skb_padto -R e1000 e1000e bnx*.c
> (empty)
> 
> Any idea where to change it in the above ones?

They don't need to, most devices handle this issue
in hardware as far as I understand.

Re: Wrong padding of short packets send by a tagged-vlan interface?

[Ben Greear]

Krzysztof Oledzki wrote:
> Hello,
> 
> I have a problem that I'm not able to connect from selected linux hosts 
> to a newly installed Netware 6.5 server. After two days of debugging I 
> discovered that the problem seems to be caused by an insufficient 
> padding of a .1q tagged packets.

Last time this came up I looked up the RFC and according to it
there is no need to pad beyond the normal 60 + 4, vlan tag or
not.

This is a bug in your intervening switch and/or Netware unless you actually see packets
leaving Linux with less than 60 + 4 bytes.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Wrong padding of short packets send by a tagged-vlan interface?

[Patrick McHardy]

Ben Greear wrote:
> Krzysztof Oledzki wrote:
>> Hello,
>>
>> I have a problem that I'm not able to connect from selected linux 
>> hosts to a newly installed Netware 6.5 server. After two days of 
>> debugging I discovered that the problem seems to be caused by an 
>> insufficient padding of a .1q tagged packets.
> 
> Last time this came up I looked up the RFC and according to it
> there is no need to pad beyond the normal 60 + 4, vlan tag or
> not.
> 
> This is a bug in your intervening switch and/or Netware unless you 
> actually see packets
> leaving Linux with less than 60 + 4 bytes.

Yes, its probably not on the Linux side. It would be interesting
to know where exactly the bug is happening though.

Re: Wrong padding of short packets send by a tagged-vlan interface?

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1352 bytes --]



On Mon, 7 Jul 2008, Ben Greear wrote:

> Krzysztof Oledzki wrote:
>> Hello,
>> 
>> I have a problem that I'm not able to connect from selected linux hosts to 
>> a newly installed Netware 6.5 server. After two days of debugging I 
>> discovered that the problem seems to be caused by an insufficient padding 
>> of a .1q tagged packets.
>
> Last time this came up I looked up the RFC and according to it
> there is no need to pad beyond the normal 60 + 4, vlan tag or
> not.
>
> This is a bug in your intervening switch and/or Netware unless you actually 
> see packets
> leaving Linux with less than 60 + 4 bytes.

Rather a Broadcom Corporation NetXtreme II driver "feature" as AFAIK 
Netware 6.5 does not support .1Q natively and vlans are implemented 
directly in network drivers, especially that everything worked with a 
previous hardware (Intel 82541GI based).

So yes, it may not be a Linux bug but it would be nice to make Linux more 
compatible with such configurations, of course if that is possible. Please 
also note that this problem does not exists with Netware<->Netware 
communication (both NetXtreme II<->NetXtreme II and 82541GI<->NetXtreme 
II) so it seems that both Intel and Broadcom supports the "extened" 
padding of .1Q packets in their Netware drivers.

Best regards,

 				Krzysztof Olędzki