Hello, I've encountered an interesting problem with ping (both busybox and the regular ping) on the Coldfire platforms. After typing <control c> to end ping the 1st time, running ping the 2nd time only lets one packet get through. Ping seems to hang after the first packet.
So the following sequence: # ping 192.168.1.100 PING 192.168.1.100 (192.168.1.100): 56 data bytes 64 bytes from 192.168.1.100: icmp_seq=0 ttl=64 time=10.0 ms 64 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=0.0 ms 64 bytes from 192.168.1.100: icmp_seq=2 ttl=64 time=0.0 ms 64 bytes from 192.168.1.100: icmp_seq=3 ttl=64 time=0.0 ms 64 bytes from 192.168.1.100: icmp_seq=4 ttl=64 time=0.0 ms 64 bytes from 192.168.1.100: icmp_seq=5 ttl=64 time=0.0 ms 64 bytes from 192.168.1.100: icmp_seq=6 ttl=64 time=0.0 ms ^C --- 192.168.1.100 ping statistics --- 7 packets transmitted, 7 packets received, 0% packet loss round-trip min/avg/max = 0.0/1.4/10.0 ms # ping 192.168.1.100 PING 192.168.1.100 (192.168.1.100): 56 data bytes 64 bytes from 192.168.1.100: icmp_seq=0 ttl=64 time=0.0 ms <<<<< wait a long time where nothing happens >>>>> ^C --- 192.168.1.100 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms --------------------------------------------------------- If you set a limit to the number of ping packets using the command: ping -c 5 <ip addr> everything works fine - every time. (As long as you don't type <control c>.) Obviously the <control c> is leaving the ping/icmp system in a bad state somewhere. I'm using the 2.6.26 kernel, but I also saw the problem on the 2.6.23 kernel. Do any other platforms have this problem? Any ideas where to start looking? TIA, Matt _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
