Doug Graham schrieb: > On Tue, Aug 26, 2008 at 02:40:37AM +0200, Denys Vlasenko wrote: >> On Tuesday 26 August 2008 02:00, Doug Graham wrote: >>> However, in my tests between these two processors, there's a datasize >>> range from 65494 through 65507 where the ping fails quietly (gets no >> What happens with sizes > 65507? > > I get this: > > % ./busybox ping -s 65508 192.168.0.2 > PING 192.168.0.2 (192.168.0.2): 65508 data bytes > ping: sendto: Message too long > > I haven't done the math, but I take this to mean that the maximum > size of an IP datagram has been exceeded. I get a similar error > on my rh desktop using its installed (iputils) ping: > > % ping -s 65508 47.128.20.74 > WARNING: packet size 65508 is too large. Maximum is 65507 > PING 47.128.20.74 (47.128.20.74) 65508(65536) bytes of data. > ping: local error: Message too long, mtu=1500 > ping: local error: Message too long, mtu=1500 > > I think the math does work out. 65508 + 8 byte ICMP header + 20 byte > IP header = 65536 which is larger than the maximum IP datagram size of > 64k - 1. > >>> response) without issuing any error message. I was going to suggest >>> a further patch to limit the maxium packet size to MAXPACKET (already >>> defined in ping.c but never used for anything), but then I realized that >>> this symptom probably really does demonstrate a quirk somewhere in the >>> networking stack on the destination machine. >> Are you saying that you verified that there genuinely were no reply packets >> (say, with tcpdump), or do you just guess? > > Yes, I did verify this with tcpdump. Also verified that the "netstat -s" > stats on the destination machine look quite odd. The destination machine > got and reassembled the packet without error, but didn't recognize it > as an ICMP packet and didn't send a reply. This destination machine is > running a 3rd party protocol stack, so I think we've found a bug to report > to the vendor. Busybox's ping works fine with sizes in this range when > the destination is a standard desktop machine, so whatever is going on, > it's not a busybox problem. >
i guess the LKML would like to hear about the problem. re, wh _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
