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[382]: 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 systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
