I have installed OpenWrt on a RPI3B and configured it to act as an Wireless access point. I use the LAN-port to connect to the network (as DHCP-client) and the onboard wifi as access point. It automatically chose channel 11 and it worked very well. However, when I tried a different channel (7), the Wireless section under Network became really slow to load and when it did it only said: 'Collecting data...' .
It was undetectable by any device and it started spawning a bunch of error messages like these in the kernel log:
I found these messages leading up to the messages above:
[ 545.844382] device wlan0 left promiscuous mode
[ 545.858155] br-lan: port 2(wlan0) entered disabled state
[ 547.187650] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 547.206012] br-lan: port 2(wlan0) entered blocking state
[ 547.220612] br-lan: port 2(wlan0) entered disabled state
[ 547.235395] device wlan0 entered promiscuous mode
[ 547.526600] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 547.537835] br-lan: port 2(wlan0) entered blocking state
[ 547.547779] br-lan: port 2(wlan0) entered forwarding state
I checked the other channels too, even 12 and 13 (Europe, so legal here). 12 and 13 didn't work for other reasons; so I'll leave that as it is. The other channels worked normally, except for 8, 9 and 10, that demonstrated the same behavior. This seems really weird to me and I haven't found anything on the internet about it. It seems like the non overlapping channels work: 1, 6 and 11 and the channels between 1 and 6, but those between 6 and 11 don't.
I set "Force 40 Mhz mode" setting under advanced, but it behaved the same way, but after some time it started working normally. When I changed to channel 8 it broke again. I tried a reboot, but that didn't help. Then switched back to channel 7, but it doesn't work anymore. So, it didn't work, but thanks for the suggestion.
If I may ask, why would you want to chose an overlapping channel and set the bandwidth to 40 MHz? Even if channels are 1, 6 and 11 are busy, they are still better than the rest. Being on an overlapping channels and setting the bandwidth to 40 MHz is making it worse for everybody including yourself.
@Hegabo, no I certainly wouldn't, but if it fixes the problem I have to try it. I have it off now, because it would otherwise only cause interference.
The setting option htmode in /etc/config/wireless stays HT20 even when i set Force 40Mhz mode
it looks like this option htmode 'HT20'.
So I tried setting it to 'HT40' and 'HT40+', but both said: Wireless not associated. Removing the setting just made it fail again.
I still don't understand why do you need these channels in the first place. I can't think of a scenario where these are better than non overlapping channels.
@Hegabo, Not trying to be rude, but that doesn't matter for the answer. But I do indeed not need those 4 in particular, but I just want to be able to. When you don't live on the countryside and not in a crowded flat these options come in handy. When the sources are not too close to one another they can overlap without problems. I didn't study radio technology, but my father did and he said that it didn't matter in that scenario. It is however not good to be on a crowded channel, because they can and will interfere with one another (1, 6 and 11 are of course automatically picked by vendor wifi access points; I checked this with a wifi monitor). I am not on a crowded channel at the moment, so there is no haste of course, but I think it's a rather odd issue my rpi can't do it and that is why I want to know.
Well nevertheless, my question is: why does my rpi go crazy when I set channels 7-10. So, let's not focus on the why I want it and if it's a good idea or not.
I did set the localization setting on Raspbian with raspi-config and after that again with openwrt settings. There was a problem reported there (with channel 12 and 13 actually and not 7-10), but I followed this workaround, so it should work.
My guess would be that Broadcom chips are not well supported.
The channels are based on an old system where they are 5 MHz apart. But a g or n signal consists of 58 radio carriers that are evenly spaced through a spectrum that is 20 MHz wide. So if you use a channel between 6 and 11 some of your carriers will receive interference from (and interfere with) networks operating on both channels 6 and 11. This is not good for you.
@mk24 Can you please not go on about the channel 1, 6, 11 thing. I am not here to discuss this. I don't know a thing about wifi or broadcasting, so I can understand it nor confirm you are right. I am also not going to just accept what you say when the people that designed the standard are definitely not stupid and there are 2 camps in this discussion: Use overlapping channels; don't use overlapping channels. I don't know how much it helps, but every channel here is below -100db.
Elaborating on the support: it doesn't seem to be badly supported, cause I would've found that when googling and looking on the openwrt page of raspberry pi. If that is the reason though, it would be a shame.
Raspberry Pi isn't a device that was designed to be a router.
Broadcom devices are known to be unfriendly to open source.
Channels 1, 6 and 11 are the good 2.4 WiFi channels. Nothing good comes of using an overlapping channels. Nobody says otherwise.
People here are trying to help.
If you insist on fighting for a lost cause (such as being on an overlapping channel) then that's up to you how to spend your time. It's certainly "nice" to have all channels working, but it's probably of no useful use.
@Hegabo I do indeed appreciate that you try to help me and I do take notice of your opinions on the wifi channels. However I said I was done with that discussion, so points 3 and 5 are useless points. Talking about point 3: there are people who have studied for it, that say the exact opposite of what you say. If you know so well: then just come with research to back it up or at least your degree in radio physics. Then I don't mean Cisco's crowded building publication, but one testing this in a spaced neighborhood. What I am trying to say: if you want to talk about it so bad don't just repeat your opinion and try to depict me like a stubborn moron, but contribute something. I am not even taking sides in this, but I am doubting both sides. Yours is just the only one coming up here.
Point 1 is also an example of what goes wrong on so many forums: somebody wants to do something that is weird, useless or not the default use case in the eyes of other people. The person creating the thread obviously knows this, but still wants it. The result is that they try to talk that person out of it, instead of either not participating or saying how you would be able to do it.
The raspberry pi especially is what you make of it, so here that argument makes even less sense.
Point 2 I know, but I know it works on other operating systems, so it's weird. I'll try that out, if I can't get this to work, but I like being able to just connect through a nice interface to the pi through OpenWrt.
I was not trying to take you out of it. My point was that don't expect a Raspberry Pi to work satisfactory as a router that was designed specifically to do routing, particularly when you factor the limitations of the lack of open source drivers. Depending on what you need, it might do exactly what you want and it might not. And if there happens to be a bug that can possibly be fixed then don't expect that to be a priority because it's not an attractive target (not that I am involved in the development, but that's only my guess).
As for the channels, I will refrain from talking more. But maybe if you happen to get them working, see if they will give you any better results. Or maybe you can compare 1 and 6 with any of 2~5, then you could let us know.
So, I tried something new: I used the OpenWrt 19.07 snapshot image from 20-07-2019 and channel 7 works now. Although when I switched to channel 8, I got problems again. Although it wouldn't immediately freeze; after a while it would though. I did notice a new error: [ 246.647553] ieee80211 phy0: brcmf_cfg80211_get_tx_power: error (-110) instead of the ieee80211 phy0: brcmf_cfg80211_get_channel: chanspec failed (-110). I still get both and maybe got them before too. I don't know anymore. I also get some of these: [ 62.151083] ieee80211 phy0: brcmf_cfg80211_del_station: SCB_DEAUTHENTICATE_FOR_REASON failed -110.
Broadcom wireless and open-wrt is not well supported due to the closed source wireless driver, so don't be surprised if it never gets fixed.
Also the people who have studied wireless and think channels other than 1, 6 and 11 on 2.4GHz work well in a crowded wireless environment either miss interpreted what they were taught or failed in their studies. To get a good idea of what channel to use you need to scan your building to see what channels are being used around you, and not use the strongest signal of the 3 of those.
@SlotTech Yeah I know there aren't open source drivers for it and expecting support from companies is out of the question. For the second part: did you by chance study it?