NetBSD Problem Report #56057

From jschauma@netmeister.org  Mon Mar 15 14:34:57 2021
Return-Path: <jschauma@netmeister.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id CFD251A9217
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 15 Mar 2021 14:34:57 +0000 (UTC)
Message-Id: <20210315143454.8B24C85612@panix.netmeister.org>
Date: Mon, 15 Mar 2021 10:34:54 -0400 (EDT)
From: jschauma@netmeister.org
Reply-To: jschauma@netmeister.org
To: gnats-bugs@NetBSD.org
Subject: 'ping6 -p' does not seem to set the data
X-Send-Pr-Version: 3.95

>Number:         56057
>Category:       bin
>Synopsis:       'ping6 -p' does not seem to set the data
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Mar 15 14:35:00 +0000 2021
>Closed-Date:    Mon Jun 07 22:17:34 +0000 2021
>Last-Modified:  Mon Jun 07 22:17:34 +0000 2021
>Originator:     Jan Schaumann
>Release:        NetBSD 9.99.78
>Organization:

>Environment:


System: NetBSD ip-10-10-0-47.ec2.internal 9.99.78 NetBSD 9.99.78 (GENERIC) #0: Fri Jan 22 00:44:55 UTC 2021  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:

Per RFC4443, the ICMP6 "echo request" / "echo reply" messages have a "data"
field, allowing the sender to send "Zero or more octets of arbitrary data.",
which the receiver has to echo back.

Per the manual page, the '-p' flag can be used to set the data, but while this
works for IPv4 ping(1), ping6(1) appears to not set this data correctly.

>How-To-Repeat:

$ tcpdump -w /tmp/icmp6 'icmp6[icmp6type] == icmp6-echo' >/dev/null 2>&1 &
$ ping6 -p 0123456789 -c 1 www.netbsd.org
$ fg
^C
$ tcpdump -n -t -X -r /tmp/icmp6
IP6 2600:1f18:400c:b800:bc3c:63cc:7e5d:1f96 > 2001:470:a085:999::80: ICMP6, echo request, seq 0, length 16
        0x0000:  6000 0000 0010 3aff 2600 1f18 400c b800  `.....:.&...@...
        0x0010:  bc3c 63cc 7e5d 1f96 2001 0470 a085 0999  .<c.~].....p....
        0x0020:  0000 0000 0000 0080 8000 dff1 57a7 0000  ............W...
        0x0030:  604f 6c53 000c b13b                      `OlS...;^M

Note that the octets in the last line here are not the data that we set.

On a Linux system, for example, I'm seeing:

IP6 2600:1f18:400c:b800:f5ba:e5ca:d7c3:c6e8 > 2001:470:a085:999::80: ICMP6, echo request, seq 1, length 64
        0x0000:  600e 3651 0040 3aff 2600 1f18 400c b800  `.6Q.@:.&...@...
        0x0010:  f5ba e5ca d7c3 c6e8 2001 0470 a085 0999  ...........p....
        0x0020:  0000 0000 0000 0080 8000 77a0 083e 0001  ..........w..>..
        0x0030:  e76f 4f60 0000 0000 cc04 0d00 0000 0000  .oO`............
        0x0040:  2345 6789 0123 4567 8901 2345 6789 0123  #Eg..#Eg..#Eg..#
        0x0050:  4567 8901 2345 6789 0123 4567 8901 2345  Eg..#Eg..#Eg..#E
        0x0060:  6789 0123 4567 8901  

showing the padding data at the end as requested.

>Fix:


>Release-Note:

>Audit-Trail:
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/56057: 'ping6 -p' does not seem to set the data
Date: Mon, 15 Mar 2021 22:50:15 +0700

 I believe that it is required to use -s and set a longer packet length
 if you want any padding data included in a ping6 packet - the default
 ping6 packet contains space only for the send time value (used to calculate
 the RTT after it is returned in the reply) and nothing else.

 That's unlike IPv4 where ping "knew" the min packet size of the underlying
 network (the whole world is ethernet) and by default sends that much.

 It may be that use of the -p option should extend (if necessary) the packet
 length to allow at least one instance of the pattern to fit, but that is
 not the way it has traditionally worked on NetBSD.

 kre

From: Jan Schaumann <jschauma@netmeister.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/56057: 'ping6 -p' does not seem to set the data
Date: Mon, 15 Mar 2021 16:38:27 -0400

 Ah, indeed, looks like that's working:

 ping6 -p 0123456789 -s 66 www.netbsd.org

 =>

 IP6 2600:1f18:400c:b800:bc3c:63cc:7e5d:1f96 > 2001:470:a085:999::80: ICMP6, echo request, seq 0, length 74
         0x0000:  6000 0000 004a 3aff 2600 1f18 400c b800  `....J:.&...@...
         0x0010:  bc3c 63cc 7e5d 1f96 2001 0470 a085 0999  .<c.~].....p....
         0x0020:  0000 0000 0000 0080 8000 71cf 4785 0000  ..........q.G...
         0x0030:  604f c4f3 000b 2012 0123 4567 8901 2345  `O.......#Eg..#E
         0x0040:  6789 0123 4567 8901 2345 6789 0123 4567  g..#Eg..#Eg..#Eg
         0x0050:  8901 2345 6789 0123 4567 8901 2345 6789  ..#Eg..#Eg..#Eg.
         0x0060:  0123 4567 8901 2345 6789 0123 4567 8901  .#Eg..#Eg..#Eg..
         0x0070:  2345


 Cool - thanks!

 Perhaps an error message if '-p' is specified and '-s'
 is not might be useful to avoid this problem?  Or at
 least a mention in the manual page for the '-p' flag
 might be helpful for the user.

From: "David A. Holland" <dholland@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56057 CVS commit: src/sbin/ping6
Date: Mon, 7 Jun 2021 22:13:34 +0000

 Module Name:	src
 Committed By:	dholland
 Date:		Mon Jun  7 22:13:34 UTC 2021

 Modified Files:
 	src/sbin/ping6: ping6.8 ping6.c

 Log Message:
 In ping6, there's no blank space in the ping packets by default.

 - document that if you use -p to specify a fill pattern you need to
 make the packets bigger with -s;

 - warn if -p is used and there's not at least one byte of fill space.

 PR 56057


 To generate a diff of this commit:
 cvs rdiff -u -r1.33 -r1.34 src/sbin/ping6/ping6.8
 cvs rdiff -u -r1.104 -r1.105 src/sbin/ping6/ping6.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 07 Jun 2021 22:17:34 +0000
State-Changed-Why:
fixed, thanks


>Unformatted:

Home	PR Database Search