Error recreation:

When the user attemps to change the default password of the DAppNode wifi hotspot with a password with less than 8 characters or more than 63 characters, the wifi hotspot will loose the interface and will not be able to connect via wifi anymore, until it changes the password using the command line (ssh)

Error

Line 7: invalid WPA passphrase length 1 (expected 8..63)
WPA-PSK enabled, but PSK or passphrase is not configured.
2 errors found in configuration file '/etc/hostapd.conf'
Failed to set up interface with /etc/hostapd.conf
Failed to initialize interface

To solve it:

In the wizard of the dappnode package set a pattern (regex) for the WPA_PASSPHRASE env variable

Add the new dappnode logo to the core package logo

Issue

Users have had problems with the dappnode wifi for a long time, and seems like one of the root causes is the following issue:

When the wifi container starts, it takes the network interface from the host (commonly wlan0) as well as the physical layer, (commonly the phy0) these are the paths that simply disappear:

• /sys/class/net/wlan0
• /sys/class/ieee80211/phy0

When the wifi container gets stopped, the network interface and the physical layer should appear back in the host, but it seems like there is a delay of 1' 53'' average, to appear in the host back again.

The line of code that takes the network interface from the host is:

Debugging

This report was obtained using a script for debugging purposes, which:

1. Stops wifi container and waits for the paths to exists
2. Starts wifi container and start again

Timelapses obtained:

1. Time lapse: Thu Jul 8 16:27:50 CEST 2021 - Thu Jul 8 16:27:50 CEST 2021
2. Time lapse: Thu Jul 8 16:27:59 CEST 2021 - Thu Jul 8 16:29:52 CEST 2021
3. Time lapse: Thu Jul 8 16:30:01 CEST 2021 - Thu Jul 8 16:31:55 CEST 2021
4. Time lapse: Thu Jul 8 16:32:04 CEST 2021 - Thu Jul 8 16:33:58 CEST 2021
5. Time lapse: Thu Jul 8 16:34:07 CEST 2021 - Thu Jul 8 16:36:00 CEST 2021
   =============================================================
6. Time lapse: Thu Jul 8 18:17:55 CEST 2021 - Thu Jul 8 18:17:55 CEST 2021
7. Time lapse: Thu Jul 8 18:18:05 CEST 2021 - Thu Jul 8 18:18:05 CEST 2021
8. Time lapse: Thu Jul 8 18:18:15 CEST 2021 - Thu Jul 8 18:20:07 CEST 2021
9. Time lapse: Thu Jul 8 18:20:17 CEST 2021 - Thu Jul 8 18:22:09 CEST 2021
10. Time lapse: Thu Jul 8 18:22:19 CEST 2021 - Thu Jul 8 18:24:11 CEST 2021

Note: notice that the first attempt works without issues, the rest of them has an average delay of 1' 50-58''

Possible solutions

• The ideal solution would be to execute a systemctl restart network and make interfaces appear back again in the host. The concern is that this procedure is a bit aggressive and I did not got it work

Wifi code is a bit old and unupdated. Consider using other source codes to be used in the wifi. Options to take into account:

• https://github.com/fgg89/docker-ap/blob/master/docker_ap
• https://fwhibbit.es/en/automatic-access-point-with-docker-and-raspberry-pi-zero-w

The driver iwlwifi may break dappnode host, making wifi service to stop working. Driver iwlwifi is crutial for the host (with intel hardware) to detect the network interface, if iwlwifi not present the network interface may not be recognized by the host.

Is not a dappnode issue but a driver/debian issue

Consider open an issue at https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=firmware-iwlwifi;dist=unstable and look for better support

Describe the bug

I have an SSID on the wifi that I set early february this year, at that time it worked to set an SSID with the letter "ä".
Now it mentions that "SSID must include only simple ASCII characters" when i look in the wifi tab.
I tried chaning the ä --> a.
When clicking update credentials nothing happens.
Tried it with both the wifi on and off.

I tried letting it be for some minutes just to see if it was slow, but as soon as i go to another section like the dashboard and then back to wifi section then it's the old SSID with ä

