POMdev wrote: > Right. I read through the Networking.lua code to see what it was doing, > then to the icon, and setting the status, and got lost! But in the > meantime, in investigating a too-long red icon, checking routing (cat > /proc/net/route), the gateway was missing, and didn't return for quite a > while. Apparently, the re-association alone caused this entry to be > deleted, hence the down/up reset, which I thought would trigger a lease > renewal to restore the entry. It did, but not rapidly enough. > > But then, using your tip, wpa_cli reassoc ; kill -s USR1 `cat > /var/run/udhcpc.eth1.pid` ; cat /proc/net/route works very quickly, the > gateway entry is still there, and the icon does not turn red at all, an > apparent big improvement over the previous code. > > However, after doing this several times, my radio on the TTL serial now > works with the just re-association alone, perhaps beaten into > submission? I wonder knowing what is causing the gateway entry to be > deleted, and that 'arp' 'address in use' message seen earlier? > > Perhaps this also will improve the success rate of the so-called > ResetQuick() method. This deserves some testing to make sure there are > no side effects. Thanks again.
A successful re-association will trigger the -wpa_action- script into "kicking" -udhcpc- into renewing the lease. I think that taking the interface down at this point with -ifconfig- simply prevents/hinders -udhcpc- from doing its job. One shouldn't need to be "kicking" -udhcpc- again. I imagine that the gateway is being cleared by -udhcpc-, immediately prior to renewing the lease, after which it would load the new one. I doubt that re-association per se is the cause. But I haven't checked that. -udhcpc- is part of busybox, so the source code could be checked to obtain complete clarity. The "arp address in use" message is caused by not getting a "null' response to the ping in reasonable time (refer code in -Networking.lua-). If the interface is down, -arping- won't even try. SqueezePlay doesn't know/care what the true cause of the error is. Remark: SqueezePlay does most of its work using -ifup[i/] and [i]ifdown-, which pull the pre-up, post-down, etc., network action scripts into play. ------------------------------------------------------------------------ mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 _______________________________________________ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
