• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Correcting the Wi-Fi Channel Range

Newcoppiceman

Active Member
Currently 1 (2.4GHz). The hub is set to smart and it moves around (1, 6, 11) on 2.4.
After forcing the hub to channel 6 I was able to connect ok, but I'd prefer to revert to smart mode on the hub.

Having consulted:
(i) https://www.cnrood.com/en/media/solutions/Wi-Fi_Overview_of_the_802.11_Physical_Layer.pdf
1701118514139.png
and (ii) https://www.cyberciti.biz/files/README_STA.txt
@> CountryRegion=value
value
0: use 1 ~ 11 Channel
1: use 1 ~ 13 Channel
2: use 10 ~ 11 Channel
3: use 10 ~ 13 Channel
4: use 14 Channel
5: use 1 ~ 14 Channel
6: use 3 ~ 9 Channel
7: use 5 ~ 13 Channel
31: use 1 ~ 14 Channel (ch1-11:active scan, ch12-14 passive scan)

I agree with MontysEvilTwin, post #8 at https://hummy.tv/forum/threads/intermittent-wifi-connection-failure-solved.8768/ that it should be CountryRegion=1.

However, I'm struggling with the steps I need to take to implement this (apparently simple) change. I will re-read the related threads signposted by Luke, albeit that some of the detail therein is beyond me at this stage!
 
post #8 at
The #n in the top right of a post is actually a link to the specific post instead of making your readers land at the top of the thread, thus: https://hummy.tv/forum/threads/intermittent-wifi-connection-failure-solved.8768/post-123530

I agree with MontysEvilTwin... that it should be CountryRegion=1.
That might be considered ideal, but it hardly matters if a WiFi client device is capable of scanning for networks over channels 1-14 when the WiFi server device is only operating on channels 1-13. It's not going to suddenly cause the network to switch to an illegal channel!

However, I'm struggling with the steps I need to take to implement this (apparently simple) change. I will re-read the related threads signposted by Luke, albeit that some of the detail therein is beyond me at this stage!
If you want help, you need to be specific about what you're struggling with. You've discovered the file editor in WebIF >> Diagnostics, I presume?
 
The #n in the top right of a post...

That might be considered ideal...

You've discovered the file editor in WebIF >> Diagnostics, I presume?
Thanks.

Ok.

I have now!

Is changing the "7" to a "1" in the .dat all I need to do? Some of those threads suggested it was a bit more involved.
 
Is changing the "7" to a "1" in the .dat all I need to do?
Try it and see. The only risks I am aware of are the relevant file getting over-written on update, or it being in a read-only file system, or it being in a temporary file system and recreated every boot.
 
but I'd prefer to revert to smart mode on the hub.
Any special reason?
I use an analyser app to check where the neighbours are and then pick a centre channel with minimum overlap. I suspect if everyone is in auto they'll end up chasing their tails, so to speak.
 
After forcing the hub to channel 6 I was able to connect ok, but I'd prefer to revert to smart mode on the hub.

Having consulted:
(i) https://www.cnrood.com/en/media/solutions/Wi-Fi_Overview_of_the_802.11_Physical_Layer.pdf
View attachment 6808
and (ii) https://www.cyberciti.biz/files/README_STA.txt
@> CountryRegion=value
value
0: use 1 ~ 11 Channel
1: use 1 ~ 13 Channel
2: use 10 ~ 11 Channel
3: use 10 ~ 13 Channel
4: use 14 Channel
5: use 1 ~ 14 Channel
6: use 3 ~ 9 Channel
7: use 5 ~ 13 Channel
31: use 1 ~ 14 Channel (ch1-11:active scan, ch12-14 passive scan)

I agree with MontysEvilTwin, post #8 at https://hummy.tv/forum/threads/intermittent-wifi-connection-failure-solved.8768/ that it should be CountryRegion=1.

However, I'm struggling with the steps I need to take to implement this (apparently simple) change. I will re-read the related threads signposted by Luke, albeit that some of the detail therein is beyond me at this stage!
That table begs the question ... Why would Humax pick 7?
 