To Reproduce

See above.

Expected behavior

Some kind of text saying "wifi credentials updated" and the credentials being updated.

Screenshots

DAppNode version:

Core DAppNode Packages versions

• bind.dnp.dappnode.eth: 0.2.6
• core.dnp.dappnode.eth: 0.2.50
• dappmanager.dnp.dappnode.eth: 0.2.45, commit: 7b9ad9ad
• https.dnp.dappnode.eth: 0.1.2
• ipfs.dnp.dappnode.eth: 0.2.15
• vpn.dnp.dappnode.eth: 0.2.8, commit: f9a8743e
• wifi.dnp.dappnode.eth: 0.2.8

System info

• dockerComposeVersion: 1.25.5
• dockerServerVersion: 20.10.2
• dockerCliVersion: 20.10.2
• os: debian
• versionCodename: bullseye
• architecture: amd64
• kernel: 5.9.0-4-amd64
• Disk usage: 76%
• Browser: Brave, using VPN going to my.dappnode. Also tried doing it via dappnode.local.

Additional context

Due to #33 , network interfaces might not exist on the host for a period of time up to 2'. This means that the INTERFACE variable assign may fail within the delay of the dappnode wifi container, which is up to 1' (

The INTERFACE assignment is done:

• DNP_WIFI/build/wlanstart.sh

  Line 59 in 348eb25

  INTERFACE=$(docker run -t --privileged --net=host --pid=host --rm --entrypoint /bin/sh ${CONTAINER_IMAGE} -c "iw dev" | grep 'Interface' | awk 'NR==1{print $2}')

  : returns empty if network interface is within the period of time where it does not exist

• DNP_WIFI/build/wlanstart.sh

  Line 62 in 348eb25

  INTERFACE=$(docker run -t --privileged --net=host --pid=host --rm --entrypoint /bin/sh ${CONTAINER_IMAGE} -c "ls /sys/class/ieee80211/*/device/net")

  : returns an error if network interface is within the period of time where it does not exist

When upgrading the package, the container is destroyed to deploy the new one, and the interface captured by the package is not seen anymore.

Fixed with a reboot, but we should investigate a way to 'liberate' again the interface to the host on upgrades.

A few users have shown their concern for the wifi status. Wifi may be a security vulnerability so users should have the option to disable it persistently. This would eliminate an entry point for possible attacks

Currentyly, wifi is a core package that has a restart policy of "always", so even when you toggle it off and reboot the host machine, the wifi container starts again.

In this case, a solution would be to consider changing the restart policy from "always" to "unless-stop", so the wifi container status is persistent when rebooting.

Update hardcoded IPs in entrypoint

Wifi package should be restarted always unless the package was manually stopped by the user. According to the restart policy unless-stopped docker will restart the container if the exit code is != 0.

Currently, the wifi container will exit with an exit code in two situations, this will prevent the wifi package from been restarted:

• Exit codes should be change to non-zero codes, so the wifi package keeps restarting unless the user manually stops it
• Look for a better way of knowing if the host machine has a network interface: ls /sys/class/ieee80211/*/device/net/

Take into account that remote dappnodes will have this package restarting in an infinite loop unless the user manually disables it.

Currently, when a module is stopped, it will return to a running state upon reboot.

Having an option to permanently stop the module and prevent is from returning to a running state after a reboot would be very helpful.

Stopping DAppNodeCore-wifi.dnp.dappnode.eth container results in an exit code 137. This means that the default timeout was not enough to stop the container and docker sent a SIGKILL signal to the container to stop it. Even giving a greater timeout result in same error. (docker stop DAppNodeCore-wifi.dnp.dappnode.eth -t 60)

This is critical for the UI since the container will appear as status crashed whereas it was paused

Expected behaviour

Stop DAppNodeCore-wifi.dnp.dappnode.eth container results in exit code 0.

Possible solution

Add a listener to stop the container when sent docker-stop signal to gracefully shut it down to wlanstart.sh