There’s no crashes or reboots in those logs so nothing to go on.
Without capturing the actual crash via serial you will just be guessing.
Are you doing anything complex such as vlans or multiple ssids? Or running additional software on the router? Vpns, samba, asterix etc could make it fall over under load.
Do you know of any good resources or tutorials on putting this together. I can definitely solder a few pins to the board and make a cable if there's a guide for me to follow.
Yes, I did have some vlans, as well as adblock and SQM going, however I've tried disabling all of these to no avail. This aside, the issue persists on the stock firmware, so I'm willing to consider these not a part of the problem.
After some further testing today, I was able to find that channels 36-48 at 20hz is the only range where the driver didn't fully crash on high bandwidth downloads, 36 being the most stable. It did however cut out, and immediately come back on frequently.
There's a radar tower not more than 5 blocks away from my apartment at the airport. I honestly do think this is probably some crazy stuff happening due to DFS that most people don't run into because they aren't near one. Still, I think DFS is not working properly at all if this is the case.
Getting serial access is straightforward.
Purchase a usb to uart / ttl serial adapter, crack the router open and find the serial header. Attach leads from the usb to uart to the tx rx and ground. Power your router up.
Then watch the console till login prompt appears.
Adapter should be 3.3v or switchable 3.3 / 5v. Don’t connect vcc under any circumstances.
If there’s no header on the board to connect to you don’t have to solder one, holding pins on with a clothes peg is fine, or I’ve used alligator clips with electrical tape one the other side of the board.
Thanks,
Cable comes in Friday.
Appreciated
If it also happens with the OEM firmware, and if you're still under warranty, I'd suggest to look into the warranty options first (flash the OEM firmware twice and your device is back to vendor standards), as time might be running out.
You can also try an updated (QCA 'ath10k' wireless chipset-) firmware from https://github.com/kvalo/ath10k-firmware/tree/master/QCA9984/hw1.0/3.9.0.2 --> /lib/firmware/ath10k/QCA9984/hw1.0/firmware-5.bin.
Given your environment you described in this thread, there may not be much else you can do with that device...except used a wired connection for high-bandwidth downloads.
Can this be done through SSH, or would I have to learn how to compile OpenWRT myself in order to accomplish this?
You can do that via ssh, just replace the existing file with the downloaded one (make sure to download it properly, not the HTML representation of github's webinterface - or just clone the git repo and copy it from there via scp).
First, thank you so much to everyone who has responded and tried to help me diagnose this issue. I FINALLY tracked down the culprit, and it was none of the above items already discussed.
According to this thread: https://steamcommunity.com/discussions/forum/0/3118150513202463640/, someone suggested disabling IPv6 in the client wireless interface.
And this worked. Seriously this worked. I have no more crashes and I'm downloading at 29mb/s. Which leads me to my next conundrum, though not as pressing. Is my router configured correctly for IPv6?
I haven't done any IPv6 related configuration.
IPv6 works reliably on OpenWrt and the nbg6817.
I believe you, and I jumped the gun. I managed to download at 25gbs at nearly 30mb/s before the interface crashed again.
I'm going to go take a walk...
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.
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.
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.