On Tue, Jan 26, 2021 at 07:31:04PM +0000, Vallevand, Mark K wrote:
I'll try to explain. I have three interfaces. I'll call them eth0, eth1 and wlan0. Normally, we create a bridge, br0, and enslave eth0 and eth1. We assign an IP to br0 (DHCP) and it can access devices connected to eth0 and eth1. Those devices also can access each other, too. A DHCP server is upstream on eth0. Now, we want to use wlan0 instead of eth0. So, we create br0 and only enslave eth1. Br0 is set to DHCP. Wlan0 connects to a NAT/PAT access point with WPA2. It serves DHCP. Everything works as expected. It gets an address from the access point DHCP pool. Before sharing, we add a config file in /etc/NetworkManager/dnsmasq-shared.d/. There is only one setting in the file. "interface=br0" This forces NetworkManager's dnsmasq to only listen on br0. This prevents inference with other dnsmasq instances that we are running. We also assign an ipv4.addresses to br0 the br0 connection, so the DHCP pool range will be determined. We enable sharing on br0. There is some magic that happens here. I haven't looked at the code too much. When br0 is shared, what actually happens?
When sharing is enabled on br0, NM starts dnsmasq to serve DHCP and DNS requests on the interface. It also enables NAT for the traffic going out of the interface.
Anyway, NetworkManager seems to use wlan0 without any configuration by us.
NM only enables NAT for traffic originated from the br0 subnet. Then the kernel uses the routing table to determine where packets go.
Devices behind eth1 get addresses from the correct pool and can access devices on the other side of the access point.
That's a lot of explanation. Maybe we are thinking of this backwards. Should we share wlan0? Suggestions are welcome.
No, this sounds right.
We'd like to convince NetworkManager's dnsmasq to forward or relay or ignore DHCP requests so that they are handled by the DHCP server on the access point. Suggestions are welcome.
You would need to put the wifi interface and eth1 under the bridge, but as said previously wifi interfaces can't be used as client in a bridge.
Finally, we noticed that traffic originating at br0, say, ping -I br0 x.x.x.x, where x.x.x.x is on the other side of access point, does not work. Traffic the other way from br0 to devices behind eth1 will work.
Sorry, I don't know why. Beniamino
Attachment:
signature.asc
Description: PGP signature