Intermittent wifi connection failure - solved

[/df]

Occasionally I have found that a wifi dongle on one of my HD/Rs will fail to connect. Generally, restarting the wireless router would fix this. Recently it didn't, causing me to have to diagnose the issue properly.

The problem comes down to automatic channel selection by the router. In the IEEE802.11b/g/n system, the available wireless band is split into 14 overlapping channels, whose availability is restricted by regulations that vary from region to region. With automatic channel selection, the access point (wireless router) chooses a channel from those available to it to minimise interference from other users of the 2.4GHz band. If the access point is set for a liberal regime while the station (the dongle) accepts a stricter subset of channels, the station will fail to connect when the access point picks a channel outside the station's set. By default, the failing dongle had CountryRegion=7, limiting the channels to 5-13. For a device that isn't an access point, there's no reason for the setting not to be CountryRegion=315 (channels 1-14 as discussed in the post below).

Perhaps this setting persists in the dongle's firmware and can be set from another host, eg PC. Well, no: it's encoded in the read-only driver settings file at /etc/Wireless/RT2870STA/RT2870STA.dat. However, when CF is available, the fix is to modify the wifi-up routine.

In the latest CF, this is the read-only /sbin/wifi-up. Therefore you have to copy this to /mod/sbin/wifi-up1 (to avoid trashing a file used with older CF - is it really necessary? why are there different routines?), add a new line 44 after the one setting NetworkType:
wset CountryRegion 5

wset CountryRegion 31

and modify /mod/etc/init.d/S00wlan to call /mod/sbin/wifi-up1 (line 10).

Perhaps this issue explains why some 2870/3070 dongles work and others seem not to?

 

[Black Hole]

At last, we have a possible explanation for a long-standing problem accessing Channel 1.

https://hummy.tv/forum/threads/unable-to-use-wifi-channel-1.5976/post-77901

 

[MontysEvilTwin]

UK and European WiFi standards exclude channel 14, using 1-13 only. Dongles designed for the European market may not be able to access channel 14. Some of the 'eBay' RT2870 chipset dongles may be able to use channel 14 so is there a risk that the HDR-FOX may broadcast briefly on channel 14 when scanning for an access point? While no one is likely to notice, transmitting on channel 14 is illegal in the UK.

 

[Trev]

Would it actually transmit, or does the scan 'just listen' for a nearby access point. I expect the answer to be "Nobody knows" as they say on QI.

 

[MikeSh]

Our router is set on CH 8, so it doesn't explain the frequent (probably 1 in 5 starts) failure of our two FOXs to connect. Shame.

 

[/df]

... Dongles designed for the European market may not be able to access channel 14. ...

I strongly suspect that the dongle hardware is international and the driver config is what implements regulatory compliance.

... is there a risk that the HDR-FOX may broadcast briefly on channel 14 when scanning for an access point? While no one is likely to notice, transmitting on channel 14 is illegal in the UK.

Would it actually transmit, or does the scan 'just listen' for a nearby access point. ...

If anyone wants to read about the various 802.11 protocols, I found this Overview of the 802.11 Physical Layer which seems to add a lot to the Wikipedia article.

A station can use active or passive scanning: with passive it listens for a Beacon frame from another station and presumably replies using the same channel; with active it picks a free channel and broadcasts a Probe Request frame.

The documentation for the RT2870 driver (eg README_STA.txt) indicates that there is a special value CountryRegion=31 which means "use 1 ~ 14 Channel (ch1-11:active scan, ch12-14 passive scan)".

Had I read TFM more closely I would have suggested 31 rather than 5! 31 seems to work for me. However I have no actual test results on radiated signals to confirm that it works as advertised wrt channel usage.

 

[MontysEvilTwin]

Our router is set on CH 8, so it doesn't explain the frequent (probably 1 in 5 starts) failure of our two FOXs to connect. Shame.

I presume you have tried using different WiFi channels? A WiFi scanner program or app will show you the channels your neighbours are using but there is plenty of other interference out there too. Microwave ovens cause problems, though this tends to be more of an issue for the lower WiFi channels, and other devices use 2.4Ghz: wireless keyboards, video senders etc. I would try changing your channel for a few days to see if it helps. I use channel 13 because it tends to be less crowded up there. In the past though I have had problems with Windows PCs and channel 13. I have a quad core desktop (originally on Windows 7) and a netbook (XP) both with cheap, Atheros WiFi cards. Neither could use channels 12 and 13, even with driver updates and the correct Windows locale settings, so I assumed that the cards themselves were designed for the US market (1 to 11 only). A couple of years ago I updated both to Windows 10 and the WiFi started working on channels 12 and 13. I presume this is a bug in older Windows versions for those cards. The card in the desktop stopped working at first with the Windows update so I had to revert to the old Windows 7 driver to get it working: it worked with channels 12 and 13 even with the old driver on Windows 10.

 

[MontysEvilTwin]

I strongly suspect that the dongle hardware is international and the driver config is what implements regulatory compliance.



