Stuart Hughes wrote:
On Tue, 2008-09-23 at 07:53 +0200, Erwin Authried wrote:
Am Montag, den 22.09.2008, 17:28 -0600 schrieb Matt Waddel:
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
Hi,
it seems that something is wrong with the signal handling in the ping
application. There should be a SIGALRM that triggers the next ping (at
least in the standalone ping). You should try to figure out if SIGALRM
is is working at all after you interrupt the application with ^C.
Not sure if it's related but a long time ago there was a patch needed to
prevent a problem with register overwrite with some gcc versions. The
symptoms were the same:
http://mailman.uclinux.org/pipermail/uclinux-dev/2005-November/035683.html
If you look at the thread listing, there's some more around this time.
Regards, Stuart
Thanks to all who responded. After writing a simple test
program it turned out to be the signal handling. Ping was
working fine. (Thanks Erwin.)
I'm pretty sure the problem is in the shell tool. When I
switched to sash everything started working (I'm currently
using msh from an older version of busybox). I bet even
the newer version of msh would work. So I need to spend
some time upgrading my version of busybox.
Best Regards,
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
_______________________________________________
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
