Be more explicit about what happens when creating bridges

[Saviq]

It took a long time, but I was finally able to recover from the (accidental, but very real) damage caused by Multipass to my PC's networking configuration.

Wiping the OS (not fun) when a program wipes out essential networking on the computer that you depend on every day...is the sad reality we need to avoid.

So others can hopefully recover when this happens to them too — here's the command that worked for me to restore the PC's networking:

nmcli connection delete br-enp1s0

Originally posted by @holta in #2537 (comment)

[Saviq]

@holta glad you got it sorted. The only thing that seems feasible is to be more explicit in the warning - that the MAC / IP will change, and that the alternative is to manage the bridge on your own.

[Saviq]

A host's existing gateway interface and its MAC address can certainly be preserved — i.e. made to work with an added bridge.

Originally posted by @holta in #2537 (comment)

How would you configure that @holta? IIUC that would require ~swapping MACs between the physical interface and the bridge, and that's not a default we'd like to go for…

FWIW I got bored of static IPs a while ago and went for local name resolution… I know it's not suitable everywhere, but Multipass has to cater for the common case to avoid bloat.

Another note - why do you say it "wiped out essential networking"? You got a new IP, sure, but why is that "wiping out"?

[holta]

@Saviq I should explain a bit at a higher level — as quickly painting the larger picture can't hurt — providing very meaningful context I hope:

• Volunteers of all ages test our free software (https://internet-in-a-box.org) every day using old phones/tablets browsing their home PC's where Multipass VM's are running.

• Multipass is a real lifesaver, as it allows lesser-skilled volunteers to quickly help test diverse old browsers and old devices in their home — as if they're the actual students in schools in Haiti, Africa, rural Mexico etc. In short, this helps global volunteers hammer on the actual learning content (served by Internet-in-a-Box's NGINX) running on their PC and/or its Multipass VM's (where they just installed Internet-in-a-Box + learning content) to provide essential feedback a.k.a. fieldback.

• All they need to do is tell other family members (in their home) the 192.168.0.x IP addresses of their PC and its Multipass VM(s) and this absolutely invaluable browsing/testing begins!

The situation arises because dedicated volunteers' home PC's and their Multipass VM's (all of which try to get their IP address from DHCP running on their home router, if possible!) get too confusing when IP addresses jump around from one day to the next.

So we just need to do what we can to keep the PC and its VM IP addresses from changing around too often — which often means putting a couple of these IP's into their home router DHCP table (so they don't jump around).

RECAP: Your suggestion to manually pre-arrange a bridge in the Ubuntu home PC might be the best way forward — e.g. if it's too hard to automate that as of today in 2022 — thereby allowing Multipass to offer super-hassle-free access to the PC's + VM's (each with stable IP addresses) for every family member in the house.

CONCLUSION: I need to write up better/stock instructions for anybody worldwide using Multipass on Ubuntu home PC's following the above essential recipe. This will be Awesome as it will allow conscientious people in all countries to keep jumping in quickly to help, as keeps growing to serve so many. I will provide links to Multipass's own evolving documentation avoiding the worst pain points.

I suppose a few people might even have static IP addresses encoded in their home PC (rather than encoding it in their home router) as you say, indeed rare but possible. Thanks for your understanding and Multipass's real contribution to this vital effort!

FINALLY: Is it possible https://linuxcontainers.org/lxd/docs/master/instances/#nic-macvlan might help any of us streamline + automate a bit in future? I don't know yet. (But might be worth looking into, if this is not already happening?)

[holta]

How would you configure that @holta? IIUC that would require ~swapping MACs between the physical interface and the bridge, and that's not a default we'd like to go for…

I was worried about that too 😂

Still, it's an idea we might consider scripting this year — if the worst risks can be mitigated — in isolated/known (relatively standard) PC configurations.

(I don't know yet if this is the best way forward!)

[holta]

Another note - why do you say it "wiped out essential networking"? You got a new IP, sure, but why is that "wiping out"?

Removing the orphan bridge was harder than it looked, after Multipass VM's we're deleted, and trying things like snap delete multipass to recover.

Multipass's bridge actions not being easily removable / reversible effectively disabled the PC's Ethernet access to the Internet — making recovering even harder. Sometimes I had to run dhclient etc to extract the PC from this messy situation.

The problem was exacerbated by Google leading to all sorts of stale instructions recommending brctl to remove the stale bridge. None of which worked in this situation, due to NetworkManager it appears.

(But yes I finally found the nmcli connection delete br-enp1s0 command which saved the day!)

RECAP: I persisted to get a better understanding. But for regular everyday users reinstalling the OS is faster than fixing networking configurations in such situations — which might be sad, but it's indeed a stark truth 🥺 😇

[ricab]

I guess we should inform the user how to revert the bridge creation, but we'd need a dedicated communication channel back to the client for that (separate from logs). We've discussed setting up something like that. For the time being, I opened #4715 which logs a message and updates the documentation.