Messages in this thread |  | | From | (Philippe Strauss) | Subject | Re: Ping with a 65510 bytes pack | Date | Sun, 20 Oct 1996 20:56:14 +0200 (MET DST) |
| |
Alan Cox wrote: > > > Yes it fix the problem. Applied against 2.1.5 rather than 2.0.22. > > I will provide some dump of this strange icmp packet later. > > This is indeed a combination of a windows 95 bug - apparently fixed in later > releases and a Linux bug when we construct a packet over 64K long (not valid) > Unfortunately the ip_send test program I had didnt build a packet that got > high enough up the stack after reassembly to cause an explosion. > > Fun bug ;). Now perhaps you can get the tcp fixes into the 2.0.24 release > and the route cache leak fix hey Linus 8) >
I've played further with big sized ICMP_ECHO, and found some interesting behavior of the ping prog. (Mine come from debian 1.1 netbase package).
pinging myself (127.0.0.1) give that:
packetsize (-s)
56-24372 work ok 24373-65332 nothing _seems_ to get through (though i can't put tcpdump on the loopback :) 65333-65464 work ok 65465-65468 really weird, seem to loose some bits, print a warning message and dump the packet on the screen. On 2.1.5, i rather get a 'Couldn't get a free page....' 65469 packet too large
On the wire, bheavior seem different, between to linux box (a 2.1.5 and a 2.0.10, no router, just a hub)
56-48948 work well 48949-65469 ping doesn't give a line of result, though tcpdump see all the packet coming and going (request *and* reply). Also the LED's on the hub are riding high every second :) but this is OK.
Any ideas? well, ok this is more a ping soft. problem (except maybe for the Couldn't get a free page).
-- Philippe Strauss, CH-1092 Belmont
Email: <philippe.strauss@urbanet.ch> Homepage: http://sicel-home-1-4.urbanet.ch
|  |