Iiab: LAN issue with bridge (br0) on Ubuntu 18.04

Created on 15 Mar 2019  Â·  11Comments  Â·  Source: iiab/iiab

This post includes a solution as well as the problem, and links to relevant config files.

Problem

1) I have Ubuntu 18.04 (desktop) running on NUC (Q4/18 make)
2) I have installed IIAB based on the instructions in docs
3) I did make modifications to the loval_vars.yml
4) There were no error messages during installation (at least I did not notice any)
5) I was connected to the internet through WIFI during installation
6) IIAB installs successfully and works as expected except only http://localhost responds

That's precise. Here it gets a little fuzzy.

7) I changed something in a config file, I guess it must have been local_vars.yml (as that is what I had learned so far) and after that I ran something. I saw it elsewhere in docs, in a similar context and ran it.
8) After this box.lan became responsive from NUC directly (I'm accessing the desktop) and from a client (my laptop basically)

I appreciate that it might have nothing to do with this, so let me know if I should open a separate issue for it and provide more information. I think I can back track to exactly what I did there.

Then...

9) Upon closer inspection, we find with Anish that there is in fact a LAN issue on the NUC. For btctl I get:

bridge name bridge id       STP enabled interfaces
br0     8000.00bb60460e56   yes     wlp0s20f3

This does not change by running ./iiab-network.

Solution

I have just now tried:

sudo brctl addif br0 eno1
sudo ./iiab-network

...and it yields the missing lan port on the NUC! It also immediately starts to function, as now my AR-150 mesh-node becomes accessible and serves the internet I have connected in the NUC.

bridge name bridge id       STP enabled interfaces
br0     8000.00bb60460e56   yes     eno1
                            wlp0s20f3

Resources

/etc/iiab/iiab.ini

/etc/iiab/iiab.env

/opt/iiab/iiab/iiab-install.log

/opt/iiab/iiab/iiab-network.log

bug help wanted

All 11 comments

Huge Thanks @mikkokotila

@jvonau can you help me learn from this, with a call if nec, to refine IIAB's 1-line installer so the fast-growing number of WiFi installs (NUC, RPi, legacy laptops) become Far Less confusing for IIAB 7.0 ?

Refs: #1306 #1519 #1527 #1536 #1569

manually adding eno1 to br0 probably won't survive a reboot. also, the sudo ./iiab-network probably doesn't add anything.

It sounds like the problem was not that wifi did not transition from gateway to hotspot, but that wired eth was wanted on lan but did not go there because that is not the programmed behavior.

Well said @tim-moody

We need far better docs built-into the install-over-WiFi process itself, and I'll work on that with @jvonau

@tim-moody That's right. For now I'll just included it in .bashrc which is something that of course could be done as part of the IIAB install. Suboptimal, but seems to fix this case for now and does not involve changing anything.

Related with this, I think there is a challenge in expecting that users read things; during the installation the user is faced with 60 minutes of mostly continuously updating screen. I think only an expert user will really pay attention to something like that.

I did notice that in the beginning of the install it said that it's strongly recommended to use ehternet for installation and not wifi, but at that point it felt more like a suggestion that ethernet is somehow intrinsically more stable or reliable than WIFI. Which seems counter-intuitive as the WI-FI is for most part used in the same space where the ethernet is.

I don't understand the intricacies related with this, but it seems that the user should absolutely not have to think about if they are on WIFI or if they are on Ethernet. If they indeed do, I would make sure that the installation docs prominently mention this, and the iiab-network and iiab-install require a prompt that suggests automatically handling this post installation (maybe just by as per above) before the install is possible and which requires a full 'yes' or 'no' as a response. I think that would do it.

@jvonau, Mikko (like Mitra & Emily in recent weeks) has provided us another excellent Install-IIAB-over-WiFi usability challenge above:

1) What's the right way for him to solve Ethernet-under-br0 (bridge) instead of .bashrc on each reboot?

2) So we can start to encode this into a far cleaner install-over-WiFi process, that critically sets accurate expectations (on-screen warning/explanation-or-if-nec-YouTube-tutorial near the very beginning when 1-line installer's run!)

3) _Context:_ Most every grassroots educator/operator/implementer wants the Ethernet jack on their IIAB to instantly work with an Ethernet-to-Internet cable, so things like OpenVPN just work(TM) for remote field debugging/occasional updates etc. Especially during those mad first few weeks/months of a deployment, when a nervous new non-technical operator is in charge locally, and fine-tuning content/configuration needs become obvious — as the local community comes together understanding their Internet-in-a-Box and needs a couple refinements.

4) _Future Coming Too Fast:_ Fields operators are beginning to ask for occasional updates/remote debugging over Wi-Fi too. I presume the answer here is to build awareness around iiab-hotspot-off and iiab-hotspot-on, so field operators can increasingly take charge on their own, facilitated by a remote implementation guru/mentor (typically on broadband, in a wealthier place or city, e.g. the Granny Cloud) when they're lucky enough to have one!

Ref: https://github.com/iiab/iiab/issues/1519#issuecomment-467165902

Given I already have an affected system running live, I could be a guinea pig for implementation ideas.

It appears I never created the network-manager template for the wired slave as that use case became less important than keeping the wired device available for upstream use. Rather than use .bashrc you could use iiab-startup for the hack. You could use the network manager connection editor to add the the device to the bridge, if you choose this route I would be interested in the files in /etc/NetworkManager/system-connections/ to base the required template upon.

You could use the network manager connection editor to add the the device to the bridge, if you choose this route I would be interested in the files in /etc/NetworkManager/system-connections/ to base the required template upon.

@mikkokotila if poss can you post these using cat file | pastebinit or similar?

@mikkokotila does the just-merged PR #1636 dnsmasq fix (during initial network configuration, on many laptops/NUCs etc, for #1306) possibly improve your situation (#1572) here?

@jvonau @m-anish can you confirmed this is now solved by your recent dnsmasq / networking PR's ?

Was this page helpful?
0 / 5 - 0 ratings