DietPi-Installer | Allow WiFi-only install, workaround NetMan uninstall

[mohitverma123]

Orange pi lite has only WIFI and not an ethernet port, hence wifi is only possible network access for it. The install script removes wifi (even after we select Yes, I need wifi modules)

[MichaIng]

@mohitverma123 Thanks for your report. We will investigate.

As an active eth0 connection is expected (https://github.com/Fourdee/DietPi/blob/master/PREP_SYSTEM_FOR_DIETPI.sh#L8), this might be a general issue on WiFi-only devices.

Maybe we find a way to preserve WiFi connection (and settings) when no eth device is available. I hope NetworkManager does not always drop connection on removal, as we do not want to keep it for the final image.

[Fourdee]

@MichaIng

this might be a general issue on WiFi-only devices.

Yep, correct 👍

Always been a problem with image creation on WiFi only devices with NetworkManager installed.

The only solution I found, was to run PREP, via serial connection and manually reconfigure WiFi if required.

We'll need to see if we can upgrade PREP script to:

• Detect WiFi only device
• Prompt user for WiFi creds
• Somehow apply the settings and reconnect after netman removal.

Or, (hopeful):

• See if netman offers an option to not disconnect on software removal

[MichaIng]

Ref: https://wiki.debian.org/WiFi/HowToUse

• [x] Check /etc/NetworkManager/NetworkManager.conf for WiFi interface info to scrape
• [x] Check if netman really uses wpa_supplicant /etc/wpa_supplicant/wpa_supplicant.conf as backend, so we can keep SSID/authentication info.

[MichaIng]

I successfully installed DietPi via preparation script on a WiFi-only device with direct console access. netman however was not pre-installed on the fresh Debian image, installed via Debian netboot installer.

• NetworkManager uses wpa_supplicant (or equivalent) as backend for WiFi connections, if available. Hence at least if wpa_supplicant is used, the WiFi credentials will survive.
• It invokes ifupdown scripts (if available), but does not handle interfaces that are declared in /etc/network/interfaces by default: https://wiki.debian.org/NetworkManager
• It uses dhclient (isc-dhcp-client) as backend, if available, but can also be used to setup static interfaces, which will then be stored like this:

  
  root@Test:~# cat /etc/NetworkManager/system-connections/eth0
  [connection]
  id=eth0
  uuid=XXX
  type=ethernet
  autoconnect-priority=-999
  permissions=
  timestamp=1539887556

[ethernet] mac-address=XX:XX:XX:XX:XX:XX mac-address-blacklist=

[ipv4] address1=192.168.178.31/24,192.168.178.1 dns=192.168.178.1; dns-search= method=manual

[ipv6] addr-gen-mode=stable-privacy dns-search= method=auto

So generally we have two possibilities:
- Scrape interface information from `/etc/NetworkManager/system-connections/*`, if available, and store those to `/etc/network/interfaces`, if not yet the case. The interface name (eth0, wlan0, enp0s3. wlp0s3) can be retrieved by comparing MAC address with `ip l` output. The profile name can be freely chosen, so `eth0` above was entered by me, while the interface name is `enp0s3` (Stretch+ default naming scheme).
- Or we simply scrape `ip r` + `ip a` outputs, possibly required (possibly on old systems `route` + `ifconfig` needed?) and retrieve IP, netmask and standard gateway from there, then store those info to /etc/network/interfaces again.
- WiFi credentials stay stored within `wpa_supplicant` as said, so they survive as long as there is no alternative WPA handler?

Then testing is required, if connection can stay active, when installing DietPi default network packages first, configure them (/etc/network/interfaces), in case `systemctl restart networking; ifup $IFACE` and then purge `network-manager`.

[MichaIng]

Additionally: connman: https://github.com/MichaIng/DietPi/issues/1285#issuecomment-508415843

General issue, even when we manually pre-configure the network with ifupdown, if uninstalling netman or connman always drops the connection, the SSH connection breaks which again breaks the installer, so re-connecting is not done anymore. This only works from a screen session which goes on in the background and can be reattached to.

So currently indeed, if no local console (keyboard+monitor) is available, a serial console is required to reliably have the installer finish, at least when SSH is only possible via WiFi.

Not sure if Ethernet connections, controlled by netman or connman, can break as well? At least I never faced that.