Subject: kern/22459: Packets received through sip are too long
To: None <gnats-bugs@gnats.netbsd.org>
From: Valtteri Vuorikoski <vuori@puuhamaa.magenta.net>
List: netbsd-bugs
Date: 08/12/2003 23:55:43
>Number:         22459
>Category:       kern
>Synopsis:       Packets received through sip are too long
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Aug 12 20:56:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Valtteri Vuorikoski
>Release:        NetBSD 1.6.1_STABLE
>Organization:
>Environment:
System: NetBSD soekris 1.6.1_STABLE NetBSD 1.6.1_STABLE (SOEKRIS) #14: Mon Aug 11 23:55:23 UTC
2003 vuori@tunkmenistan:/usr/src/sys/arch/i386/compile/SOEKRIS i386                    

Updated from AnonCVS Aug 10. Also tested -current as of Aug 12.

>Description:

Packets received through a sip interface on a Soekris net4501 seem to
have 4 bytes too much data. This is visible in a non-harmful manner
when running dhclient:

Listening on BPF/sip0/00:00:24:c0:2e:64
Sending on   BPF/sip0/00:00:24:c0:2e:64
Sending on   Socket/fallback
DHCPREQUEST on sip0 to 255.255.255.255 port 67
ip length 328 disagrees with bytes received 332.
accepting packet with data after udp payload.
DHCPACK from 62.78.149.1
New Network Number: 62.78.149.0
New Broadcast Address: 62.78.149.255
bound to 62.78.149.153 -- renewal in 8724 seconds.

Elsewhere I have same boxen running a late-2002 1.6_STABLE which are
unable to handle 1500 byte VLAN-tagged packets, claiming that they
are too long (again 4 bytes extra). I haven't had a chance to test
these with a newer kernel, but if the problem still affects VLANs on
newer kernels, this severely impairs the usefulness of VLAN trunks
with these boxes.

tcpdump of DHCP traffic shows an ethernet frame of 346 bytes an ip len
328, leaving the 4 bytes unaccounted for. The extra bytes also appear
in other traffic coming through a sip interface. They appear to contain
random data.

Another box with a tlp interface does not show these extra bytes and
has no problems with VLAN trunks.

>How-To-Repeat:

Run dhclient on affected hardware. Note warning. Alternatively, ping -s 1500
someone and tcpdump -ve icmp. Note 1518 byte return frames.

>Fix:

Unknown.

>Release-Note:
>Audit-Trail:
>Unformatted: