[10:25] <ack> hi, I have a strange issue with network configuration on ubuntu core20 (on a raspberrypi). not sure if something is wrong with my conf or it could be a netplan issue. With wifi configured and eth0 through a bridge, if I disconnect the ethernet, the wifi also stops working
[10:25] <ack> when I reconnect the cable, both start working again
[10:27] <ack> this is my config: https://paste.ubuntu.com/p/2MJ3DSYyKr/
[10:31] <slyon> ack, hi! That should not be happening. Your config looks OK so far. Do you have any more logging output, e.g. from networkd (journalctl -u systemd-networkd)?
[10:37] <ack> slyon, I don't see anything strange in there, if I disconnect the cable and then reconnect it I only see the messages about link and dhcp, no error
[10:37] <ack> slyon, fwiw if I don't create the bridge, everything works fine
[10:37] <ack> slyon, the only thing I can think of that might be relevant is that since the interfaces are on different vlans, they both end up adding a default gateway
[10:38] <ack> $ ip r
[10:38] <ack> default via 10.10.10.1 dev br0 proto dhcp src 10.10.10.10 metric 100 
[10:38] <ack> default via 10.10.20.1 dev wlan0 proto dhcp src 10.10.20.30 metric 600 
[10:38] <ack>  
[10:38] <ack> doesn't seem that should be a problem, though?
[10:39] <slyon> I wonder if the br0 route goes away once you disconnect the eth0 link? If not, this could be a problem indeed.
[10:40] <slyon> so your wifi actually stays associated with the AP, but routing doesn't work anymore after you disconnected the link?
[10:40] <ack> slyon, https://paste.ubuntu.com/p/KcVFcw48Ky/
[10:40] <ack> slyon, that's a good point
[10:43] <ack> slyon, oh it seems the br0 doesn't even go away
[10:43] <ack> slyon, I wonder if the down is not detected because it happens on eth0 and br0 is not affected?
[10:44] <ack> although "Mar 18 10:10:09 ubuntu systemd-networkd[1025]: br0: Lost carrier" shows it does lose  it
[10:45] <ack> but yeah, it seems br0 is not brought down when the link on eth0 goes away, so the route stays too
[10:46] <ack> I wonder if it's raspberrypi-specific
[10:46] <slyon> Usually systemd-networkd clears the routes on carrier loss...
[10:46] <slyon> I don't think this is rpi specific
[10:47] <slyon> you could specify your routes manually for the different subnets/vlans, that should work
[10:50] <ack> slyon, so you think it's not netplan, it's systemd-networkd?
[10:51] <ack> the weird thing is that it does work if I don't use a bridge
[10:51] <slyon> sd-networkd usually clears the routes if the link goes down/carrier is lost
[10:51] <slyon> i wonder why it doesn't do that for your br0?
[10:53] <ack> slyon, right, so if I just use eth0 + wlan0, the route and IP on the interface do get cleared on link down
[11:02] <slyon> ack: does it work if you put the bridge down manually (while cable is still connected)? i.e. "ip link set dev br0 down"?
[11:03] <slyon> will it clear the routes for br0 after that command and route via wifi?
[11:05] <slyon> I think the problem is: disconnecting the link on eth0 does not automatically bring down br0. And I'm not sure if this is a bug or a feature...
[11:06] <slyon> ack: I guess you could place some routable.d and off.d hooks to bring br0 down/up automatically, via https://netplan.io/faq/#use-pre-up%2C-post-up%2C-etc.-hook-scripts (that is, if the previous test works)
[11:12] <ack> slyon, yes, if I manually set the link down/up the route goes away
[11:13] <ack> the IP is still there for br0 but the route is removed
[11:13] <ack> (so things keep working)
[11:14] <ack> slyon, so maybe the bug is that it should set br0 down if the last interface in it is disconnected
[11:15] <slyon> you could use the "networkctl down br0" command, that should clear the IP as well I guess (instead of "ip link ...")
[11:16] <slyon> ack: yes. But as I said above, I'm not sure if this is a networkd bug or feature... (There might be cases where it is important that the bridge stays up), as a workaround you could place some "networkctl up|down br0" hooks
[11:19] <ack> slyon, thanks
[14:05] <krono> Hi all, what is the canonical way to configure an Infiniband IPoIB interface via netplan?
[14:08] <slyon> hi krono! netplan does not currently support IPoIB: https://bugs.launchpad.net/netplan/+bug/1848471
[14:08] <slyon> I guess your best bet would be using systemd-networkd directly: https://systemd.network/systemd.network.html#%5BIPoIB%5D%20Section%20Options
[14:08] <krono> Hi slyon. that's interesting…
[14:09] <krono> Thanks for letting me know…
[14:09] <krono> I have around 50 machines w/ IB that now need an IP… -.-
[14:10] <krono> slyon: what would happen if I just put the ib's dev name into the ethernets: section in a config, will it just be ignored?
[14:10] <krono> (I can't test on production machines :( )
[14:11] <krono> (as per https://code.launchpad.net/~darren-birkett/cloud-init/+git/cloud-init/+merge/373759/comments/978965 it should somehow work…)
[14:13] <slyon> hmm yeah, I think the main problem is netplan being unable to match the long IB mac addresses. So if you match on other properties (like interface-name) netplan will happily generate sd-networkd configuration files and networkd will try to apply those.
[14:14] <slyon> But I cannot give any guarantees about that, as that's basically an untested/unsupported feature in netplan
[14:17] <slyon> you can write your YAML somewhere (say /tmp/my_netplan_config/etc/netplan/test.yaml) and use `netplan generate --root-dir /tmp/my_netplan_config` and check the outputs at /tmp/my_netplan_config/run/systemd/network
[14:17] <slyon> this will not change the system config, but allows you to inspect what it WOULD do
[14:17] <krono> slyon: Thanks, that is valuable info!
[14:19] <slyon> then you can cross-compare those outputs to the sd-networkd documentation at https://systemd.netwok
[14:52] <krono> slyon: Things worked for me sufficiently, thanks!
[14:52] <slyon> krono: cool, I'm glad it worked out! :)
[14:52] <krono> :)
[14:52] <krono> bye then, everybody
[14:52] <slyon> o/