Can you change your country to Panama from the wireless country setting? I am waiting for your reply.
Not at all a good idea (read actively illegal), even more so if there really is a radar near by.
3 Likes
From the OP's thread back in October...
I had to do some research on this to get a better understanding of that as a solution and the legal considerations around it, and It seems to me there is a legal white zone where this approach is appropriate.
Under the US configuration, the maximum transmit power is 23dbm and both DFS and non-DFS channels are selectable, however for me.. all channels seem to be suffering from DFS cutting the radio off even if the channel selected is within the legal range. So if this behavior is erroneously overcorrecting and can be disabled via the solution above, I'm still within the legal white zone by going below 23dbm transmit power and utilizing a non-DFS channel.
Thoughts?
Mind you, I just tested this solution, and though it seemed to be promising and lasting a lot longer, it still crashed. Will have to monitor with the UART cable when it comes in.
1 Like
Yes, that zone is called Panama, a small independent republic in Central America, roughly 75'000 km² in size and inhabitated by just over 4 million citizens.
IEEE 802.11d is evaluated by modern wireless clients, messing up both your client's regulatory settings and that of your neighbours. As a result e.g. all you Intel wireless cards in notebooks and desktops will only give you access to 5 GHz channels after a passive scan reveals unanimous agreement about your region (yes, one bad neighbour can create real trouble here).
If you do stay within the DFS-less frequency ranges (ch36-ch48), DFS is not necessary and not in use, any remaining problems would not be caused by DFS or radar events in your environment. Changing the region settings will not change this, you merely extend the frequency range claimed not to be DFS encumbered into ranges you certainly aren't allowed to use without DFS.
lol, I hear you. I was going under the assumption that changing the country selection for your router isn't illegal. Operating said router outside of the legal signal and strength range for your country is.
According to what you're saying, does this mean all wireless access point devices under IEEE 802.11d is transmitting the country code, ex "US US US US PA US US US"?
DFS was a strong theory, and still might have something to do with it. Now I'm doubting and looking forward to seeing exactly what is going on when the crash happens. Channels 36-48 have still shown to be more stable than the DFS channels, which raises suspicion.
Any semi-contemporary AP built within the last decade will use IEEE 802.11d and transmit something like:
DS Parameter set: channel 6
Country: DE Environment: Indoor/Outdoor
Channels [1 - 13] @ 20 dBm
and
DS Parameter set: channel 132
Country: DE Environment: Indoor/Outdoor
Channels [36 - 48] @ 23 dBm
Channels [52 - 64] @ 20 dBm
Channels [100 - 140] @ 26 dBm
Channels [144 - 144] @ 0 dBm
Channels [149 - 173] @ 13 dBm
Power constraint: 3 dB
it's the only way to get e.g. Intel WLAN cards in client devices to use the 5 GHz band at all.
You guys have all been so responsive and awesome. Thank you so much. I really appreciate being here with the opportunity to learn.
I've now identified the error message thrown at the exact time of wifi going down.
Thu Jan 13 21:31:29 2022 daemon.err hostapd: 20/40 MHz: center segment 0 (=138) and center freq 1 (=5710) not in sync
Thu Jan 13 21:31:29 2022 kern.info kernel: [ 1931.325762] device 5G left promiscuous mode
Thu Jan 13 21:31:29 2022 kern.info kernel: [ 1931.325937] br-lan: port 2(5G) entered disabled state
Thu Jan 13 21:31:29 2022 daemon.notice netifd: Network device '5G' link is down
Does this give any clues as to what's going on?
What channel and channel width?
You'll get that message if you're on a DFS channel...50 to 144 in the U.S.
Hmm, I was on 144 at 80mhz. Just switched to 147, and waited for it to crash.
Got nothing in the kernal log. UART cable comes in tomorrow 
This router's ability to flabbergast me has no bounds.
The UART cable came in today. I open the router. Soldered pins to the serial connections. Monitored the terminal. Started a large steam download at 28.2MB/s.
Nothing.
No crashing what so ever.
I can only think of two things that it could possibly be at this point.
- The adapter is overheating with the enclosure on.
- Maybe static buildup as I did get shocked a few times feeling the plates.
I'm leaning towards the first.
Very strange!
Are you able to put the top on loosely with the serial still connected and test again?
The nbg6817 is indeed running considerably hotter than its competition, like e.g. the r7800.
May have been one of the reasons it was discontinued in 2021.
Unlikely, all other ipq806x devices have been discontinued in favour of ipq807x; nbg6817 and r7800 were pretty much the last holdouts.
I found this post supporting the thermal theory. His earlier post hypothesized that changes between OpenWRT v18 to v19 might have put more load on the CPU than had been present before since he didn't run into the issue on v18.
Don't know if this would work on a NBG6817...
It does, thermal sensors are present and supported.