[systemd-devel] systemd networking : problems with bridges

[Charles Devereaux]

Hello

I'm trying to configure systemd networking for a bridge, using v217-stable
from anongit.freedesktop.org/systemd/systemd-stable

I mostly have 3 problems:

1- 3 - I do not understand how to properly use systemd-networkd-wait-online

I have one service (establishing the uplink) with:
After=network-online.target

Yet it its status I  see it failed because it could not resolve the remote
host.

The services are properly enabled:

$ find . |grep network
./multi-user.target.wants/systemd-networkd.service
./systemd-networkd-wait-online.service
./network-online.target.wants
./network-online.target.wants/systemd-networkd-wait-online.service

So I tried to check systemd-networkd-wait-online :

$ systemctl status systemd-networkd-wait-online
● systemd-networkd-wait-online.service - Wait for Network to be Configured
   Loaded: loaded
(/etc/systemd/system/systemd-networkd-wait-online.service; enabled)
   Active: inactive (dead)
     Docs: man:systemd-networkd-wait-online.service(8)

If I try to start it manually, it hangs, even if I specify
--interface=wlan0 in its service.

I think the reason might be br0, that is seen as "not ready" because of the
uplink issue:

$ networkctl status 3
● 3: br0
   Link File: n/a
Network File: /etc/systemd/network/bridge.network
        Type: ether
       State: no-carrier (configuring)
(...)

If I manually start the uplink, networkctl is happy (State: routable
(configured) and systemd-networkd-wait-online works. So it's a catch 21:
uplink can't start because systemd-networkd-wait-online does not indicate
success because uplink can't start.

Is there an option I could use on bridge.network to indicate it shouldn't
be considered by systemd-network-wait-online (a bit like it ignores the
loopback interfaces)?

2- Updating the bridge configuration without requesting too many DHCP
addresses.

The bridge is properly brought up by systemd-networkd, but I do not see how
to take it down or how to change some options when say the .netdev file has
changed (ex: changed the mac address, new dhcp option, etc).

At the moment, I work around the problem with systemctl stop
systemd-networkd && systemctl start systemd-network but this cause some
dhcp weirdness on the other network interfaces using DHCP, with a new IP
being configured every time.

For exemple, after a few tries I currently have:

$ networkctl status
       State: routable
     Address: 192.168.2.44
              192.168.2.43
              192.168.2.42
              192.168.2.41
              192.168.2.40
              192.168.2.39
              192.168.2.38
(...)

I'm not sure why it's hogging the DHCP addresses since the corresponding
.network file is quite simple:

$ cat wireless.network
[Match]
Name=w*
Virtualization=no

[Network]
DHCP=both

[DHCP]
UseHostname=false

Does networkctl supports turning interfaces up/down and restarting them? Is
it a planned feature?

If not, I would suggest adding a least a restart feature,  so that the
interface can be reconfigured in isolation without affecting the DHCP IPs
of the other interfaces. For bridges, this restart feature could do the
ifconfig down and brctl delbr.

It might be good to do the same when systemd-network is restarted, so that
the new options (ex: cloned mac addres) are applied.

3- Acquiring DHCP leases *AND* serving DHCP on br0

br0 is configured as:
$ cat bridge.network
[Match]
Name=br0

[Network]
DHCP=both
Address=192.168.3.224/28
DHCPServer=yes

[DHCP]
UseHostname=false
UseDNS=false
RequestBroadcast=yes

ap0 is a local access point, bridged to an uplink on br0

The idea is to have 192.168.3.224 configured and serve DHCP address in the
/28 (16 addresses) during the uplink confirmation. When the uplink is up,
it  will provide better addresses and configuration to the clients. With
the configuration above, the DHCP address offered by the uplink is properly
seen by networkctl, and configured. It respond to pings.

The DHCP range is properly used to give IP addresses like 192.168.3.225 to
clients.

I tested with a OSX Yosemite client : when the uplink is established, the
clients get the new lease, yet they still seem to try and use the old one,
as I can see packets trying to use the local link instead of the uplink :
ip6tables forward denied: IN=br0 OUT=wlan0 PHYSIN=ap0 MAC=xxxxx
SRC=192.168.3.225 DST=local-endpoint

With another OSX Yosemite, only the original lease is acquired (weird)

Would it be possible to make the DHCPServer release the ip and stop as soon
as the uplink is up? (which relates to the previous question of being able
to apply changes to a single interface without affecting the others)


Thanks
Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150103/2cc92f79/attachment-0001.html>