chain reaction of failures because I cannot br0 to wlan0...

camosoul · 2021-03-19 06:00:26

...all I wanted to do was set up a br0 and have KVM guests use it. But, that was too much to ask...

https://wiki.archlinux.org/index.php/Ne … h_iproute2

sudo ip link add name br0 type bridge
sudo ip link set br0 up

The network adapter to which I wish to bond it, is already up and working.

So, I do a this:

sudo ip link set wlan0 master br0

But, it flagrantly refuses to do the one job it was created to do:

Error: Device does not allow enslaving to a bridge.

That's your job! It is your one and only purpose! Does not allow? Excuse me? I didn't realize how belligerent computers could be...

virt-manager uses firewalld to create virtual networks, and it's a real problem. It has no respect for existing ufw/iptables rules and absolutely trashes my network setup(s) every time it runs. It's unusable.

I have to get this br0 running.

Last edited by camosoul (2021-03-19 06:20:49)

d_fajardo · 2021-03-19 07:17:39

Your issue might have a bearing on the interface being wireless.
In the section Tips and Tricks of the page you quoted, there's an entry there regarding wireless interface that might be the answer.

camosoul · 2021-03-19 07:24:00

d_fajardo wrote:

Your issue might have a bearing on the interface being wireless.
In the section Tips and Tricks of the page you quoted, there's an entry there regarding wireless interface that might be the answer.

https://wiki.archlinux.org/index.php/Ne … n_a_bridge

camosoul wrote:

The network adapter to which I wish to bond it, is already up and working.

d_fajardo · 2021-03-19 07:33:55

I'm not saying your wireless is not up and running. Just wanted to check if you had a look at hostapd.

camosoul · 2021-03-19 11:31:02

d_fajardo wrote:

I'm not saying your wireless is not up and running. Just wanted to check if you had a look at hostapd.

I don't see how disconnecting from the router and turning my WiFi adapter into an access point to nowhere would be helpful.

Lone_Wolf · 2021-03-19 14:11:28

camosoul wrote:

I don't see how disconnecting from the router and turning my WiFi adapter into an access point to nowhere would be helpful.

Have you looked at https://wiki.archlinux.org/index.php/So … figuration ?

seth · 2021-03-19 15:05:13

Don't bridge, NAT.

https://unix.stackexchange.com/question … -interface

hostapd will allow you to run 4addr w/o issues, but your local AP (wifi router?) maybe (likely) won't.
So if the latter is mandatory, don't bridge, NAT.

camosoul · 2021-03-19 21:03:53

seth wrote:

Don't bridge, NAT.
https://unix.stackexchange.com/question … -interface
hostapd will allow you to run 4addr w/o issues, but your local AP (wifi router?) maybe (likely) won't.
So if the latter is mandatory, don't bridge, NAT.

If virt-manager/firewalld weren't trashing up my other network configs, maybe.As it is, the mess it keeps making is intolerable.

But, more importantly, I don't want a virtual network in the first place.

I want my VMs to appear on the same network as the host, and interact with the network exactly as if they were real machines plugged into the ethernet.

With VirtualBox I just click the "bridged" checkbox and everything works...

I'm trying to "do this correctly" but this is a nightmare. Documentation is incorrect.

I desperately need to shut off and not use the virtual network that virt-manager wants to create. It's a disaster. I don't even want to use virt-manager.

I only went with virt-manager because there's zero documentation or explanation on using kvm/qemu headless guests, on a headless host.

I'm forced into all of this against my will, and it's a huge mess... I'd like to quit using virt-manager, too...

I just want this VM to autostart on the headless server, in headless mode, when the machine boots up, and appear as if it's on the host's network... I don't want this convoluted mess, gui, manually running things...

Last edited by camosoul (2021-03-19 21:21:26)

seth · 2021-03-19 21:48:21

Did you bother to read the link I posted?
(…answer implied…)

Also there is zero documentation, but it's also incorrect…?
This one?
https://wiki.archlinux.org/index.php/QEMU#Networking
Or any of the pages that were linke in this thread?

Also

With VirtualBox I just click the "bridged" checkbox and everything works...

Yeah, guess what:

https://www.virtualbox.org/manual/ch06.html#network_bridged wrote:

