Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
POMdev wrote: > A few additional questions: > Does the radio respond to pings from the desktop? How about ssh? The > optional web server? > What does the squeezebox say under Network Info? Wireless Info? > Can it play any music source? Is the wireless icon red? > Does your router report the radio on some other ip address (look for > its mac address) > I downgraded back to v0.6.3 just to confirm I wasn't crazy. (I wasn't. The radio's connection has been solid again for 48+ hrs since downgrading.) I'll upgrade to the latest v0.7.x and try some of your troubleshooting steps. 'I created an issue on GitHub' (https://github.com/PomDev2/wlanpoke/issues/2) where I'll post the results so that we're not spamming this thread with a bunch of diagnostic details. Thank you again for your time and assistance with this script. RichardDavies's Profile: http://forums.slimdevices.com/member.php?userid=35024 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
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
frankd wrote: > Log files of the script (version 0.73) with two events capture, when the > script could not reestablish the network (second one around 12:30, first > one around 11:55). Thanks for the log files, an interesting read! Looking at wlanerr.log, an 11:55:26 outage (Line 3) was restored (l 13) at 5 ping fails by a quick reset at 11:55:41, only to be followed by a quick reset that took 15 seconds in all. However, a second outage occurred just 39 seconds later at 11:56:20 (line 15). The recovery record (l 25) shows a 11:57:09 recovery at 3 ping fails. The entry shows a hard reset entry at 11:56:37, then a quick reset at 11:57:06, and the wireless recovering by 11:57:09, indicating the network connection was successfully reestablished, and stayed that way until the next outage. The next came at 12:05:06, but the ping statistics were not written to the log file, as perhaps the radio was being rebooted. It came up at 12:07:00. Again, the failure at 12:30:24 neither recovered nor wrote the ping statistics to the log file (as it was also rebooted?), coming up at 12:31:50. That might have a little too soon to reboot, or there is something else wrong. Those missing statistics are in your stats.txt file. The current thinking is that the quick reset introduced in >= 0.7.0 is neglecting to keep the jive player "happy," and perhaps the radio showed no connection when it actually was successfully pinging. A brand new requirement of keeping jive happy is being addressed in 0.7.4 (currently available on the development branch). A few more observations: the Gastzimmer SB signal level of -67 to -69 dbm is pretty low. Logitech at the time commented (in the code) that 20 db of SNR would be ok, but perhaps not in that fierce environment to which your radio is exposed. The 11:55:26 entry (line 12) shows a 14 competing access points, 5 on 2412 mHz alone, with signal levels close to radio's AP. That list, sorted by frequency (channel) with unessential info removed is below with the columns being frequency, internal signal level measure, and SSID. 2412 188 Franky24 2412 184 ABCDE 2412 177 BREITBAND-430D 2412 173 cbx-69595 2412 169 tle-53241 2432 171 HUAWEI_H122_40BC 2437 166 PVK 2437 173 Little Hawaii 2442 171 dlink-7B08 2442 170 dlink-7B08 2462 177 BREITBAND-A533 2462 170 Android piotr 2472 184 FrankyGast 2472 183 Franky2 That's a lot, especially with a low signal level, and the neighbors similar levels. Try to boost your the signal level. My worst signal level is -52 dbm, the best is -35 dbm. My worst radio has a -51 dbm signal level, and is closest to the neighbors on the south. (This data is from the :8080 web page.) Try the 0.7.4 wlanpoke.sh in the GitHub development branch. One of its goals is to keep the player UI reassured that the network is working. This is the start of that requirement, so further improvements are expected. The hope is that keeping jive "happy" will return the script to "never fail" status, possibly with tweaking the detection parameters. A 12 hour test run of 0.7.4 (.4) last night at this now quieter environment has yielded just a few (18) failures over 7 radios, requiring 11 hard resets, and 18-11 7 successful quick resets. The radios kept playing, and the network icon presumably did not turn red during the quick resets, so this data is inconclusive. Too quiet hier. Please test. Thank you. POMdev's Profile: http://forums.slimdevices.com/member.php?userid=70558 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
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
Log files of the script (version 0.73) with two events captures, when the script could not reestablish the network (second one around 12:30, first one around 11:55). +---+ |Filename: _log.zip | |Download: http://forums.slimdevices.com/attachment.php?attachmentid=33888| +---+ frankd's Profile: http://forums.slimdevices.com/member.php?userid=52885 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
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
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
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
POMdev wrote: > This is the first report of the mitigation not working in every case. > How many times has this happened? What wlanpoke version are you > running? > > To investigate this, the log files are a first step, but they will be > lost if the radio is rebooted. Could you please upload the logs for the > affected period to your pc, then compress and post them here? You could > try moving and connecting to an Ethernet cable, or if no battery, > running a temporary cable to the radio. Alternatively, a wired serial > connection to a TTL level serial adapter would work, and you could try > various methods to restart the wireless. A second unload and reload > might do it. wlanpoke should do this on its own, but that has never been > documented. > > I don't believe the extra activity saving the logs has any effect on the > connectivity loss, and the logs are not saved until the connection is > lost anyway. You can use top and uptime to quickly check out the > processor load. Your file system should not be full. I am testing now 0.73 with standard parameters and /etc/log as directory to have logs after a failure. Keep you updated. Thanks for your great work. frankd's Profile: http://forums.slimdevices.com/member.php?userid=52885 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
Re: [SlimDevices: Radio] Installing a patch
slartibartfast wrote: > I tried installing the patch on my second Radio from /usr and it > wouldn't install so I moved it to /usr/share and I still needed to add > -p1 to the patch command. The path inside the patch has no / before > share so that could be the reason. The patch installer has no problem > with it though. Maybe another way: in case you have access to some type of webserver: you could write your own repo.xml, copy the repo.xml and the patch to your webserver, update the install.xml to maxversion * and add your own repo.xml address to the list of repositories in LMS... Long-time ago I patched the weather-applet for radios / touches and moved it to my own webserver to install the patched weather-applet (that was before the end of wunderground as public service). I tried it recently with the orange color highlight patch (for the community firmware) and it worked... The problem of most patches is currently that they all have the maxversion 7* Although they work in 8* firmwares... frankd's Profile: http://forums.slimdevices.com/member.php?userid=52885 View this thread: http://forums.slimdevices.com/showthread.php?t=114197 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
