RT-N66U, 378.51, 5 GHz and OS X - 802.11d available or not?

[nmt1900]

This is more or less for you information - I mean, that it just might be of some help for ones struggling with the wifi on their Apple devices...

As we know, last months have been a huge problem for many, who are using 10.10 Yosemite - Apple has its' forums full of long threads on the issues and some have deemed whole thing as a disaster and all this might add up to confusion, if there are other "coincidences", which might turn out to be problems without any solution.

So... I have a Macbook Pro which has been working on wifi without problems for years on any networks and both bands - but recently a strange problem occured.

Macbook worked on any channel of 5 GHz band before the problem surfaced - all from 36 to 140, just as my Windows laptop and few Android devices, but now for some reason Macbook just plainly refused to see my router on channels 52 and up. Windows machine and Androids still worked just fine...

Then I took the Macbook to work with me to try out the guest wifi at the office - we have wide wifi coverage all around the office with multiple AP's on both bands and on channels all across the frequency bands. Funny or not, but Macbook connected and worked just fine there and saw all AP's on 5 GHz band - connected on channels 60, 108, 132 - take your pick... Then I came home and observed the same old behaviour - network was not visible, period. Absolutely invisible - Wifi Explorer did not show any trace of my network. No dice...

I was thinking, that maybe this is really something about these problems with Yosemite and started all kind of tinkering until I found few lines on system log, which explained everything and saved me from further waste of time.

When I was at work, there was

9.03.15 19:38:18.000 kernel[0]: en1: 802.11d country code set to 'FI'.
9.03.15 19:38:18.000 kernel[0]: en1: Supported channels 1 2 3 4 5 6 7 8 9 10 11 12 13 36 40 44 48 52 56 60 64 100 104 108 112 116 120 124 128 132 136 140

When I got home, I got

9.03.15 20:44:22.000 kernel[0]: en1: 802.11d country code set to 'EU'.
9.03.15 20:44:22.000 kernel[0]: en1: Supported channels 1 2 3 4 5 6 7 8 9 10 11 12 13 36 40 44 48

There you go! Asus with hardcoded 'EU' country code, channels 52...140 and Apple devices -> no dice.

No need for trying to find a way around this. This is "by design" with this combination of devices - or is it?

 

[joegreat]

When I got home, I got

9.03.15 20:44:22.000 kernel[0]: en1: 802.11d country code set to 'EU'.
9.03.15 20:44:22.000 kernel[0]: en1: Supported channels 1 2 3 4 5 6 7 8 9 10 11 12 13 36 40 44 48

There you go! Asus with hardcoded 'EU' country code, channels 52...140 and Apple devices -> no dice.

No need for trying to find a way around this. This is "by design" with this combination of devices. Don't waste your time and switch to channel outside DFS range, if possible.

Hi,

I am also on EU regional settings, but I have the higher channels avaliable...

chief@RT-AC68U:/tmp/home/root# nvram show | grep EU
wl0_country_code=EU
wl1_country_code=EU
0:ccode=EU
1:ccode=EU

Did you set the Regulation mode for 5GHz WLAN in the Wireless/Professional settings to 802.11d+h as I did?

With kind regards
Joe

By the way: Which router model do you have? I remember that my N66U router did not have the high channels with older firmware... or, am I wrong?

 

[nmt1900]

Well... how about that!

I was just writing up the thing about how all worked just a month before, when I was doing channel testing here and only change from that time was Merlin's update to latest version - and regulation mode was not set to "off" back then - "EU" was clearly visible in screenshots...



Something must have been thrown the setting to position "h only" as this dropdown has got rid of useless entries like "Off(default)"?

It is interesting that although Wifi Explorer still shows EU on the CC column, Wi-Fi dropdown menu shows "Country code: FI". It seems like kernel has assumed the country code as "FI".

Now it seems, that we're have even found a solution to the problem!

Thank You!

 

[nmt1900]

Now it seems, that deeming this as a solution might be a bit premature. Connection was up for more than hour - until this "intermittent disconnection" (as known to many Yosemite users).

After that it was "country code set to 'EU'" and of course system made itself "blind" again. Disabling and re-enabling wifi on Macbook lead to same result.

Back to square one?

 

[nmt1900]

By the way: Which router model do you have? I remember that my N66U router did not have the high channels with older firmware... or, am I wrong?

This is N66U and high channels "appeared" with 378.50. Results of channel testing (on different devices) showed, that channels around 100...108 gave much better signal levels that channels on lower end of the band. That was initial reason for this channel selection.

Now it looks like going back to low channels is still the most reliable solution for this "puzzle"...

P.S. And system still says, that country code is 'EU'...

9.03.15 23:29:24.000 kernel[0]: en1: 802.11d country code set to 'EU'.
9.03.15 23:29:24.000 kernel[0]: en1: Supported channels 1 2 3 4 5 6 7 8 9 10 11 12 13 36 40 44 48

