two days ago, I decided to give hostapd a try (again and again and again) by reducing my power consumption for 24/7 devices by removing my WIFI ap for IoT devices.
Since the devices use WIFI 4 only, I added a WIFI 4 Realtek giveaway WIFI USB stick I got many years ago, checked the HT capabilities and it works.
First I added my OpenDTU to it and yesterday I still could reach the webif. Yesterdays I added my Shelly devices and it also worked. Atm my client is connected to the network to check out what may be wrong, because:
Today I can’t connect to the webifs of the devices anymore.
Watching the hostapd tells me that the devices are connected. The Shelly LED indicated the same and also that it has internet access.
My client also works and has internet access. However I can’t even ping the other clients within the same network.
There are no information in the fw log and the wireless log only tells me that my OpenDTU disonnects and reconnects some times (don’t now why). That doesn’t happen with the Shelly devices.
The kernel log tells me until yesterday for the WIFI (but I had to change the config because Shelly has an issue with special characters in the password):
11:22:14 kernel: usb 2-1: rtl8xxxu_send_beacon_frame: Failed to read beacon valid bit
For now there are no entries.
So what’s wrong with it now? I don’t want to restart (this will probably solve it for a time) until the situation is clear.
Just waited until midnight and surprise, without doing anything it’s working again. If I remeber right, there has been or still is a bug with captive portal and unlimited coupons and the internal time measurement. I still use captive portal and i guess this problem still exists.
to see if we need to do anything special, but the max clients is 148 on them, and a few years back the AP settings were not in it and you had to add them and compile the driver. Obviously the access point info is in but I wonder what max number of clients is set. Since it looks like this:
if (priv->fops->max_macid_num)
hw->wiphy->max_ap_assoc_sta = priv->fops->max_macid_num - 1;
and when we had to manually add it to make it an access point we just add this at the bottom of this file:
Problem back. Just connected to the network and the clients are not reachable. Atm there are only 3. With iwconfig I don’t get any info about the max number of connections, iwlist tells me 127.
That message 11:22:14 kernel: usb 2-1: rtl8xxxu_send_beacon_frame: Failed to read beacon valid bit comes every time something connects to the network.
I also wonder that ipfire itself can’t even ping network members. I restarted hostapd but no change.
I restarted ipfire, still nothing. Internet is there, but internal communication not possible.
This is a driver bug. For some reason the beacon cannot be sent and that results in the network disappearing for all clients that are not connected yet.
But probably there is another underlying issue there: Firmware lockup, general breakdown of the conversation of the driver with the firmware. I would not recommend using Realtek at all. I don’t think we have anything here that results in a stable network.
I just had it here. Never used, nobody wanted to have it so I was happy to have a usecase for it, finally.
Honestly what brand is performing well? There are not that many out there:
Intel: no AP mode (but it performes well as client: 2Gbit @ 6GHz)
Realtek: not good?
AMD: don’t know, even I don’t know any USB dongles
Mediathek: don’t know
I guess that’s it with the amount of manufactorers.
Qualcomm is the only one which implements the features that you need to run an AP. DFS, automatic channel selection, and so on. They also do much more in hardware and less in the driver. The Realteks are much closer to a SDR where the software is doing most of the work.
That are all very disappointing infos. However, if the connection comes back tonight I will start something like pingplotter so see when it stops working. Maybe this is a periodic problem.
Edit: switched my client back to green and I can access the webifs in blue
No. Their chipsets only use SDIO and PCIe as far as I know. Only the latter is interesting for us.
The USB bus is way too slow to communicate with WiFi. There is simply too much work to do for the protocol and it all has to be done in timely fashion. Especially when transmission rates increase.
Your current module seems to have a softMAC only which contributes to the problem. Every 102ms, there has to be a beacon frame sent. Not every 101ms, not every 103ms. Every 102ms. Those timings are pretty hard to get right over USB. Especially USB 2.0.
None of them are cheap. Either you want a well-functioning AP that has decent, modern features or you want cheap. There is no sweet-spot that I am aware of.
It’s cheap because it costs only about 5€. The requirements for that NIC are very low, because the network members don’t need performance. The PCIe M.2 WIFI port is already in use for a WIFI bridge on RED. So there is only USB left.
Just had a look: there are adapters from key m to key e. Maybe that works for additional PCIe WIFI modules. Any recommendation for Qualcomm/Atheros WIFI modules?
Finally I have reactivated my AP for those IoT devices. For me the whole AP solution is kind of useless, if just a single wlan adapter manufacturer may work and that only with PCIe. That’s nothing to blame on IPFire and shows up, why bananapi even designed its own wlan adapter to work with opemwrt.
WiFi is a wide field nowadays.
But the greatest use case are cllent adapters. Therefore most manufactures focus on this topic.
The AP needs much more functionality. This isn’t only true for wireless but for all master-slave systems.
