Your main problem here will be attempting this from a container. For using a wireless device from within a container, you need to pass through complete control over the raw device to the VM, which probably isn't possible with lxd.
With kvm and for PCI/ PCIe devices you could accomplish this by using the IOMMU (vt-d) to allow this, the situation for USB would be more difficult already (yes, usbhost exists and works for many easier USB devices, but WLAN cards are extremely timing sensitive, making passing them through to a VM a very fragile endeavour).
While I'm not very familiar with lxd (but having used lxc in the past), I don't really think this is possible. If it were possible, you may be able to find documentation for this under the keywords of how to pass through a (PCIe) graphics card to a VM (to play windows 3d games in a VM) - but I don't think is a supported feature of lxd.
Okay, so my struggle here is knowing how to work in the OpenWRT environment.
I have the LXD/Container skills to handle the hardware pass-through part and regularly pass any number of pci & usb devices into containers both physical nic(s), wifi cards, and other devices which are fully supported in the design of LXD. In fact, I've used ClearOS, another firewall/gateway distro before, using the wifi card as WAN. However it is much bigger in terms of disk and ram foot print compared to OpenWRT and this is my last hurdle to being able to run feature parity on OpenWRT
I've actually run a number of fairly exotic labs on this same hardware including other configurations of hostapd+ipsec builds broadcasting various ssid's from the wifi radio passed through into both other LXD Ubuntu/RHEL LXD Containers as well as Ubuntu/RHEL QEMU guests.
My biggest hitch here is knowing how the OpenWRT parts fit together internally to troubleshoot effectively. Do I need to target specific kmod(s)? Do I need to write a config for the wifi card? What are those parts? various UCI keys documented do not show up in my OpenWRT but others relating to wireless do and I havent found documentation for them, etc.
For clarity, my use case for the OpenWRT lxd containers actually spans a few scenarios but most immediately relates to this build (diagrams included) that I'm polishing as a CompSCI Cloud Ops Lab Environment which we are writing curriculum around.
LXD is containers not a VM, so it should absolutely be possible to move the wifi device into the namespace of the LXD container if you have a wifi device in the first place
@KathrynMorgan do you have a wifi device in the container? I'm not sure but I suspect that LuCI won't put up the wireless menu if there are no wireless devices, that's all.
Also consider the issue that the host system kernel needs to support all the functions that OpenWrt expects, because you won't be installing kmods from the container, since it's just a namespace not a VM.
In contrast to most desktop/server builds, OpenWrt doesn't include every driver known in x86 builds. You may need to add the drivers required, ath9k or ath10, either the "standard" or the -ct variants, or whichever is/are appropriate for the device(s).
I've confirmed I can scan available networks from the OpenWRT CLI and it does pickup all the expected information from both of my local SSID's that are broadcasting. This makes me wonder, if I can scan networks how could there be any drivers etc missing?
As far as modules and drivers. I'll hunt down the driver required and install it / make sure it's working.
With modules, I may actually need to ensure the container has access to the kernel module in the host, but thinking out loud that is already solved because I'm currently troubleshooting the issue with an unconfined/privileged container.
Sounds like you are set at the kernel level. What you want is the appropriate Luci function, which might be not detected, you might need to plop some blank wireless network into /etc/config/wireless in order for Luci to decide to show it.