...
Is changing the "7" to a "1" in the .dat all I need to do? Some of those threads suggested it was a bit more involved.
The driver settings file is in /etc/ which is RO storage. You can't directly modify this file, unlike files in the RO filesystem, like /etc/resolv.conf, that were configured as links to RW storage (eg /var/lib/humaxtv) when the firmware was created.

As I explained in the old post about this, the setting for the WiFi adapter can be changed dynamically before making the WiFi connection (using the iwpriv command) so avoiding the need to make the default settings file appear writable. But neither of these things can be done in this forum, ie without installing the CF.

That table begs the question ... Why would Humax pick 7?
As posted in another thread regarding development practices, my impression is that if it didn't block shipping, whatever value was there would stay the same. Maybe the value 7 was based on the applicable national wireless regulations ~15 years ago; maybe some Humax dev thought 7 was good because it was a number in the middle of the (quite unrelated) 2.4GHz channel range. The Linux driver from the 2009 (2009.bz2 from driverguide.com, eg) has CountryRegion=5.
 
Any special reason?
I use an analyser app
To avoid WiFi connection issues if the local RF environment changes - this has happened previously.
Me too; I use NetSpot.
Interestingly, my BT Hub6 only offered channels 1, 6 and 11 for fixed operation - these are different from the rest as they are non-overlapping channels (and the only ones I've noted the hub to have used in smart mode):
1701146921812.png
 
As I explained in the old post about this, the setting for the WiFi adapter can be changed dynamically before making the WiFi connection (using the iwpriv command) so avoiding the need to make the default settings file appear writable.
It will all be a lot easier (and of benefit to everyone) if some kind person (wink wink) releases a package to do this. I'm a little surprised one hasn't been – OK, so there was no pressure before, but we're all about correcting Humax's errors aren't we?

The below no longer relevant because the discussion has been moved:
? (I have installed the CF.)
Yes, but you're discussing it in the wrong section of the forum (this section is specifically for matters affecting the stock unit) and polluting the thread.

Mods: I suggest splitting this thread at post 36, and moving to the CF section under the title "Correcting the Wi-Fi Channel Range" (the OP can then edit it if he wants).
 
Last edited:
I use an analyser app to check where the neighbours are and then pick a centre channel with minimum overlap. I suspect if everyone is in auto they'll end up chasing their tails, so to speak.
That's what I did. I see no point in it hopping about, and I definitely see no point in it hopping between only three channels!
 
the setting for the WiFi adapter can be changed dynamically before making the WiFi connection (using the iwpriv command) so avoiding the need to make the default settings file appear writable. But neither of these things can be done in this forum, ie without installing the CF.
To use the iwpriv command before making the WiFi connection must surely mean using the Lan. I'm trying to ditch this as the only practical implementation for us is to use powerline - which is a faff. And I'd have to do this each time I want to connect?

If there's no way to make a permanent change to the CountryRegion value I'll either have to use a fixed WiFi channel above 4, or abandon attempts to connect via WiFi and stick with the powerline Lan. Unless I'm missing another solution?

(And apologies for polluting the other thread.)
 
The current version of the wifi-helper package tries to fix all the driver parameters to avoid manual intervention but I believe it isn't guaranteed to be used, at least initially, because the Humax blob may succeed in making the connection first.
 
The current version of the wifi-helper package tries to fix all the driver parameters to avoid manual intervention but I believe it isn't guaranteed to be used, at least initially, because the Humax blob may succeed in making the connection first.
Does this mean wifi-helper will most likely work (take precedence) if we do something like disconnect then reconnect WiFi, or will that be pointless? If so, then maybe that can be automated?
 
Generally it works without intervention. Forcing reconnection using the on-screen UI may sometimes be necessary: presumably, parameters set with iwpriv... sit in some driver data store that survives reconnections. Also, the hacks that are supposed to restore the last connection even after an uncommanded reset/retune don't always succeed (for serious testing of the sort that might fix this, read about Microsoft's USB cart of death). It's difficult for the system to know whether it's connected to the right base, or rightly not connected. Some sort of General Intelligence is needed to poke it on these occasions.
 
Back
Top