I built 19.07 (-b openwrt-19.07 --single-branch) with ath10k-ct for CONFIG_TARGET_ipq806x_generic_DEVICE_netgear_r7800
Upgraded from 18.06 master and realized that lots of devices are connecting to 5GHz radio but have connectivity issues. Nothing special in the syslog (no disconnect, no crash, nothing), even nothing obvious on tcpdump.
Problematic devices are e.g. Sonos, aTV, no problems with iPhone, Debian.
I found nothing on the forum search, is this just for me or something known?
It is reproducible with binding problematic devices to 2.4 GHz, the issue disappears... binding them to 5GHz, the issue occurs again.
The config didnt change (except of the anonymous wifi-iface names after upgrade from 18.06 master to branch 19.07 SNAPSHOT.
there does seem to be an issue , probably driver level bug triggered by client capabilities... compiling with full ath DEBUG options and sending a verbose log to Mr Greer would likely assist in pinpointing cause.
I have set lots of DEBUG options in .config but I need to ask which one you mean specifically? I will give it a try to provide the logs! I know this thread is like trash without getting into the details...
Right now, it is still reproducible... just flashed latest master and there is no issue at all.
The issue is extremely obvious since airplay(2) to Sonos doenst work anymore when client (iPhone) is connected to 5 GHz and Sonos Speaker is on 2.4 GHz (and appleTV doesnt work on 5 GHz at all).
So either
I have a weird and rare constellation with my custom build that is causing this behavior
or
this is a serious issue with 19.07 that no one else is facing - except of me
Both options are pretty unlikely from my point of view...
19.07 build started with CONFIG_PACKAGE_ATH_DEBUG=y
Yes, master works fine. No problems at all. same config, same setup (always backed up from router, put into built, after flashing nothing is changed).
I am very very afraid that this is a real issue. I dont like real issues like that with important pieces of my infrastructure.
I mean: Airplay doesnt work anymore! I investigated 2 days in this until I found out that it is related to 5GHz...
ok, in this case, a bug on flyspray or a mail to the developers would probably be better than debugging as it's more likely a "porting"=>known issue... ( in least in an intermediate "fix" sense... )
weird constellation... others have seen related bugs for a while... so it's not "new" or unique per-se... but depending what was done at a porting level it may be "new-er" or just a regression ( pre-fork inclusion ).
As you are building the firmware by yourself, you might test which change triggers the error. Master and 19.07 are rather close to each other when compared from ath10k-ct wifi perspective:
As OpenWrt uses a mix of an older kernel and a newer wifi driver infra backported from newer upstream Linux kernels, you might be seeing something that has actually been fixed in Linux and the regular mac80211 already before kernel 5.4.
If master works for you, just use it as an intermediate solution.
I have seen the bug tracker before, but didn't know it has such a nice name
@hnyman I am ok with master, but I wanted to build 19.07 stable latest version for friends routers... I thought like this is the most reliable version for regular people / consumers / customers.
But I am wondering that it is the most unstable version at the moment... isnt this the version that is supposed to be downloaded by regular end users??
I will rather test the downloadable (official) 19.07.0-rc2 to see if it is the same...
Guys what am I missing?
Tested lots of builds - now decided to do some longer use of 19.07.1 tagged version.
Master and also this one do occasionally have issues with 5GHz AppleTV.
Everything else is ok, no crashes, no special logs...
19.07.1 is officially released. Non-compatible with aTV on 5GHz.
Why is this released?
For basic functionality, OpenWRT was working well in the past. This is not the case anymore Whats wrong?
Do you really expect that somebody would have tested all possible WiFi hardware and driver combinations with all firmware versions of all WiFi client devices worldwide????
Quite possibly your Apple TV has some driver option selections that now misbehave with the current hostapd and WiFi hardware drivers. Fault can be on either side.
I assume that Apple is already looking at the matter for you and they will update their TV firmware soon? Have they already promised you a fix date? That is quite as probable as your implied assumption that all devices would have been tested to work with all WiFi hardware and drivers.
E.g. the 802.11n and ac standards were implemented in devices long before the final standards were released. Similarly the allowed encryption ciphers are gradually changing. Old TV firmware may contain a selection of ciphers that have been deprecated. Both hardware and wpa drivers also change the interpretation of some rules between strict, mandatory, relaxed approach, so something that may have falsely worked until now, may now stop working. And vice versa, some broken things may have started to work...
The sad part is that practically all modern radio chip drivers (like ath10k, mvlwifi,..) contain a closed-source firmware blob either from the chip manufacturer or some other party (like CandelaTech for -ct firmware blob), which means that the OpenWrt dev can't even look into the low-level driver details. In the good old ath9k days, the whole driver was opensource and only the device-specific calibration data table was a blob on each device.
The combination of devices and drivers is so huge that there will always be some problematic combinations. But nobody can debug those than ones who have the problematic combination, so I hope that your help in fixing your specific problem will prove to be valuable.
As of now, it is very much guessing, but I know the same issues with Fritzbox users. Same connectivity issue which was solved after Fritz Firmware updates.
I was able to view 120 MB aTV logs in the meanwhile.
Networking: Error Domain=NSURLErrorDomain Code=-1009 "Es besteht anscheinend keine Verbindung zum Internet."
Wifi: No idea. Tons of logs with lots of stuff, but nothing "self-explaining"...
Actually, this all started to happen after updating OpenWRT. TVos was not updated / changed.
So I guess (again guessing) that the issue occurs somewhere on the router... and I have no big clue where to start analysing it on router side. Down to the tcpdumps, there is nothing special in the captures.
In this thread, someone posted that this is a "known issue" so maybe also others experience the problem and might have a better idea?
Whats wrong?