WIFI & Tethering : DHCP server stays on after moving from Tether to expected network

[zaicik]

FPP Version and Hardware**:

While bebugging and to save everyone time, I reproduced the bug on multiple configs:

• Versions :
  • FPP 7.5
  • FPP 8.2
• Hardware : Raspberry Pis
  • RPi Zero W
  • RPi Zero 2 W
  • RPi 4 (wifi only, no ethernet cable plugged in)

Steps to reproduce

1. Boot FPP device (RPi here) while wifi network is unavailable
2. Turn on RPi and wait until FPP is visible
3. Turn on "normal" wifi (let's call it my_ssid) and wait a bit => FPP is gone, your RPi has joined my_ssid => EDIT: if an OLED is attached, FPP still advertises the tethering QR-code even though it's not longer here
4. Join my_ssid from your computer => your IP should be in the 192.168.8.0/24 subnet => you probably don't have access to other devices on my_ssid => if my_ssid is connected to the internet, you probably don't have web access
5. Additional check : go to http://fpp.local/proxies.php or http://192.168.8.1/proxies.php and verify that your current IP address has indeed been allocated by FPP

Expected behavior

After finding the expected network is (back) up, I'd expect FPP to join it ( :white_check_mark: it does), shutdown its own DHCP ( :x: it doesn't) and request a lease from the network's server (:x: it doesn't)

Additional Attachments

Made a fresh install so the logs are super clean => booted for basic configuration and add my wifi ssid and pass (and set log level to debug) => rebooted to reproduce the issue

FPP_Logs_20240906.0829.zip

Supplemental notes (half issue / half feature request)

When wifi suddenly becomes unavailable – and stays so for a while (timeout to be determined) – FPP just waits for it to come back and stays unavailable.

It might be practical to launch tethering, in order to still get access to the player, without having to reboot or wait for the overall wifi issue to be resolved.

I'm putting this here because I feel that if this reported :arrow_up: issue gets addressed, adding that new behavior should be pretty straightforward and together address quite a few situations (esp with mobile / traveling setups)

Final words

    :v: Cheers !

[cbennett6008]

regarding the last bit, I think it would be problematic if wifi went away, (like a WAP rebooting) caused controllers to go to a tether state, and need rebooted to come back up

[zaicik]

@cbennett6008 : OFC 💯 And that's also precisely why I mentioned that "properly rejoining the expected wifi" (this ticket's main subject) is a pre-requisite, and the need for proper timeout determination 😉

Also: I've since attached an OLED display (wish I'd thought of that earlier, would have saved a bit of time investigating the issue) and noticed a related QR-Code issue. I just edited the original post (step 3) to include it.

[cbennett6008]

Can you reproduce the dhcpd server remaining running after https://github.com/FalconChristmas/fpp/commit/b170bbca964d03ffd6b63bcdb97b963c3affe0ed?

I cannot.