I've switched to kmod-brcm-wl+wl+nas+wlc on a Linksys e3000 as per this thread and it mostly works, however it doesn't boot cleanly. Upon boot, the SSIDs are missing from the "Wireless Overview" page and neither are visible to wireless clients. If I click "Edit" on one of the wireless interfaces, and then simply "Save & Apply", the SSIDs come back for both interfaces and everything works.
I assume that when I do these steps, LuCI is issuing some shell commands to
wl or similar.
Is there some debug facility where I could see what LuCI is doing under the hood while I do these steps? If I knew this, I could put them into
/etc/rc.local as a kludge.
Any other pointers as to how LuCI is interacting with the driver? Is it making use of
I think "Wireless Overview” uses info from
iwinfo. You can start debugging by:
- Checking a list of wireless interfaces (e.g.
- Trying to query them using
iwinfo wlan0 info)
Thanks @rmilecki. That got me a bit further.
iwinfo wl0 info shows
ESSID: unknown, so it makes sense that the "Wireless Overview" screen is missing the ESSID. At this point if I run
iwconfig wl0 essid "MyNetwork" then it appears correctly on the "Wireless Overview" page AND clients can see the network. They can attempt to connect (and they show up briefly under "Associated Stations" in LuCI with a '?' under the host column, then disappear a few seconds later.
iwconfig are good leads, but seem to address the symptom and not the cause. What I really need to know is what exactly happens when you click "Save & Apply" on the
/cgi-bin/luci/admin/network/wireless/wl0.network1 page. I assume it updates the UCI config, and then.... reinitializes the network stack based on the new config? The latter is what I'm looking for.
I ended up instrumenting
/lib/wifi/broadcom.sh to see what was sourcing/calling it. That led me to
Turns out that simply calling
/sbin/wifi reload has the same effect as clicking "Save & Apply" on a wireless interface page in LuCI. I've put this command in my
/etc/rc.local and everything comes up clean.
It seems the
broadcom.sh setups something incorrectly (maybe in a wrong order?) and it needs another call to get
wl driver setup properly. You may log all
wlc calls done by
broadcom.sh and then them to repeat them one by one, seeing which one will fix the initial (incorrect) setup for you. Then you can try to fix
broadcom.sh to work properly on the first