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:25 |
ack | this is my config: https://paste.ubuntu.com/p/2MJ3DSYyKr/ | 10:27 |
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:31 |
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:37 |
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:38 |
slyon | I wonder if the br0 route goes away once you disconnect the eth0 link? If not, this could be a problem indeed. | 10:39 |
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:40 |
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:43 |
ack | although "Mar 18 10:10:09 ubuntu systemd-networkd[1025]: br0: Lost carrier" shows it does lose it | 10:44 |
ack | but yeah, it seems br0 is not brought down when the link on eth0 goes away, so the route stays too | 10:45 |
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:46 |
slyon | you could specify your routes manually for the different subnets/vlans, that should work | 10:47 |
ack | slyon, so you think it's not netplan, it's systemd-networkd? | 10:50 |
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:51 |
ack | slyon, right, so if I just use eth0 + wlan0, the route and IP on the interface do get cleared on link down | 10:53 |
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:02 |
slyon | will it clear the routes for br0 after that command and route via wifi? | 11:03 |
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:05 |
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:06 |
ack | slyon, yes, if I manually set the link down/up the route goes away | 11:12 |
ack | the IP is still there for br0 but the route is removed | 11:13 |
ack | (so things keep working) | 11:13 |
ack | slyon, so maybe the bug is that it should set br0 down if the last interface in it is disconnected | 11:14 |
slyon | you could use the "networkctl down br0" command, that should clear the IP as well I guess (instead of "ip link ...") | 11:15 |
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:16 |
ack | slyon, thanks | 11:19 |
krono | Hi all, what is the canonical way to configure an Infiniband IPoIB interface via netplan? | 14:05 |
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:08 |
krono | Thanks for letting me know… | 14:09 |
krono | I have around 50 machines w/ IB that now need an IP… -.- | 14:09 |
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:10 |
krono | (as per https://code.launchpad.net/~darren-birkett/cloud-init/+git/cloud-init/+merge/373759/comments/978965 it should somehow work…) | 14:11 |
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:13 |
slyon | But I cannot give any guarantees about that, as that's basically an untested/unsupported feature in netplan | 14:14 |
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:17 |
slyon | then you can cross-compare those outputs to the sd-networkd documentation at https://systemd.netwok | 14:19 |
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/ | 14:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!