Note
Bridging to a wireless interface is done differently from bridging to a wired interface, because most wireless adapters do not support promiscuous mode. All traffic has to use the MAC address of the host's wireless adapter, and therefore Oracle VM VirtualBox needs to replace the source MAC address in the Ethernet header of an outgoing packet to make sure the reply will be sent to the host interface. When Oracle VM VirtualBox sees an incoming packet with a destination IP address that belongs to one of the virtual machine adapters it replaces the destination MAC address in the Ethernet header with the VM adapter's MAC address and passes it on. Oracle VM VirtualBox examines ARP and DHCP packets in order to learn the IP addresses of virtual machines.

camosoul · 2021-03-19 22:03:54

Lone_Wolf wrote:

camosoul wrote:
I don't see how disconnecting from the router and turning my WiFi adapter into an access point to nowhere would be helpful.
Have you looked at https://wiki.archlinux.org/index.php/So … figuration ?

Yes. I have read this multiple times. I do not need to convert the host machine into a WiFi Access Point. I have no idea how that would be useful. Further, it seems destructive to what I'm trying to accomplish. The host machine has only one connection to a REAL router. If I convert wlan0 into an AP, there will no longer be any connection to the network.

Just for entertainment:

$ iw list
...
Supported interface modes:
		 * IBSS
		 * managed

According to that document, I couldn't convert it into an access point even if I wanted to. It appears my adapter doesn't have that ability.

...this is going very far off topic.

The objective is to make Guest VMs operate in a useful way. If they are isolated behind the virtual network that virt-manager makes, then I cannot use them (not to mention, virt-manager destroys all other existing network configs).

I just want it to be normal and simple and work correctly. Bridging seemed to be the best way to do that, but bridging is broken, so...

I don't even want to use virt-manager, but everything I read insists on using it... So, I had no choice but to give up on doing it right and go in this huge circle of nonsense I don't want instead... Adding a huge pile of additional problems that I'm now trying to fix...

All I wanted to do was run a headless VM on a headless server, but now I'm stuck down this ridiculous rabbit hole and nothing works...

Last edited by camosoul (2021-03-19 22:06:22)

progandy · 2021-03-19 22:05:47

Something like this should work. Set up a so-called routed network for kvm.

https://jamielinux.com/docs/libvirt-net … twork.html
https://jamielinux.com/docs/libvirt-net … twork.html

Last edited by progandy (2021-03-19 22:08:42)

camosoul · 2021-03-19 22:35:56

seth wrote:

Did you bother to read the link I posted?
(…answer implied…)

Yes. Multiple times. It is unrelated. Further, it appears destructive to the goal of a working network connection. I followed it to conclusion anyway, and discovered I couldn't even do this completely unrelated thing even if I wanted to.

seth wrote:

Also there is zero documentation, but it's also incorrect…?
This one?
https://wiki.archlinux.org/index.php/QEMU#Networking
Or any of the pages that were linke[d] in this thread?

Yes, and everything I see is either unrelated or unhelpful.

seth wrote:

Also
With VirtualBox I just click the "bridged" checkbox and everything works...
Yeah, guess what:
https://www.virtualbox.org/manual/ch06.html#network_bridged wrote:
Note
Bridging to a wireless interface is done differently from bridging to a wired interface, because most wireless adapters do not support promiscuous mode. All traffic has to use the MAC address of the host's wireless adapter, and therefore Oracle VM VirtualBox needs to replace the source MAC address in the Ethernet header of an outgoing packet to make sure the reply will be sent to the host interface. When Oracle VM VirtualBox sees an incoming packet with a destination IP address that belongs to one of the virtual machine adapters it replaces the destination MAC address in the Ethernet header with the VM adapter's MAC address and passes it on. Oracle VM VirtualBox examines ARP and DHCP packets in order to learn the IP addresses of virtual machines.

Bridging to a wireless interface is done differently from bridging to a wired interface

because most wireless adapters do not support promiscuous mode

And ethernet adapters do?

You'd think, after all this time, a solution to these defects would have been achieved...

As you so astutely note, Oracle fixed it.

It seems like you're telling me, in an indirect, don't want to say it out loud, drop hints, asian save-face kind of way; that KVM/QEMU can't do the job. KVM/QEMU does seem a lot faster and more responsive with lower overhead than VirtualBox, for obvious reasons. But, if it can't do the job, it can't do the job. I don't have the time or patience to keep beating my head against the wall.

