[Bug]: Duplicate indices in WiFi client page prevent from adding a nearby WiFi network #2003

Code of Conduct

• I agree to follow this project's Code of Conduct.

Issue reporting checklist

• I have read and understand the issue reporting policy.
• I have read and followed the common sense checklist.
• I observed this bug on a clean install of a supported OS.
• I have followed the project prerequisites.
• I have searched this repository for existing issues.
• I checked the FAQ and official documentation.
• I am using an external wireless adapter.
• I have generated a RaspAP debug log and performed a self-diagnosis.

Operating System

Raspberry Pi OS Lite 64-bit Debian 12 (bookworm)

Installation method

Quick install

Onboard wireless chipset or external adapter?

External adapter

Hardware

Raspberry Pi 4 Model B

RaspAP version

Other (specify below)

Other software or services running with RaspAP?

No other software

Contact details (optional)

No response

Bug description

It seems the code in
https://github.com/RaspAP/raspap-webgui/blame/aecf8e6e94bc969ac3c461da39cef2a1035aadde/src/RaspAP/Networking/Hotspot/WiFiManager.php#L97
assumes that the last item in the list of known WiFi networks always holds the highest index.

However, I observed on my one-year old installation RaspAP (updated to 3.4.6 recently) that this assumption is not always true.
This can lead to an index value being used twice. For example, I had an index 6 for a known WiFi station and also an index 6 for a nearby WiFi station. I was not able to add that nearby WiFi because of the duplicate index/ID. (well, in fact I did after manipulating the HTML in the browser)

I'm not sure if I ran into an exceptional/unexpected configuration here, where the order in the wpa_supplicant.conf doesn't reflect the indices that are returned by sudo wpa_cli -i $iface list_networks which is used by WiFiManager::getNetworkIdBySSID() to determine the indices, but I think we could make the code more robust, there.

Something like:

$index = 0;
if (!empty($networks)) {
    foreach ($networks as $network) {
        if (isset($network['index']) && ($network['index'] >= $index)) {
            $index = $network['index'] + 1; // It's probably not exactly clean to instantly increment. That could also be done after the loop, of course. If so, the equal sign in the comparison above must be removed as well.
        }
    }
}

That's at least how I've patched it so far.

Steps to reproduce

Preconditions:

• No known networks yet.
• There must be at least two nearby networks to which the credentials are known or that are open, so that they can be added.
• There must be additional nearby networks.

Steps:

1. Add two networks by their credentials.
2. Delete the network that was added first.
3. Add deleted network again.
4. Check the indices of all the networks (known and nearby) shown on the page by inspecting the HTML.

After step 2 and a reboot I checked the configuration via commandline and found this:

$ cat /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
        ssid="RouterWiFi"
        psk=...
}
network={
        ssid="iPhone"
        psk=...
}

$ sudo wpa_cli -i wlan1 list_networks
network id / ssid / bssid / flags
0               any     [DISABLED]
1       iPhone any     [DISABLED]
2       RouterWiFi      any     [DISABLED]

So, the order in the wpa_supplicant.conf does not reflect the IDs/indices given by wpa_cli list_networks.

Screenshots

No response

Additional context

No response

Relevant log output