mrw wrote: 
> ...
> It was not clear to me which elements of the script are "action" and
> which are "logging". Are you able to produce a version, or a sketch,
> that confines itself to "action" - that might help me understand what's
> going on. Squeezeplay (on the Radio) already carries out a regular
> network check, my thought is that the "action" your script takes might
> be inserted into that existing process.
I don't have the time to make a new script, but I can paraphrase the
"action part":

o The script initializes variables, kills any previous instance (if
any), checks log file writing, says "hello" to any logging server,
sleeps to allow the network to stabilize, and enters the main loop
below:
o If the wlan has an ip address, get and save the ip address of the LAN
gateway.
o If the gateway address seems reasonable, ping it. 
o If the ping is successful, and if just after a failure, send log data
to the logging server.
o If the ping failed, increment a counter. If the previous ping was ok,
start a new failure log entry.
o If the counter gets too high, restart the wireless network adapter
and drivers using RestartNetwork() [line 133]
o Check to rotate the logs, save statistics, etc. (Not actions)

A lot of code deals with logging, statistics gathering, etc. There is a
circular buffer (CB_*) that works by saving global variables that is
particularly hard to fathom. 

> In your comprehensive wi-fi monitoring report you remarked: "... from
> the Squeezebox even when it reports reasonable SNR (signal to noise
> ratio) values" Pedant mode: did you mean SNR or did you mean signal
> strength? 
I meant SNR not the signal strength. Here is a typical log entry,
de-identified (I hope):


Code:
--------------------
    ...(near duplicate entry)
  2021-02-02T11:57:35-0500 MasterSB.23_063 failed 2021-02-02T11:56:54-0500 
reset 2021-02-02T11:57:13-0500 up 2021-02-02T11:57:32-0500 eth1 AR6000 802.11g 
ESSID:\"<APN>\" Mode:Managed Frequency:2.412 GHz Access Point: <ETH> Bit 
Rate=54 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Retry:on Encryption key:off Link 
Quality:50/94 Signal level:-45 dBm Noise level:-96 dBm Rx invalid nwid:0 Rx 
invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed 
beacon:0 PING <ipaddresses): 56 data bytes 64 bytes from <ipaddress>: seq=0 
ttl=64 time=4.265 ms --- <ipaddress> ping statistics --- 1 packets transmitted, 
1 packets received, 0% packet loss round-trip min/avg/max = 4.265/4.265/4.265 ms
  2021-02-02T11:56:55-0500 PublicSB.23_063 Link Statistics
  ...[4 earlier entries from circular buffer]
  2021-02-02T11:56:50-0500: Bit Rate=54 Mb/s Tx-Power=15 dBm Sensitivity=0/3 
Link Quality:49/94 Signal level:-46 dBm Noise level:-96 dBm Tx excessive 
retries:0 Invalid misc:0 Missed beacon:0 time=38.317 <ETH> 2412 213 
[WPA2-PSK-CCMP][WPS] <APN> <ETH0> 2437 191 [WPA2-PSK-CCMP][WPS] <APN0> <ETH1> 
2462 189 [WPA2-PSK-CCMP][WPS] <APN1> <ETH2> 2417 201 <APN2>
  ...(failing entry)
--------------------

As I read this, the signal level was -46 dBm and the noise level -96,
for an SNR of 50 dB. The radio in the worst location also has its AP set
to a further away multi mode AP, with signal levels down to -70-80 dBm
as the SB driver reduces the transmission speed, etc., but the ping
still works, until it doesn't.

> I have never seen a noise level other than -96dBm on my Radio, which I
> suspect is a white lie. But perhaps you know better how to extract the
> numbers.
That's it, I don't. But, the signal numbers seem reasonable (except for
the radio on the wrong AP).

> Did you investigate the possibility of increasing the Radio's RSSI/SNR
> thresholds ? I believe that 'wmiconfig' advertises this possibility,
> although I have no idea how. My thinking being that, perhaps, increasing
> the thresholds might persuade the Radio's wifi chip to ignore your
> neighbour's wi-fi transmission altogether. But, without knowing the
> source of the interference, this is little more than an idle thought.
No I didn't. *This sounds like a really, really good idea!* This could
fix the radios, so long as the correct AP signal levels are high
enough.

> Did you ever determine the state/configuration of the Radio's wifi and
> networking configuration during the troublesome periods ? E.g.: Does it
> still have an association with the AP ? Has the AP just thrown it off
> due to successive errors ? Etc. All very difficult to determine.
Yes, most of that is in the logs (not the AP). That is what the circular
buffer is for, to save status data prior to a failure to then later
analyze. 
I did look at various AP logs, and one of them had an entry something
like "the device has left the network" of so. No evidence of AP errors.
The WLAN sniffer shows the main visible indication to be the SB is not
reliably acking transmissions from the AP, nor receiving acks
transmitted from the AP, resulting in a lot of re-transmissions. Also,
it is frequently looking for access points.

> As regards the Community Firmware for the Radio: this is shipped with a
> more up to date version of 'wpa_supplicant'. It has become clear to me
> that there are some behavioural differences between the two versions of
> wpa_supplicant that could impact matters. There have been a few
> occasions when, in conditions of particularly low wi-fi signal strength,
> my Radio (with Community firmware) seems to be "taking down" its wi-fi
> network. The effect of that is that scanning will no longer work... I
> have yet to nail the cause. I don't have wi-fi problems, and setting up
> the right conditions is very hit and miss. Rotating the Radio by a mere
> 5 degrees on the same spot can have an enormous effect on wi-fi received
> signal strength.
The script can help you troubleshoot this issue with its logging. It was
designed for troubleshooting first and to quiet noisy family members
second.


------------------------------------------------------------------------
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

Reply via email to