Bug 10033 - ping -p fails because buffer size is computed wrong.
ping -p fails because buffer size is computed wrong.
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: netkit-base (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-03-07 13:10 EST by Nick Simicich
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-03-08 13:02:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Nick Simicich 2000-03-07 13:10:22 EST
ping -p used to work on my Redht 5.0 system.  It no longer works on my
redhat 6.0 system with the latest RPM for netkit-base.

Have there not been enough problems reported with ping that it is time for
a new, "blessed" RPM?  I hesitate to run suid code on my system from some
other source.

[root@glock /root]# type ping
ping is hashed (/bin/ping)
[root@glock /root]# rpm -q -f /bin/ping
netkit-base-0.10-31
[root@glock /root]# ping -p 55 ftp.concentric.net
PATTERN: 0x55
PING ftp.concentric.net (206.173.119.79) from 208.176.124.157 : 56 data
bytes
ping: sendto: No buffer space available
ping: wrote ftp.concentric.net 64 chars, ret=-1
ping: sendto: No buffer space available
ping: wrote ftp.concentric.net 64 chars, ret=-1

--- ftp.concentric.net ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
[root@glock /root]#

(In the meantime, a message like the following is logges in syslog,
leading to my contention that the buffer size is miscomputed:)

Mar  6 23:57:41 glock kernel: kmalloc: Size (3688685021) too large

Of course Perl's Net::Ping worked fine, making me think that the general
icmp code is OK.

Here is the important bit of the strace of ping:

brk(0x8060000)                          = 0x8060000
munmap(0x40108000, 21990)               = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr
("0.0.0.0"
)}, 16) = 0
send(4, "\217\262\1\0\0\1\0\0\0\0\0\0\3ft"..., 36, 0) = 36
SYS_168(0xbfffe7d8, 0x1, 0x1388, 0x1388, 0xbfffe7d8) = 1
recvfrom(4, "\217\262\201\200\0\1\0\1\0\4\0\4"..., 1024, 0,
{sin_family=AF_INET,
 sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, [16]) = 233
close(4)                                = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sin_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr
("206.173.119.79")}, 16) = 0
getsockname(4, {sin_family=AF_INET, sin_port=htons(3964),
sin_addr=inet_addr("208.176.124.157")}, [16]) = 0
close(4)                                = 0
bind(3, {sin_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr
("208.176.124.157")}, 16) = 0
setsockopt(3, IPPROTO_RAW, 1, [-6202], 4) = 0
getpid()                                = 27348
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [49152], 4) = 0
setsockopt(3, SOL_SOCKET, SO_BROADCAST, [0], 4) = 0
write(1, "PING ftp.concentric.net (206.173"..., 78
PING ftp.concentric.net (206.173.119.79) from 208.176.124.157 : 56 data
bytes
) = 78
SYS_174(0x2, 0xbffffa3c, 0, 0x8, 0x2)   = 0
SYS_174(0xe, 0xbffffa34, 0, 0x8, 0xe)   = 0
gettimeofday({952452592, 882948}, NULL) = 0
gettimeofday({952452592, 890215}, NULL) = 0
socketcall(0x10, 0xbffffb6c)            = -1 ENOBUFS (No buffer space
available)
write(2, "ping: sendto: No buffer space av"..., 40ping: sendto: No buffer
space
available
) = 40
write(1, "ping: wrote ftp.concentric.net 6"..., 48ping: wrote
ftp.concentric.net
 64 chars, ret=-1
) = 48

#define SOCKOP_sendmsg       16 = 0x10

so I assume that the problem is buried in the mystery of the argument
buffer at bffffb6c.
Comment 1 Jeff Johnson 2000-03-08 13:02:59 EST
"ping -p ff host" does not exhibit the problem described in the ping in
iputils-20000121-1. Try recompiling from the src.rpm in Raw Hide for 6.0.
(THere won't be an errata for Red Hat 6.0 because the impact of "-p xx" being
broke is vanishingly small).

Note You need to log in before you can comment on or make changes to this bug.