Hello there! any help is appreciated.
I believe this to be a bug. Can I file bugs here? will they be read?
My setup, functional until switch to leap 16.0 beta: bridge br0 controls eth0 and wlan0 ( wlan0 is operated by hostapd); all managed by wicked and brctl. Wlan clients connect through wlan0 and are forwarded in br0 via eth0 to the router, which hands out DHCP addresses and dns and serves all the internet traffic. (my router is in the basement and its wifi doesn’t reach everywhere).
I also have vnet0 and vnet1 from virtual machines running in br0. The bridge is indispensable!
Problems in 16.0:
- Now with Cockpit, wicked is largely ignored, and Cockpit forces networkmanager to run the network devices; network devices run by wicked are not recognised by Cockpit. I don’t understand why: wicked seems still under development and should be recognised as network-managing service.
- Running Networkmanager, I have the problem that any traffic coming from wlan0 or vnet* is blocked completely by firewalld. I have checked firewall-config extensively, and all interfaces appear there (including eth0 br0 wlan0) in the right zone (dmz, which is my standard zone), all usual rules and services still apply, including imcp/ping, which worked before ( I have run this setup for years). But all traffic, including dhcp and dns, everything is blocked coming from wlan0 (wifi clients), as well as vnet0 and vnet1. WLAN Clients can connect to hostapd, but they don’t get an IP address from the router, and therefore connection fails eventually. virtual machines vnet0 and vnet1 also fail to connect.
However, all traffic issued directly on the “server” running the hostapd and br0 (for example pings from the console), works flawlessly, dns is served, and ping to internet works. Ifconfig shows all interfaces “up”. Nothing seems wrong there.
As soon as I stop firewalld, wlan client can connect, all is well. When I start firewalld again, the services stop as described above.
Standard forward rule in is “standard to [ip router] via br0” I think that must be correct. is this a bug?
note: ifconfig is an alias for “ip a”, I just have kept the name because I am used to it. It works and is not connected to the problem
Who can help me?
Cellocommander
Check that NetworkManager assigns the correct zone to interfaces.
Thanks for your reply! Well, network manager can be controlled either by Cockpit, or by nm-applet. Both do not recognise wlan0 as part of br0, and don’t let me add them (although brctl says wlan0 is part of the bridge br0!)
→ Cockpit can add new interfaces to br0, but when i try to add the wlan device (it is shown in the list) it fails with a strange notification which goes something like “802-11-wireless config is necessary for 802-11-wireless” - translated from German. So adding the device fails here, even if listed.
→ nm-applet doesn’t give me an option to add a wifi device (only lan, bonds, vlan ,…), so i cannot add it here.
In Cockpit there is an extra firewall config option, which correctly lists all interfaces (br0 wlan0 vnet* eth0) as part of my zone dmz!
I do not understand how your reply answers my question. Firewall zone is the property of the NetworkManager connection profile and NM always assigns the firewall zone to the interface where this connection profile is activated.
Ok, but where do i see/check that? I think I can see that either in Cockpit or in nm-applet. Is there another way? Please give me a tip how to check that config and see if it is right, or change it. Thanks!
Have you checked that when firewall is active all interfaces are in the correct zone? Not what some management frontend shows you - what actually happens.
Sorry, I don’t know how to do that,. Please tell me.
firewall-cmd --get-active-zones
firewall-cmd --get-active-zones
dmz (default)
interfaces: br0 wlan0 eth0 vnet0 vnet1
I also just checked firewall-config again, and it said something interesting: Under “Connections” it lists vnet0 vnet1 br0 and “br0 eth0”(bound eth0 to br0), all correctly in zone dmz; and below, under “Interfaces” wlan0 is listed, but not the others, but also in the correct zone dmz. Is the difference between “Interface” and “Connection” a clue toward the problem ?
And? Is it correct or not?
Well, they are all in the correct zone if you mean that. If a setting were wrong, i would have changed it long ago. But the problem remains: wlan clients on wlan0 don’t get any internet or DHCP.
To the extent I could understand your description you have the single bridge br0 and everything is connected to it. Which means for the firewall there is only one interface - br0. Any traffic between wlan0 and eth0 happens below firewall level (at least, below the usual L3 firewall level).
How have you determined it? Start packet capture on both wlan0 and eth0, compare what happens during DHCP transaction.
Anyway, if stopping firewall makes it work, the full output of
nft list ruleset
iptables -L -n -v
iptables -L -n -v t nat
could be useful. Upload to the https://paste.opensuse.org/
https://paste.opensuse.org/pastes/3d5ee6964e01
(vnet 0 / 1 have changed to vnet4/5, but never mind, the problem persists all the same)
How do I do packet capture? Is it possible also in android client?
I have determined that simply because it doesn’t work and the clients disconnect when failing to get an IP. “systemctl status hostapd” and “systemctl status firewalld” and the mentioned tools ifconfig, brctl, Cockpit and nm-applet tell the rest of my story…
I do not see how it can affect bridge. Show
ip l
ip a
tcpdump, wireshark, tshark, dumpcap. If you just want to capture packets without seeing them
dumpcap -i wlan0 -w /tmp/wlan0.pcap
dumpcap -i eth0 -w /tmp/eth0.pcap
Start your wireless client so it generates some DHCP transactions and upload two files to the same location. It is better to not have any other network activity concurrently to avoid unrelated packets.
The goal is to compare what enters your host with what leaves it. Communication is bidirectional and packets may be lost (or blocked) in any direction.
https://paste.opensuse.org/pastes/af9cad32ab9b
my editors refuse to open that file. this is wlan0
it says:
dumpcap -i wlan0 -w /tmp/wlan0.pcap
Capturing on ‘wlan0’
File: /tmp/wlan0.pcap
Packets captured: 1377
Packets received/dropped on interface ‘wlan0’: 1377/0 (pcap:0/dumpcap:0/flushed:0/ps_ifdrop:0) (100.0%)
There is no DHCP traffic on wlan0. There are two DHCP packets from the host with MAC e2:6b:df:0a:e5:b4 - I have no idea whether they are related. But it is strange that those packets are not visible on wlan0 as they should (they are sent to the broadcast).
At the same time there is other traffic which is apparently originated on eth0, like Spanning Tree Protocol from the MAC 00:01:c0:12:09:38 or HomePlug AV traffic from the host d4:24:dd:1e:ab:ad. Maybe you can identify them.