If anyone wants to read about the various 802.11 protocols, I found this Overview of the 802.11 Physical Layer which seems to add a lot to the Wikipedia article.

A station can use active or passive scanning: with passive it listens for a Beacon frame from another station and presumably replies using the same channel; with active it picks a free channel and broadcasts a Probe Request frame.

The documentation for the RT2870 driver (eg README_STA.txt) indicates that there is a special value CountryRegion=31 which means "use 1 ~ 14 Channel (ch1-11:active scan, ch12-14 passive scan)".

Had I read TFM more closely I would have suggested 31 rather than 5! 31 seems to work for me. However I have no actual test results on radiated signals to confirm that it works as advertised wrt channel usage.

Based on the the link in your post, would the region setting be best set to '1'? This is for channels 1-13 and presumably actively scans those channels.

 

[/df]

Based on the the link in your post, would the region setting be best set to '1'? This is for channels 1-13 and presumably actively scans those channels.

As I understand it, that wouldn't be wrong for UK/Europe, but the value 31 caters for the possibility of using the device in USA or Japan (though why you'd do that when the local DTV systems aren't supported by the HD/R is a fair question: maybe you took it as a player).

 

[af123]

why are there different routines

IIRC, /sbin/wifi-up is used when entering maintenance mode, /mod/sbin/wifi-up is delivered as part of the wifi-helper package. It's a long time since I looked at this stuff though..

 

[/df]

IIRC, /sbin/wifi-up is used when entering maintenance mode, /mod/sbin/wifi-up is delivered as part of the wifi-helper package. It's a long time since I looked at this stuff though..

Yes, so entering maintenance mode, the code runs the settop binary to connect devices, then kills it and runs /sbin/wifi-up in case that didn't work.

While in normal, non-maintenance, mode without wifi-helper, the settop binary does the wifi connection.

And with wifi-helper, /mod/etc/init.d/S00wlan invokes the Jim TCL routine /mod/sbin/wifi-up for CF older than 3.02 (presumably lacking /sbin/swifi) or /sbin/wifi-up otherwise.

Known issues with these are:

• /sbin/wifi-up doesn't handle WEP (for which the key has to be set as parameter Key1 rather than WPAPSK);
• the settop binary doesn't support hidden SSID, and doesn't know the difference between certain WEP key types;
• the CountryRegion issue from this thread which affects all connection methods, but perhaps is an artefact of the driver settings file RT2870STA.dat in CF?

Would it be possible to modify /sbin/wifi-up in the next CF version, either with an updated version or one that punts to a /var/lib/humaxtv/mod/wifi-up if found (or both)?

I have (what I believe to be) improved versions of wifi-up as both shell script (like /sbin/wifi-up) and TCL (like /mod/sbin/wifi-up) should you or others be interested.

 

[af123]

Thanks for taking the time to go through it and yes, I'd be interested in the updated shell script; we might as well drop the Jim (TCL) one now. That came first and the shell version later since it needs to be able to run without the disk mounted - i.e. when Jim is not available.

Would it be possible to modify /sbin/wifi-up in the next CF version

Definitely, although there is no next version currently planned so it could be a while.

You can replace that file yourself via a bind mount, just put something like this in /mod/boot/xinit.d/wifi and make it executable:

#!/bin/sh

mount --bind \
        /var/lib/humaxtv_backup/mod/wifi-up \
        /sbin/wifi-up

 

[Black Hole]

Is that implementable as a package? If so, it would enable people to benefit before a CF roll-out.

 

[prpr]

Is that implementable as a package?

Yes. That's exactly how opkg-beta works. You'd be amazed how similar it is .

 

[/df]

Thanks for taking the time to go through it and yes, I'd be interested in the updated shell script; we might as well drop the Jim (TCL) one now. ...

As attached.

You can replace that file yourself via a bind mount, just put something like this in /mod/boot/xinit.d/wifi and make it executable: ...

Mmmm, nice. With that set up and the attached script mounted over /sbin/wifi, I can do maintenance mode without an Ethernet cable.

In a similar vein, you can create a /usr/bin/env which some scripts expect (eg youtube-dl) by mounting /usr/bin on say /mod/var/usr/bin, linking the contents of /mod/var/usr/bin/usr/bin plus /mod/bin/env to a new /mod/usr/bin and mounting that over /usr/bin from /mod/etc/init.d. No need for unionfs-fuse.

 

[/df]

Yes. That's exactly how opkg-beta works. You'd be amazed how similar it is .

Maybe an updated wifi-up with the bind mount script should be worked into a new version of wireless-helper?

This package has a few dependencies that presumably pre-date the most recent CF versions. We need from CF 3.13 /sbin:

• iwgetid, iwpriv (wireless-tools)
  
• wpa_passphrase (wpa-supplicant)
  
• swifi (functionality implemented via Jim script with jim-pack and jim-sqlite3).

It's not obvious to me how to set up an opkg package with different dependencies according to the target CF version. Presumably the installation script could install differently once the maximal set of dependencies had been installed, but that seems unsatisfactory.