[systemd-devel] Can't connect to WiFi when the wired and the wireless interfaces are bonded

[Bruce A. Johnson]

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?
>