It just does not seem to work - no matter what "regulation mode" is set, if it is not "off" - which is not possible any more. If OS X assumes country code EU, it just stops listening to high channels. I do not know, if this is a part of these alleged Yosemite "screwups" or not...

 

[nmt1900]

Now some more testing with restarting the computer - result is the same.

10.03.15 20:22:51.000 kernel[0]: en1: 802.11d country code set to 'X3'.
10.03.15 20:22:51.000 kernel[0]: en1: Supported channels 1 2 3 4 5 6 7 8 9 10 11 12 13 36 40 44 48 52 56 60 64 100 104 108 112 116 120 124 128 132 136 140
10.03.15 20:22:51.562 sharingd[337]: 20:22:51.561 : SDStatusMonitor::kStatusWirelessPowerChanged
10.03.15 20:22:52.000 kernel[0]: en1: 802.11d country code set to 'EU'.
10.03.15 20:22:52.000 kernel[0]: en1: Supported channels 1 2 3 4 5 6 7 8 9 10 11 12 13 36 40 44 48

Now I found this thing on one other thread and started to think - does 802.11d even work on 378.51 any more? It looks like 802.11d was the thing, that made high channels possible (by means of switching EU->FI) - but now this is not happening any more...

But as of January 1, 2015, the FCC has ruled that the use of 802.11d in any devices sold after that date is not permitted. I believe from what I've also read about ETSI, that it has also followed suit (although I've not checked recently, the last RT&T decision that I read contained wording about not allowing end-users to change country codes or power that would suggest ETSI is imposing the same restrictions as well). Which is kind of odd, since the GUI picture that S.D. posted up-thread seemed to suggest that 802.11d+h was being enabled for use on those channels that were formerly not exposed by Asus (120, 124 and 128).

But in any event, if you're in North America, new client devices will no longer be able to look to the wireless AP to ensure automatic compliance, and won't "switch" depending on 802.11d beacon signals; instead, the device (and by this I mean client devices) will have to be locked to use only U.S. frequencies. Apparently, devices already out on store shelves or sold and in use (i.e., those that were certified by the FCC prior to January 1, 2015) are "grandfathered" in and can still be used, but after January 1, all new have to be preconfigured and hard-coded just to one regulatory domain.

 

[joegreat]

Now it seems, that deeming this as a solution might be a bit premature. Connection was up for more than hour - until this "intermittent disconnection" (as known to many Yosemite users).

After that it was "country code set to 'EU'" and of course system made itself "blind" again. Disabling and re-enabling wifi on Macbook lead to same result.

Back to square one?

Hi,

I set my N66U router (running as Access Point) to high channel 136 upper and could connect to it without any problem! The device I use is a LG Nexus 5 Android Phone...

With kind regards
Joe

 

[nmt1900]

Of course! This problem is related to Apple devices and (as now observed by little more investigation -> https://www.google.com/search?q=802.11d+OSX) appears to be quite well known - Apple devices are unable to connect or even see networks on high channels of 5 GHz band without 802.11 d+h.

I have difficulties to find any other explanation for this problem to occure after last upgrade, because everything worked with 378.50, but now no dice whether "regulation mode" is set to 802.11h or 802.11d+h. This upgrade also removed other entries from this dropdown on 5 GHz band and now this really might be unsure, whether regulation mode selection works or not...

P. S. As stated before - my Nexus 5 and Thinkpad (with Windows 7) are connecting without problems even after the upgrade! Problem is mainly related to Apple devices and very probably 802.11d.

P. P. S. I should probably try last possible thing - doing a full reset and reconfiguration from scratch to see, if it might help (last reset was with 378.50)...

 

[nmt1900]

Now everything is reset and it seems, that at least GUI is doing its' thing in right way

Setting it to "802.11d+h" gives

admin@192.168.1.1:/tmp/home/root# nvram show|grep wl_reg_mode
size: 43761 bytes (21775 left)
wl_reg_mode=h

and setting it to "802.11h" gives

admin@192.168.1.1:/tmp/home/root# nvram show|grep wl_reg_mode
size: 43775 bytes (21761 left)
wl_reg_mode=strict_h

Only unknown thing here is whether flipping this nvram variable affects anything or not - and that is up to firmware code itself.

All I can tell is that everything worked with 378.50 with the same Macbook Pro and there was no updates done to this machine since. Not much options left, I must say...

 

[john9527]

I think the reg mode 'setting' discussion is a red herring..... In the prior level of code, no matter what you set it would be forced to 802.11d+h. The new code just let's you choose between two options of 802.11h or 802.11d+h.

I see that Merlin did a couple of merges between the two levels....if you check the wl driver level in the Tools page, has it changed? Merlin reverted the driver for the AC66 due to problems....maybe he also needs to revert the N66.

 

[nmt1900]

wl0: Oct 17 2014 12:47:21 version 6.30.163.2002 (r382208)

This is on 378.51. What it was on 378.50 - I am not sure where to look for it right now. Merlin probably knows better

Maybe there's really some problem, because d+h worked before...