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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 7 Jul 2008 23:40:58 +0200 (CEST)
From:	Krzysztof Oledzki <olel@....pl>
To:	Patrick McHardy <kaber@...sh.net>
cc:	netdev@...r.kernel.org, greearb@...delatech.com
Subject: Re: Wrong padding of short packets send by a tagged-vlan interface?



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