Home of the Squeezebox™ & Transporter® network music players.
Page 23 of 24 FirstFirst ... 1321222324 LastLast
Results 221 to 230 of 236
  1. #221
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    798
    Quote Originally Posted by ralphy View Post
    The wireless extensions version is 22.
    Thank you for that, I thought I had come across the definition in the past, but couldn't remember where.

    There's nothing better than a hard fact, which you have (kindly) provided, to spoil a perfectly good tale !

    It turns out that our ar6000.ko seems to have chosen to increment the SSID length it is provided, by one. Not just for its own use, mind, it increments the length in the data buffer provided by the originating SIOCSIWESSID ioctl call. That (now changed) data buffer then informs the kernel's subsequent wireless_send_event event notification. And if the SSID was 32 bytes long, well, it now appears to have been 33 bytes long.

    I shall add that the kernel's ioctl_standard_call is also capable of tinkering with the SSID length in some circumstances, but seems to be capable of cleaning up after itself... (net/wireless/wext.c).

    I found one sample of an AR6000 driver source code that appeared to display this behaviour, and several that did not. Never mind that the sample I found is apparently for an AR6003, and Linux v3.3. The fact that one driver source appears to have done it suggests that others might have done it.

    That sample carefully increments the length if WIRELESS_EXT > 20, presumably because it knows, I suppose, that wpa_supplicant and friends will have taken care _not_ to increment the length in this circumstance. Ho hum.

    (File wireless_ext.c at: http://dl.linux-sunxi.org/SDK/A20/A20_SDK_20130319/lichee/linux-3.3/modules/wifi/ar6003/AR6kSDK.build_3.1_RC.514/host/os/linux/
    But not worth examining. )

    A little peek inside our ar6000.ko seems to reveal the same behaviour. There is always room for misinterpretation/error...

    Anyway, we can legitimately "squash" the kernel complaint by simply restricting the "random SSID" to 31 bytes in length, not 32, so my tale still contains a kernel of truth.

  2. #222

    Mitigation Script 0.8.3 Available for Testing

    An update to the mitigation script wlanpoke is available on the GitHub development branch. It has a lot of changes to accommodate low signal levels, better reports and logging, switching between Wlan and Ethernet, etc. Other than reinstatement of a reliable "quick reset" method, this is more or less feature complete. The 7 radios here seem ok with it, but the environment has been quiet lately, and this needs testing under more fierce conditions before it is more generally offered in the main branch or as a release. Thanks for your input.

  3. #223
    Junior Member
    Join Date
    Feb 2013
    Posts
    12
    Thanks PomDev for your efforts, cannot test anymore, as I capitulated yesterday and sold all three radios whilst keeping the booms. Good luck on pinpointing the issues here!

  4. #224
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    2,833
    Quote Originally Posted by mrw View Post
    Thank you for that, I thought I had come across the definition in the past, but couldn't remember where.

    There's nothing better than a hard fact, which you have (kindly) provided, to spoil a perfectly good tale !

    It turns out that our ar6000.ko seems to have chosen to increment the SSID length it is provided, by one. Not just for its own use, mind, it increments the length in the data buffer provided by the originating SIOCSIWESSID ioctl call. That (now changed) data buffer then informs the kernel's subsequent wireless_send_event event notification. And if the SSID was 32 bytes long, well, it now appears to have been 33 bytes long.

    I shall add that the kernel's ioctl_standard_call is also capable of tinkering with the SSID length in some circumstances, but seems to be capable of cleaning up after itself... (net/wireless/wext.c).

    I found one sample of an AR6000 driver source code that appeared to display this behaviour, and several that did not. Never mind that the sample I found is apparently for an AR6003, and Linux v3.3. The fact that one driver source appears to have done it suggests that others might have done it.

    That sample carefully increments the length if WIRELESS_EXT > 20, presumably because it knows, I suppose, that wpa_supplicant and friends will have taken care _not_ to increment the length in this circumstance. Ho hum.

    (File wireless_ext.c at: http://dl.linux-sunxi.org/SDK/A20/A2...host/os/linux/
    But not worth examining. )

    A little peek inside our ar6000.ko seems to reveal the same behaviour. There is always room for misinterpretation/error...

    Anyway, we can legitimately "squash" the kernel complaint by simply restricting the "random SSID" to 31 bytes in length, not 32, so my tale still contains a kernel of truth.
    I've merged wpa_supplicant v2.9 - Fix "Wireless Event too big (33)" messages. Thank you.

    There's a new baby_8.0.1_r16855.zip firmware available on sourceforge with the change.
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 2-UE Radio
    Squeezebox client builds donations always appreciated.

  5. #225
    Junior Member
    Join Date
    Dec 2019
    Location
    holland
    Posts
    6
    Quote Originally Posted by POMdev View Post
    An update to the mitigation script wlanpoke is available on the GitHub development branch. It has a lot of changes to accommodate low signal levels, better reports and logging, switching between Wlan and Ethernet, etc. Other than reinstatement of a reliable "quick reset" method, this is more or less feature complete. The 7 radios here seem ok with it, but the environment has been quiet lately, and this needs testing under more fierce conditions before it is more generally offered in the main branch or as a release. Thanks for your input.
    oke i have tested it but: this is the result:

    Squeezebox Radiok wlanpoke.sh 0.8.3.4 4/2/2021 launched 2021-04-07_16:46:28 Options: -W slow -Wp 8080 logging to -W slow -Wp 8080
    Wed Apr 7 16:51:26 CEST 2021 ( 16:51:27 up 1:50, load average: 2.14, 1.33, 1.07 )

    eth1 AR6000 802.11g ESSID:"hop1"
    Mode:Managed Frequency:2.432 GHz Access Point: 3C:7C:3FB:7A:E9
    Bit Rate=36 Mb/s Tx-Power=15 dBm Sensitivity=0/3
    Retryn
    Encryption keyff
    Link Quality:30/94 Signal level:-65 dBm Noise level:-96 dBm
    Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
    Tx excessive retries:1 Invalid misc:0 Missed beacon:0

    wlanpoke test settings (s,q,f) and failed pings [0..n] prior to recovery

    recent AP scan results


    the "wlanpoke test settings" there is nothing to see

  6. #226
    Quote Originally Posted by cb4kda View Post
    oke i have tested it but: this is the result:
    Squeezebox Radiok wlanpoke.sh 0.8.3.4 4/2/2021 launched 2021-04-07_16:46:28 Options: -W slow -Wp 8080 logging to -W slow -Wp 8080
    Wed Apr 7 16:51:26 CEST 2021 ( 16:51:27 up 1:50, load average: 2.14, 1.33, 1.07 )
    ...
    wlanpoke test settings (s,q,f) and failed pings [0..n] prior to recovery
    (blank)
    recent AP scan results
    (blank)
    the "wlanpoke test settings" there is nothing to see
    Thanks for the report. This is a new bug in awstats.sh, which incorrectly calculates the logging directory. A previous update inadvertently deleted a step on line 18, not caught here because we have switched logging to -d /etc/log/, which works. The fixed awstats.sh script has been uploaded to the development branch.

    For more information, including a quick fix, see the new Missing Web Page Output issue on GitHub.

  7. #227
    Junior Member
    Join Date
    Dec 2019
    Location
    holland
    Posts
    6
    Quote Originally Posted by POMdev View Post
    Thanks for the report. This is a new bug in awstats.sh, which incorrectly calculates the logging directory. A previous update inadvertently deleted a step on line 18, not caught here because we have switched logging to -d /etc/log/, which works. The fixed awstats.sh script has been uploaded to the development branch.

    For more information, including a quick fix, see the new Missing Web Page Output issue on GitHub.

    thanks the result

  8. #228
    Senior Member Tony T's Avatar
    Join Date
    Nov 2009
    Posts
    1,144
    Is wlanpoke now included as part of the CBRF?
    Tony
     SBTouch ♪ SBRadio ♬

  9. #229
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    798
    Quote Originally Posted by Tony T View Post
    Is wlanpoke now included as part of the CBRF?
    No. There is no "CBRF" per se.

    The "Community Firmware for Squeezebox Radio/Touch/Controller and LMS 8" thread is here: https://forums.slimdevices.com/showt...ller-and-LMS-8

    The first post has a link to the CHANGELOG.

  10. #230
    Junior Member
    Join Date
    Mar 2021
    Posts
    5
    Just by way of providing additional logging.

    The SBR had not been able to connect for ages, so I spent some time changing the settings on the Asus router on the 2.4ghz. When I turned off protected management frames, the SBR connected to the wifi again. Attached is the logging from the last 20 mins - three drop outs with successful reconnects. When it initially reconnected I updated the firmware:

    Player Model: Squeezebox Radio
    Player Type: baby
    Firmware: 8.0.1-r16844
    Attached Files Attached Files

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •