NetBSD Problem Report #15360

Received: (qmail 19515 invoked from network); 25 Jan 2002 11:32:23 -0000
Message-Id: <200201251132.g0PBWK925819@dslab8.cs.uit.no>
Date: Fri, 25 Jan 2002 12:32:21 +0100 (CET)
From: frodef@stud.cs.uit.no
Reply-To: frodef@stud.cs.uit.no
To: gnats-bugs@gnats.netbsd.org
Subject: NetBSD emits erroneous IPv6 neighbor solicitation packet.
X-Send-Pr-Version: 3.95

>Number:         15360
>Category:       kern
>Synopsis:       NetBSD emits erroneous IPv6 neighbor solicitation packet.
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jan 25 11:33:01 +0000 2002
>Closed-Date:    Sat Mar 24 08:05:05 +0000 2018
>Last-Modified:  Sat Mar 24 08:05:05 +0000 2018
>Originator:     Frode V. Fjeld
>Release:        NetBSD 1.5.2
>Organization:
	Univ. of Tromsoe, Norway
>Environment:
System: NetBSD dslab8 1.5.2 NetBSD 1.5.2 (FVF-KONTOR) #7: Wed Oct 3 19:04:15 CEST 2001 frodef@dslab8:/usr/src/sys/arch/i386/compile/FVF-KONTOR i386
Architecture: i386
Machine: i386
>Description:
	I'm observing with tcpdump the following packet emitted from this
NetBSD machine:

