mrw wrote: > I think it be very helpful to find out what is killing it. If it is not > the script, then that may hint at a problem with -wpa_supplicant-, or > with its control socket. > ... > SqueezePlay does restart -wpa_cli- when it brings a network up. > (-Networking.lua- function -_ifiup- calls -restartWpaCli-). > ... > SqueezePlay itself does have the ability to respond to events from > -wpa_supplicant- if it chooses. But it does not so choose. See -attach- > / -detach- following -jive.net.Networking:request()-. That might be a > route towards logging -wpa_supplicant- events. Using a debug build of both will be a start. Hope to get on that soon, but the script needs to always work again. I hope that's finished with a today's new version.
As mentioned before, I think there is a problem with one or both of the two wpa_* since the driver messages displayed by recEvent stop before an outage is detected, then resume after wpa_cli and wpa_supplicant is killed (see prior message). RecEvent could do some logging directly, but I'm the events come streaming out at a too-high rate for reasonable logging, and the events just prior to the event stream stopping seem uninformative, at first glance (2 weeks ago). If SqueesePlay restarts wpa_cli, I guess it is safe to do so in the script...??? What about restarting wpa_supplicant (thinking about that as a next script step)? I think that the wpa_ demons should handle the networking by themselves. SqueezePlay shouldn't have to deal with a faulty network stack. The stack should be fixed. This may be possible. ------------------------------------------------------------------------ POMdev's Profile: http://forums.slimdevices.com/member.php?userid=70558 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 _______________________________________________ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
