I've found out that I'm experiencing this problem regardless of whether
the WiFi network was present or not when I booted - which is different
from what I've initially reported in my 1st message.
I've created an issue report on systemd's issue tracker, I hope to get
more support there - https://github.com/systemd/systemd/issues/9011
On Wed, May 16, 2018 at 01:25:34PM -0400, Bruce A. Johnson wrote:
> I didn't see your in-line comments at first. I'm not part of the systemd
> development team (I'm just a "consumer", trying to give back), so I
> don't feel comfortable advising you to open a ticket, but I would at
> this point if I were you. I'll add a few more comments in-line below.
> Good luck!
> Bruce A. Johnson
> Herndon, Virginia
> On 2018-05-16 12:34, Doron Behar wrote:
> > Currently I'm not residing at home were I use both interfaces to connect
> > to the same network, so I can't test this setup right now. In the
> > following experiments results following your suggestions, I didn't
> > connect any Ethernet cable.
> >> Mantas seems to be correct that I was giving you a bum steer about
> >> putting the DHCP=Yes into 25-wireless.network. I haven't used bonding
> >> before, either. So please consider advice from someone who actually
> >> knows what he/she's doing in preference to anything I suggest.
> >> Have a look at how systemd obtains the IP address on the [presumably
> >> working] wired connection.
> >> # journalctl -b | grep DHCP
> >> May 16 15:32:47 rl-000db948364a systemd-networkd: en01: DHCPv4 address 192.168.3.200/24 via 192.168.3.1
> > When I connect to the WiFi network only after boot, the command you used
> > above doesn't produce any output.
> If there is nothing from systemd-networkd about the IP address
> assignment and you having a working IP environment, it sounds like
> you're getting the IP address outside the systemd framework. That would
> probably preclude it from working with the active-backup configuration
> under systemd. I'm not sure whether wpa-supplicant does anything about
> getting an IP address, not having been there yet myself.
> >> My Ethernet interface is called /en01/. I would expect your log to say
> >> it's /bond0/. Given that wireless interfaces look a lot like Ethernet
> >> interfaces, I don't see that you've done anything wrong, and maybe if
> >> you run dhcpd manually on bond0 for diagnostic purposes, you'll see a
> >> better result in your test. The other thing would be to ping the default
> >> gateway (192.168.43.1 in your log), in case ICMP to the outside world is
> >> blocked. (The router might also block ICMP pings, though. It depends on
> >> the paranoia level of the network administrator.) If you've just brought
> >> up dhcpd, it's still running, and the IP layer is down already, that
> >> suggests to me that systemd-networkd has gotten in the way.
> > Well first of all, running `dhcpcd bond0` when I connect to the WiFi network only after
> > boot gives me this:
> > dhcp6_listen: Address already in use
> > DUID 00:01:00:01:22:58:f0:ec:34:13:e8:35:48:e6
> > bond0: IAID c4:ca:ef:aa
> > bond0: soliciting an IPv6 router
> > bond0: soliciting a DHCP lease
> > bond0: no IPv6 Routers available
> > And it's stuck there for a really long time..
> > As for `ping`ing `192.168.43.1`, I get this output:
> > connect: Network is unreachable
> > My network infrastructure at the moment is a WiFi hotspot of my Android
> The gateway address would depend on the wireless network you're using,
> so if you were working from home WiFi before and are now working from a
> WiFi hotspot, there are reasonable odds the gateway address would be
> different. To find your gateway address without reading the log output
> from dhcpd, run /ip route/ and pick up the address on the default line:
> $ ip route
> default via 10.100.1.1 dev en01 proto static metric 100
> 10.100.1.0/24 dev en01 proto kernel scope link src 10.100.1.64 metric 100
> In this example, the default gateway is 10.100.1.1, so if I were
> checking basic IP connectivity, I'd ping that address. (Although,
> honestly, if you have a default route, your IP is working and you're
> good to go.)
> > device.
> >> With wired interfaces, I swap the cable around all the time and
> >> systemd-networkd properly picks up the new IP configuration from DHCP.
> >> Maybe try a setup without the bond interface and see whether you can get
> >> IP working over wireless. I would expect systemd-networkd to gracefully
> >> handle DHCP configuration when you go out of range of the transmitter
> >> and return, or if you move to another SSID that's set up in
> >> wpa-supplicant. If that works, it suggests an issue with interface bonding.
> > As for moving away and returning to the range of a WiFi networks, it
> > should be noted that it works great without having a bonding
> > configuration - when using just a dumb `wireless.network` with:
> > [Match]
> > Name=wlp2s0
> > [Network]
> > DHCP=yes
> >> Another thing you might do is set up .network files for the interfaces
> >> that include a route metric of 0 for the wired (preferred) interface and
> >> 1 for the wireless:
> >> [Match]
> >> Name=en02
> >> [Network]
> >> Description=WAN connection on en02
> >> DHCP=yes
> >> [DHCP]
> >> RouteMetric=1
> > Adding the entry `RouteMetric=1` for the `[DHCP]` section in my
> > `bonding.network` doesn't help at all.
> I should have specified you'd need two separate files and no bond
> interfaces. In my case, I've got 80-en01.network and 80-en02.network,
> and the above is the content of the 80-en02.network file. The
> 80-en01.network file has /Name=en01/ and /RouteMetric=0/. Both (wired)
> interfaces are up simultaneously, and I want all traffic to normally go
> through en01. I have host routes with a route metric of 0 for the
> addresses I want to reach on en02. If either interface loses
> connectivity, all traffic goes through the remaining interface.
> > Should I open an issue on systemd's issues tracker?
> systemd-devel mailing list