to put my paint point first, maybe it was not clear: at boot NM does not connect at boot to a WiFi. Instead I have to click the applet, wait multiple seconds for a scan to finish and then have to choose the wifi manually. NM says it would be connected to my bridge, see attached screenshot.
> I still don't undestand: Are you saying that NM tries to manage your > "bridge" interface while it shouldn't? ^ this, at least sort of: it behaves like the presence of the bridge is enough, while the bridge can't give me internet access. It doesn't change bridge's settings AFAICT > Or are you expecting NM to manager your bridge interface but it does not? > Anyway, if want to mark a device as unmanaged by NM, you have more > explicit ways then relying on the eni parser. > E.g. you could create a conf file like this: > > # cat /etc/NetworkManager/conf.d/unmanaged.conf > [keyfile] > unmanaged-devices=interface-name:bridge thanks for this suggestion, I'll try it! however I still think theres something unnecessarily annoying that should be fixed, especially when docu suggest that ENI was enough. > I don't see anything in the logs which would indicate that NM manages > your bridge interface, it simply shows, that such a device has been > detected. the lines from the log that read wrong to me: > <info> adding bridge port none to eni_ifaces none is a special value indicating an empty list that I guess the parser does not handle. If this was python it would be "bridge_ports = []" > <info> devices added (path: /sys/devices/virtual/net/bridge, iface: bridge) > <info> device added (path: /sys/devices/virtual/net/bridge, iface: bridge): > no ifupdown configuration found. I can't find another explanation for this as that the eni parser is wrong > <info> device (bridge): Activation: starting connection 'bridge' > (92896f34-0c23-4893-a459-7bf9f941f397) if this is not saying that NM does something about the bridge, then it's misleading.
signature.asc
Description: OpenPGP digital signature
