How to WIFI Radio as WAN on x86 OpenWrt running in LXD container

So basically you are stuck on the third image of the guide?
Can you paste here an image of what do you see on the screen that troubles you?

I cant even find my way to the 2nd picture of the guide. That is not a valid URI for me.

If I try manually entering that full url (https://blablabla/network/wireless_join I get a 404

You should go to Network - Wireless - Scan. Is it not there?
What device and Openwrt version do you have?

Okay, so I am missing that menu path. I do not have 'wireless' under 'Network' menu.

This is kind of the fun part. So far this OpenWRT image has not been missing anything that I noticed in a number of applications, but I'm running a home brewed OpenWRT in LXD container image.....

If I can identify what luci packages & dependencies are missing I can modify the build process at least to include the missing bits.

Thoughts?

and thank you!!

Oh and version:
OpenWrt 18.06.1 r7258-5eb055306f / LuCI openwrt-18.06 branch (git-18.329.26825-5e87083)

VMs and containers are not my cup o' tea, so I'll let someone else more knowledgable help you with that. Best of luck :slight_smile:

Well thank you, at least I know where the piece is missing in the webui.

Now to track down the opkg bits to solve it.

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.

1 Like

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.

Thanks! I tried touching a blank /etc/config/wireless and that didnt work on it's own. That file did not exist previously.

I'm tinkering with it's contents now. We'll see what we come up with.

It would be really neat to see the default contents of /etc/config/wireless on a clean openwrt before any configuration.

Is a useful message from the forum. Install "wpad" package because by default it's not installed on x86!

2 Likes

@dlakelan

Consider it solved. Simple enough I was just overwhelmed with the material and didnt find that one detail.

Thank you! This gives me a lot more flexibility with architecture/layout of the lab(s)

1 Like

You can click the check mark below my post with the answer, and it will mark the thread as solved. Glad you got it working.

already done :slight_smile:

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.