Bug 10033 - ping -p fails because buffer size is computed wrong.
Summary: ping -p fails because buffer size is computed wrong.
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: netkit-base
Version: 6.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-03-07 18:10 UTC by Nick Simicich
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-03-08 18:02:24 UTC
Embargoed:


Attachments (Terms of Use)

Description Nick Simicich 2000-03-07 18:10:22 UTC
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 18:02:59 UTC
"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.