[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 7 Jul 2008 23:01:29 +0200 (CEST)
From: Krzysztof Oledzki <olel@....pl>
To: netdev@...r.kernel.org
cc: kaber@...sh.net, greearb@...delatech.com
Subject: Wrong padding of short packets send by a tagged-vlan interface?
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
Powered by blists - more mailing lists