Correcting the Wi-Fi Channel Range

N

Newcoppiceman

Active Member
Newcoppiceman said:
Currently 1 (2.4GHz). The hub is set to smart and it moves around (1, 6, 11) on 2.4.
Click to expand...
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!
 
Newcoppiceman said:
post #8 at
Click to expand...
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

Newcoppiceman said:
I agree with MontysEvilTwin... that it should be CountryRegion=1.
Click to expand...
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!

Newcoppiceman said:
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!
Click to expand...
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?
 
Black Hole said:
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?
Click to expand...
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.
 
Newcoppiceman said:
Is changing the "7" to a "1" in the .dat all I need to do?
Click to expand...
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.
 
Newcoppiceman said:
but I'd prefer to revert to smart mode on the hub.
Click to expand...
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.
 
Newcoppiceman said:
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!
Click to expand...
That table begs the question ... Why would Humax pick 7?
 
Newcoppiceman said:
...
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.
Click to expand...
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.

MikeSh said:
That table begs the question ... Why would Humax pick 7?
Click to expand...
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.
 
MikeSh said:
Any special reason?
I use an analyser app
Click to expand...
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
 
/df said:
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.
Click to expand...
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:
Newcoppiceman said:
? (I have installed the CF.)
Click to expand...
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:
MikeSh said:
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.
Click to expand...
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!
 
/df said:
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.
Click to expand...
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.
 
/df said:
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.
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top