This is not a toy. It needs to work, properly, and right now. I've already wasted months fighting with it. If KVM/QEMU can't do this, just come out and say it instead of playing abusive troll mind games.

I've gone way too far down several rabbit holes that not only don't solve the problem or accomplish the original goal, but generate even more problems while pushing me further my goal. I find it baffling that such a simple task cannot be done.

I'm giving up on this path of questioning and starting over.

Perhaps KVM/QEMU simply isn't up to the task of network comms. Or, at least virt-manager, which I don't even want, can't get it done... I'm not sure which at this point, and I'm sick of doing this on a computer it shouldn't even be on in the first place.

camosoul · 2021-03-19 23:07:20

progandy wrote:

Something like this should work. Set up a so-called routed network for kvm.
https://jamielinux.com/docs/libvirt-net … twork.html
https://jamielinux.com/docs/libvirt-net … twork.html

Thank you, sir. You are a gentleman and a scholar.

Now, to get back to work on headless VirtualBox...

A routed network is usually only used when a Bridged network is unavailable, either due to hosting provider restrictions or because the libvirt server is connected wirelessly to the LAN.

Unfortunately, libvirt’s built-in routed network automatically inserts iptables rules whether you want them or not, in an order that is difficult to control.

Yeah, it sucks.

In this example:
The server has an Ethernet device called eth0.

...aaannd an instant bad example. If I had eth0, I wouldn't need this. I could easily do a br0... Which this very same document stated in the first paragraph. smh...

This very same document, in it's very first sentence, states that this sucks and you would only do this because br0 isn't an option and you were forced to. It explains that this sucks and you really don't want to do it. Then immediately proceeds to use an example where br0 is possible and you wouldn't want to do this... This is precisely why so much documentation is garbage... No logic. No common sense. If you're going to make an example, make it a non-insane example... An example which defies it's own explanation is confusing, and casts doubt on the writer's trustworthiness... A rational adult is forced to asked "Is this guy insane? Does he know what he's talking about? He contradicted himself in the first page... Can I trust anything I'm about to read? Is my computer going to blow up if I try this?"

That's what I needed to see.

It seems virt-manager/libvirt/KVM/QEMU has no civilized, rational solution to a problem that should have been solved a decade ago, but nobody wants to come out and say it. Therefore generating hostility and confusion... I get it. It's about purism. And it's got merit to it. KVM is meant to be native, without any funny business. Under many circumstances, I might be the guy in support of it. Except for edge cases, you just set up a br0 and you're done...

While I find the packet sniffing and replacing that VirtualBox does to be a bit uncomfortable from a security standpoint, it's waayyy better than the huge patchwork mess of non-solutions needed to make KVM work. KVM may be native, but it is a non-solution. Running ethernet cables all over is not going to happen.

This VM needs to rapidly re-deploy on simple, even unknown infrastructure without a huge amount of messing around. VM establishes reverse ssh tunnel to vultr (vps being used as a router/static IP) when it boots up, everything "just works" in under a minute. Resilient. Portable. Wired. WiFi. Pretty much any machine can be a host. A proper server. An old laptop with a cracked screen and non-functional touchpad... maybe a Raspberry Pi. Who knows. It's gotta go, and go fast, without a bunch of messing around.

Seems like there could be some kind of patch or add-on that would do this for KVM. It would be politically unwelcome, but that's why the AUR exists... Which is also where virtualbox-headless can be found... Maybe it does exist, and I don't know what it's called.

Last edited by camosoul (2021-03-19 23:38:28)

seth · 2021-03-20 08:57:06

Oracle didn't fix anything. Virtualbox essentially NATs under the hood when you "bridge" on wireless devices for the reasons that I pointed out in several links and quotes and the wiki and other users.
Bridging on wireless devices is fragile and often/typically not possible to begin with because of the wifi protocol - something you seem to be unwilling or simply incapable to understand.

BlackMastermind · 2021-03-20 13:24:32

Wow, talk about great timing!