11:49:35.575991 0:1:3:40:d0:94 0:40:5:18:66:d8 ip6 172: fe80::201:3ff:fe40:d094 > fe80::240:5ff:fe18:66d8: icmp6: neighbor sol: who has fe80::240:5ff:fe18:66
d8
0x0000   6000 0000 0076 3aff fe80 0000 0000 0000        `....v:.........
0x0010   0201 03ff fe40 d094 fe80 0000 0000 0000        .....@..........
0x0020   0240 05ff fe18 66d8 8700 0220 0000 0000        .@....f.........
0x0030   fe80 0000 0000 0000 0240 05ff fe18 66d8        .........@....f.
0x0040   0101 0001 0340 d094 0001 0340 d094 0000        .....@.....@....
0x0050   0000

This solicitation packet looks precisely like the regular solicitation
packets, except it is 172 bytes long rather than the normal 86 (i.e. IP
payload is 118 bytes rather than 32). Not all the extra data is included in
the dump above, but what can be seen is one neighbor discovery option type #0,
which is an invalid value (by RFC 2461, sec. 4.6), and then an option of
type #0 and length 0, which both are invalid. I suppose this is really
just random trash data, and that the actual error is that the packet length
is set to 172/118 rather than the correct 86/32. This suggests a bug in
either the ICMPv6 or IPv6 code.

>How-To-Repeat:
	It is difficult to consistently trigger this packet, but it seems
to happen mostly when I ping some machine (from the NetBSD box) and then
while pinging I halt the target machine for a few seconds before restarting it.
>Fix:
	Correct IPv6 stacks should discard this erroneous packet, so no
particular fix is strictly necessary. But this could be the symptom of a
potentially serious bug in the NetBSD IPv6 stack, so it probably should be
corrected, if anyone is able to reproduce this at all.. :)
>Release-Note:
>Audit-Trail:

From: Frode Vatvedt Fjeld <frodef@acm.org>
To: gnats-bugs@netbsd.org
Cc:  
Subject: Re: kern/15360: NetBSD emits erroneous IPv6 neighbor solicitation
 packet.
Date: Fri, 25 Jan 2002 14:50:50 +0100

 This is a followup to my earlier bug report.

 The problem seems to be slightly more serious than I first thought. I
 have now observed more similar illegal neighbor solicitation packets,
 but now with wildly differing packet-lengths (not just 172), and in
 relative large numbers and high frequency.

 The following is a tcpdump (I added line-breaks) of what happened,
 with my comments interspersed. fe80::201:3ff:fe40:d094 is my NetBSD
 machine, which is pinging the "target" fe80::240:5ff:fe18:66d8.
 I have removed some router advertisment messages that occur in the
 midst of all this and I believe are irrelevant to the problem.

 [initially: The ping is triggering solicitations, the target is offline]

 14:31:49.265328 0:1:3:40:d0:94 0:40:5:18:66:d8 ip6 86:
     fe80::201:3ff:fe40:d094 > fe80::240:5ff:fe18:66d8:
     icmp6: neighbor sol: who has fe80::240:5ff:fe18:66d8
 14:31:53.265726 0:1:3:40:d0:94 33:33:ff:18:66:d8 ip6 86:
     fe80::201:3ff:fe40:d094 > ff02::1:ff18:66d8: icmp6:
     neighbor sol: who has fe80::240:5ff:fe18:66d8

 [I switch on the target, which replies to the solicitation]

 14:31:53.611840 0:40:5:18:66:d8 0:1:3:40:d0:94 ip6 86:
     fe80::240:5ff:fe18:66d8 > fe80::201:3ff:fe40:d094:
     icmp6: neighbor adv: tgt is fe80::240:5ff:fe18:66d8

 [The MACs are resolved and pinging proceeds]

 14:31:53.612123 0:1:3:40:d0:94 0:40:5:18:66:d8 ip6 70:
     fe80::201:3ff:fe40:d094 > fe80::240:5ff:fe18:66d8: icmp6: echo request
 14:31:53.962651 0:40:5:18:66:d8 0:1:3:40:d0:94 ip6 70:
     fe80::240:5ff:fe18:66d8 > fe80::201:3ff:fe40:d094: icmp6: echo reply
 14:32:02.616678 0:1:3:40:d0:94 0:40:5:18:66:d8 ip6 70:
     fe80::201:3ff:fe40:d094 > fe80::240:5ff:fe18:66d8: icmp6: echo request
 14:32:02.938405 0:40:5:18:66:d8 0:1:3:40:d0:94 ip6 70:
     fe80::240:5ff:fe18:66d8 > fe80::201:3ff:fe40:d094: icmp6: echo reply

 [I take the target offline and then back online, in effect flushing
 its neighbor cache.]

 14:32:12.607734 0:1:3:40:d0:94 0:40:5:18:66:d8 ip6 70:
     fe80::201:3ff:fe40:d094 > fe80::240:5ff:fe18:66d8: icmp6: echo request

 [The target's neighbor cache being flushed, it needs to look up the
 MAC address of fe80::201:3ff:fe40:d094]

 14:32:13.413891 0:40:5:18:66:d8 33:33:ff:40:d0:94 ip6 86:
     fe80::240:5ff:fe18:66d8 > ff02::1:ff40:d094:
     icmp6: neighbor sol: who has fe80::201:3ff:fe40:d094
 14:32:13.414201 0:1:3:40:d0:94 0:40:5:18:66:d8 ip6 86:
     fe80::201:3ff:fe40:d094 > fe80::240:5ff:fe18:66d8:
     icmp6: neighbor adv: tgt is fe80::201:3ff:fe40:d094

 [Solicitation went OK, the previous echo request is answered, and
 pinging proceeds.]

 14:32:13.775159 0:40:5:18:66:d8 0:40:5:18:66:d8 ip6 70:
     fe80::240:5ff:fe18:66d8 > fe80::240:5ff:fe18:66d8: icmp6: echo reply
 14:32:22.608818 0:1:3:40:d0:94 0:40:5:18:66:d8 ip6 70:
     fe80::201:3ff:fe40:d094 > fe80::240:5ff:fe18:66d8: icmp6: echo request
 14:32:22.966429 0:40:5:18:66:d8 0:1:3:40:d0:94 ip6 70:
     fe80::240:5ff:fe18:66d8 > fe80::201:3ff:fe40:d094: icmp6: echo reply

 [Now everything goes into a spin, and this is what I believe is
 incorrect behavior on NetBSD's part.]

 14:32:27.269350 0:1:3:40:d0:94 0:40:5:18:66:d8 ip6 86:
     fe80::201:3ff:fe40:d094 > fe80::240:5ff:fe18:66d8:
     icmp6: neighbor sol: who has fe80::240:5ff:fe18:66d8
 14:32:27.646284 0:1:3:40:d0:94 0:40:5:18:66:d8 ip6 172:
     fe80::201:3ff:fe40:d094 > fe80::240:5ff:fe18:66d8:
     icmp6: neighbor sol: who has fe80::240:5ff:fe18:66d8
 14:32:28.050698 0:1:3:40:d0:94 0:40:5:18:66:d8 ip6 258:
     fe80::201:3ff:fe40:d094 > fe80::240:5ff:fe18:66d8:
     icmp6: neighbor sol: who has fe80::240:5ff:fe18:66d8
 14:32:28.269480 0:1:3:40:d0:94 0:40:5:18:66:d8 ip6 86:
     fe80::201:3ff:fe40:d094 > fe80::240:5ff:fe18:66d8:
     icmp6: neighbor sol: who has fe80::240:5ff:fe18:66d8
 14:32:28.452977 0:1:3:40:d0:94 0:40:5:18:66:d8 ip6 344:
     fe80::201:3ff:fe40:d094 > fe80::240:5ff:fe18:66d8:
     icmp6: neighbor sol: who has fe80::240:5ff:fe18:66d8
 14:32:28.828711 0:1:3:40:d0:94 0:40:5:18:66:d8 ip6 172:
     fe80::201:3ff:fe40:d094 > fe80::240:5ff:fe18:66d8:
     icmp6: neighbor sol: who has fe80::240:5ff:fe18:66d8
 14:32:29.249120 0:1:3:40:d0:94 0:40:5:18:66:d8 ip6 430:
     fe80::201:3ff:fe40:d094 > fe80::240:5ff:fe18:66d8:
     icmp6: neighbor sol: who has fe80::240:5ff:fe18:66d8
 14:32:29.269600 0:1:3:40:d0:94 0:40:5:18:66:d8 ip6 86:
     fe80::201:3ff:fe40:d094 > fe80::240:5ff:fe18:66d8:
     icmp6: neighbor sol: who has fe80::240:5ff:fe18:66d8
 14:32:29.644034 0:1:3:40:d0:94 0:40:5:18:66:d8 ip6 258:
     fe80::201:3ff:fe40:d094 > fe80::240:5ff:fe18:66d8:
     icmp6: neighbor sol: who has fe80::240:5ff:fe18:66d8
 14:32:30.070986 0:1:3:40:d0:94 0:40:5:18:66:d8 ip6 516:
     fe80::201:3ff:fe40:d094 > fe80::240:5ff:fe18:66d8:
     icmp6: neighbor sol: who has fe80::240:5ff:fe18:66d8

 ..and so on for about 10 more packets. The frequency of these
 solicitations might be reasonable, but as far as I can tell their
 syntax is incorrect, and the packet length should always be 86.

 Sincerely,
 -- 
 Frode Vatvedt Fjeld

From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
To: frodef@stud.cs.uit.no
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/15360
Date: Wed, 30 Jan 2002 13:58:04 +0900

 	http://www.NetBSD.org/cgi-bin/query-pr-single.pl?number=15360

 	I cannot seem to repeat the symptom on my machines.
 	please post the whole tcpdump file output, uuencoded
 	(captured with -s 2000 -w foo).

 itojun
State-Changed-From-To: open->closed
State-Changed-By: maxv@NetBSD.org
State-Changed-When: Sat, 24 Mar 2018 08:05:05 +0000
State-Changed-Why:
Close this PR, it's not relevant anymore, the code has significantly
changed since.


>Unformatted:

Home	PR Database Search