bin/41111: ping -R gives misleading error when remote side doesn't support record route

[eravin%panix.com@localhost]

>Number:         41111
>Category:       bin
>Synopsis:       ping -R gives misleading error when remote side doesn't 
>support record route
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 31 19:30:00 +0000 2009
>Originator:     Ed Ravin
>Release:        5.0RC2
>Organization:
Public Access Networks
>Environment:
NetBSD panix5.panix.com 5.0_RC2 NetBSD 5.0_RC2 (PANIX-XEN3U-USER-pae) #1: Sat 
Feb 21 20:24:11 EST 2009  
root%juggler.panix.com@localhost:/misc1/obj/misc2/devel/netbsd/5.0-RC2/src/sys/arch/i386/compile/PANIX-XEN3U-USER-pae
 i386
>Description:
"ping -R" adds a 40 byte field to the ICMP echo request packet.

Some hosts do not support record route.  Some of those non-supporting hosts 
will still answer the ICMP echo request with the appropriate ICMP echo reply, 
but they delete the 40 byte field before replying.

When that happens, the NetBDS ping command issues this error:

$ ping -R -c 2 google.com
PING google.com (74.125.45.100): 56 data bytes
64 bytes from 74.125.45.100: icmp_seq=0 ttl=242 time=214.877 ms
wrong total length 84 instead of 124
64 bytes from 74.125.45.100: icmp_seq=1 ttl=242 time=44.624 ms
wrong total length 84 instead of 124

----google.com PING Statistics----
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 44.624/129.750/214.877/120.387 ms

This message is confusing.  ping is doing a simple length check when it 
receives the packet and issues the mismatch error without consideration as to 
why the lengths are different.  In this case, there's nothing "wrong" about the 
returned length - it's just an indication that record route isn't supported 
along the path being pinged.  Users not familiar with the intricates of IP and 
ICMP might think there is a networking fault at the IP address in question 
because it responds with "wrong" packets.
>How-To-Repeat:

>Fix:
Fix the error message to explain the length mismatch without any pejorative 
terms (e.g. "expected N byte response, received M bytes")
or perhaps decode the response to see which part(s) of it differ.