Coincidentally I embarked on the same journey as camosoul this morning, wanting to convert some VMs from a NAT-ed config to a bridged config, which is easy enough to do in VirtualBox, and ran into the same frustrations and rabbit holes of incomplete or inconsistent documentation for something you'd expect to be a common use case.

I'm glad I stumbled upon this thread and that finally someone came out and spelled it out clearly: you can't bridge to a wireless device using KVM.

A statement to that effect should probably at the top of any documentation describing bridging with KVM, to prevent others from going on this fool's errand. Also this thread could have done with a lot less tap dancing around the hot potato.

seth · 2021-03-20 13:32:28

BlackMastermind wrote:

you can't bridge to a wireless device

ftfy, this has nothing to do w/ KVM. A wifi bridge is a PITA and often not possible.
Virtualbox does NOT use a bridge for wireless devices, regardless of what the GUI checkbox label says.
They just shadow the details because their users use a GUI to configure the system.

Also tap dancing? You mean like

seth wrote:

Don't bridge, NAT.
https://unix.stackexchange.com/question … -interface
hostapd will allow you to run 4addr w/o issues, but your local AP (wifi router?) maybe (likely) won't.
So if the latter is mandatory, don't bridge, NAT.

spooky_dove · 2023-02-20 14:16:44

I faced similar problem with QEMU/wlan bridging.
This article helped to configure it https://wiki.gentoo.org/wiki/QEMU/Bridg … fi_Routing in particular the part called The fun of routing to Wifi
Hope it helps someone.

Lindsay · 2024-09-20 23:55:42

Did this ever get resolved? I'm seeing the same issue on a different distribution, and am thinking it may be a percolating up from a level 1 issue. The WiFi chip on the problem system here is Broadcom BCM2711 PCIe Bridge. WiFi implementation still has something of the USA Wild West about it.

seth · 2024-09-21 06:44:40

What issue?
Creating a bridge to a wifi device? You typically won't resolve that.

The gentoo article in #17 shows how somwehat work around that (depending on the ultimate goal) by bridging two VMs and forward their traffic to the hosts wifi using iptables/netfilter and ipv4.ip_forward
Every article or whatever you read that shows you how to bridge a VM to ethernet or two ethernet devices etc. is mostly useless unless you have a probably one-in-a-million wifi chips/drivers that supports bridging.

Arch Linux

#1 2021-03-19 06:00:26

chain reaction of failures because I cannot br0 to wlan0...

#2 2021-03-19 07:17:39

Re: chain reaction of failures because I cannot br0 to wlan0...

#3 2021-03-19 07:24:00

Re: chain reaction of failures because I cannot br0 to wlan0...

#4 2021-03-19 07:33:55

Re: chain reaction of failures because I cannot br0 to wlan0...

#5 2021-03-19 11:31:02

Re: chain reaction of failures because I cannot br0 to wlan0...

#6 2021-03-19 14:11:28

Re: chain reaction of failures because I cannot br0 to wlan0...

#7 2021-03-19 15:05:13

Re: chain reaction of failures because I cannot br0 to wlan0...

#8 2021-03-19 21:03:53

Re: chain reaction of failures because I cannot br0 to wlan0...

#9 2021-03-19 21:48:21

Re: chain reaction of failures because I cannot br0 to wlan0...

Note

#10 2021-03-19 22:03:54

Re: chain reaction of failures because I cannot br0 to wlan0...

#11 2021-03-19 22:05:47

Re: chain reaction of failures because I cannot br0 to wlan0...

#12 2021-03-19 22:35:56

Re: chain reaction of failures because I cannot br0 to wlan0...

Note

#13 2021-03-19 23:07:20

Re: chain reaction of failures because I cannot br0 to wlan0...

#14 2021-03-20 08:57:06

Re: chain reaction of failures because I cannot br0 to wlan0...

#15 2021-03-20 13:24:32

Re: chain reaction of failures because I cannot br0 to wlan0...

#16 2021-03-20 13:32:28

Re: chain reaction of failures because I cannot br0 to wlan0...

#17 2023-02-20 14:16:44

Re: chain reaction of failures because I cannot br0 to wlan0...

#18 2024-09-20 23:55:42

Re: chain reaction of failures because I cannot br0 to wlan0...

#19 2024-09-21 06:44:40

Re: chain reaction of failures because I cannot br0 to wlan0...

Board footer