labs/kernel-board-setup-bbb: force disable NetworkManager IPv6

[tleb]

Two trainees faced issues this week with their NetworkManager not bringing up their interface after the usual nmcli con add ... command.

For the first one, first mistake was to not have removed the Snagboot netns coming from am335x_usb_setup.sh. One that was fixed, with the usual nmcli con add ..., NM didn't bring the interface up and logs looked like:

<info> [033.2553] manager: (eth1): new Ethernet device (/org/freedesktop/NetworkManager/Devices/63)
<info> [033.2717] device (eth1): interface index 60 renamed iface from 'eth1' to 'enxf8dc7a000001'
<info> [033.2822] device (enxf8dc7a000001): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
<info> [033.2840] device (enxf8dc7a000001): carrier: link connected
<info> [033.2843] device (enxf8dc7a000001): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed')
<info> [033.2847] policy: auto-activating connection 'ethernet-enxf8dc7a000001-1' (<SOME_UNIQUE_HASH>)
<info> [033.2853] device (enxf8dc7a000001): Activation: starting connection 'ethernet-enxf8dc7a000001-1' (<SOME_UNIQUE_HASH>)
<info> [033.2855] device (enxf8dc7a000001): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
<info> [033.2859] device (enxf8dc7a000001): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
<info> [033.2863] device (enxf8dc7a000001): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
<warn> [033.3609] l3cfg[<SOME_UNIQUE_HASH2>,ifindex=60]: unable to configure IPv6 route: type unicast fe80::/64 dev 60 metric 1024 mss 0 rt-src ipv6ll
<info> [039.3610] device (enxf8dc7a000001): state change: ip-config -> unavailable (reason 'carrier-changed', sys-iface-state: 'managed')

We get stuck in ip-config for 6 seconds, even though we want give it a manual IPv4. The warn log line about IPv6 made us try to force disable IPv6 config (set ipv6.method value to disabled). Once that was done, logs looks like above but without the warn line but still no link up. After a reboot it was solved.

Second trainee had the same issue (logs as above). We directly tested ipv6.method set to disabled && reboot, which solved it.

Technically, the known fix sequence is:

nmcli con add type ethernet ifname enxf8dc7a000001 ip4 192.168.1.1/24
# ping ran on BBB, not working
nmcli con modify ethernet-enxf8dc7a000001 ipv6.method disabled
reboot
# ping ran on BBB, working

But we hope it is equivalent to the proposed patch. Please give your opinion!

I tried finding a reason in NetworkManager NEWS (ie its changelog) and nothing stood out.

[Tropicao]

I don't have strong opinion on the provided patch, as relying on ipv4 only is fine for this kind of very local network, so the provided fix looks reasonable. Even if it is not part of the final patch, I wouldn't mention a reboot to make it active if done after the connection configuration (it sounds quite aggressive to ask trainees to reboot their laptop, and especially inconvenient for online session). If the configuration is done after having already enabled the connection, I guess a bare nmcli con down <...>; nmcli con up <...> is enough

About the potential root cause of this failed ping, couldn't it be due to ipv6 autoconfiguration (used for auto-addressing) not completing ? I've seen this feature being deactivated explicitely in many network-related tests I have been working on, because it can add some non-negligeable delay in the duration needed to have usable network interfaces