Hello to everyone who is seeing this, and thanks in advance to anyone who provides some insight.
I'm trying to run OpenWRT in a linux container. My goal is to have a single RPi that would be used for a handful of possible projects running in separate containers.
My container seems to be just fine. I can access luci and make configuration changes from the host/outside the container, and I am letting the container have control over wlan0.
Inside the container (the OpenWRT image), if I run ifconfig wlan0 shows up just fine
wlan0 Link encap:Ethernet HWaddr E4:5F:01:3F:62:47
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
I can scan for other networks just fine.
I've ensured that I set the country code within Raspbian before passing wlan0 to the container.
I've configured OpenWRT with my appropriate country code (US, before doing this I was unable to scan for 5Ghz networks).
Based on this, it seems like the drivers exist/are installed correctly (unless I'm wrong here).
Running "wifi config" generates the config file in /etc/config/wireless, however it's empty and nothing I do seems to populate it automatically (unless that's not what it's supposed to do).
If I populate the config file manually, I'm able to access the "Network > Wireless" in luci, but it says that wlan0 is unavailable, and I haven't been able to get it working.
So where I'm stuck is how I can get OpenWRT to recognize my wireless device? Or is the issue ultimately that I'm trying to run it in a container?
I would recommend against this practice, for several reasons.
OpenWrt expects its own kernel, with the features (lots of patches) it relies on, the ability to load and unload kernel modules as needed and to rely upon the sysctl configuration it sets by default, in a containerized setting you rely on the host kernel to provide the necessary environment, this might happen to work, or fail somewhere between subtle issues or spectacular issues (including serious security ones). If you insist on virtualization, (virtio based) full system emulation (kvm and similar) would be a safer and less convoluted approach.
The container (or full system virtualization) orchestration needs to duplicate a considerable part of the network configuration (how to connect the VM interfaces to the outside), unless you really know what you're doing (in a battle-tested/ hardened enterprise environment), this is a considerable extra burden, needing lots of attention to keep everything safe and prevent leaking access to internal interfaces. You depend on host- and VM for security and to agree on the networking policies, to the extent of asking yourself why to even bother about the OpenWrt VM, if you already need to do over half of the policy- and security decisions on the host anyways.
The onboard wireless of the RPi4 (and previous generations) is just CR…P (in capital letters), 1x1, tiny PCB antenna, limited brcmfmac driver, no concurrent dual-band and performance not even achieving earliest draft-n ranges, a 20 buck wireless router can do better (even though I wouldn't buy those myself either).
Especially for gateway security, get a device dedicated exclusively to the routing tasks (installed directly on the bare iron), with the minimum attack surface exposed to the outside (OpenWrt is fine for this) - this makes security auditing and ongoing maintenance just so much easier. And most of all, get the right tool for the job - a RPi4 is the cheapest way to get a very fast router, but its fortune doesn't lie within its wireless features - look into offloading that aspect into hardware that can actually deliver (any cheap wireless router/ AP in dumb-AP configuration will run circles around your RPi).