starred/super

Fork 0

mirror of https://github.com/spr-networks/super.git synced 2026-04-24 20:35:55 +03:00

[GH-ISSUE #184] iPhone device listed twice #52

New issue

Closed

opened 2026-03-04 01:34:26 +03:00 by kerem · 6 comments

kerem commented

2026-03-04 01:34:26 +03:00

Owner

Originally created by @rgov on GitHub (Aug 11, 2023).
Original GitHub issue: https://github.com/spr-networks/super/issues/184

SPR 0.2.16 on Clearfog.

I had an existing iPhone device which I duplicated (from Safari) so that it would use the same iCloud Keychain password. After adding the device I refreshed the browser (because there's a bug where after adding a device it immediately pops up a modal). Then I renamed the device from "EVA Phone 12 mini #copy" to "EVA Phone 13 mini".

The state seemed to get a little messed up because there was an entry showing "EVA Phone 13 mini" with no PSK (showing as "N/A" on the device list, like a hardwired device), and no groups, but the correct MAC address (the iPhone's real MAC, not a random private one). And then the "EVA Phone 12 mini #copy" is populated with a WPA key but no MAC address.

The MAC shown here matches what was displayed on the iPhone's setting screen.

The phone is happy connected at 10.0.0.66 and once I added it to LAN/WAN/DNS groups it was able to access the internet. I can ping the device from another host and it responds:

$ ping 10.0.0.66
PING 10.0.0.66 (10.0.0.66) 56(84) bytes of data.
64 bytes from 10.0.0.66: icmp_seq=1 ttl=64 time=4.35 ms
64 bytes from 10.0.0.66: icmp_seq=2 ttl=64 time=20.5 ms
64 bytes from 10.0.0.66: icmp_seq=3 ttl=64 time=40.5 ms
^C
--- 10.0.0.66 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 4.346/21.774/40.455/14.768 ms

The MAC address for this device does NOT appear in the sae_passwords file. Therefore I'm surprised it is able to join the network.

However there is a device ff:ff:ff:ff:ff:ff with the same shared password, not sure if that plays into it.

Originally created by @rgov on GitHub (Aug 11, 2023). Original GitHub issue: https://github.com/spr-networks/super/issues/184 SPR 0.2.16 on Clearfog. I had an existing iPhone device which I duplicated (from Safari) so that it would use the same iCloud Keychain password. After adding the device I refreshed the browser (because there's a bug where after adding a device it immediately pops up a modal). Then I renamed the device from "EVA Phone 12 mini #copy" to "EVA Phone 13 mini". The state seemed to get a little messed up because there was an entry showing "EVA Phone 13 mini" with no PSK (showing as "N/A" on the device list, like a hardwired device), and no groups, but the correct MAC address (the iPhone's real MAC, not a random private one). And then the "EVA Phone 12 mini #copy" is populated with a WPA key but no MAC address. <img width="262" alt="image" src="https://github.com/spr-networks/super/assets/108767/f5570b8a-bfd2-4af2-9f46-96747994779f"> The MAC shown here matches what was displayed on the iPhone's setting screen. <img width="747" alt="image" src="https://github.com/spr-networks/super/assets/108767/28839ca5-7792-41b4-a4a4-018a8e5db832"> The phone is happy connected at 10.0.0.66 and once I added it to LAN/WAN/DNS groups it was able to access the internet. I can ping the device from another host and it responds: ``` $ ping 10.0.0.66 PING 10.0.0.66 (10.0.0.66) 56(84) bytes of data. 64 bytes from 10.0.0.66: icmp_seq=1 ttl=64 time=4.35 ms 64 bytes from 10.0.0.66: icmp_seq=2 ttl=64 time=20.5 ms 64 bytes from 10.0.0.66: icmp_seq=3 ttl=64 time=40.5 ms ^C --- 10.0.0.66 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 4.346/21.774/40.455/14.768 ms ``` The MAC address for this device does NOT appear in the `sae_passwords` file. Therefore I'm surprised it is able to join the network. <img width="305" alt="image" src="https://github.com/spr-networks/super/assets/108767/18c4e5c0-9d56-47b2-b1f4-68235cbc6d2c"> However there is a device `ff:ff:ff:ff:ff:ff` with the same shared password, not sure if that plays into it.

kerem closed this issue

2026-03-04 01:34:26 +03:00

kerem commented

2026-03-04 01:34:27 +03:00

Author

Owner

@rgov commented on GitHub (Aug 11, 2023):

Subsequently the iPhone dropped from the network and then reattached with a new MAC address (perhaps a randomized private one), which then got assigned to the pending entry which had the right PSK. Now it's at 10.0.0.70.

@rgov commented on GitHub (Aug 11, 2023): Subsequently the iPhone dropped from the network and then reattached with a new MAC address (perhaps a randomized private one), which then got assigned to the pending entry which had the right PSK. Now it's at 10.0.0.70.

kerem commented

2026-03-04 01:34:27 +03:00

Author

Owner

@rgov commented on GitHub (Aug 11, 2023):

Here are the new phone connecting as :6a and then again as :30:

{"Event":"AP-STA-CONNECTED","Iface":"wlan1.4115","MAC":"...:30","Router":"","Status":""}
info
8/10/2023, 9:44:40 PM
{"Event":"AP-STA-CONNECTED","Iface":"wlan0.4108","MAC":"...:6a","Router":"","Status":""}
info
8/10/2023, 9:29:09 PM
{"Event":"AP-STA-CONNECTED","Iface":"wlan0.4108","MAC":"...:6a","Router":"","Status":""}
info
8/10/2023, 9:29:06 PM
{"Event":"AP-STA-CONNECTED","Iface":"wlan0.4107","MAC":"...:6a","Router":"","Status":""}
info
8/10/2023, 9:28:58 PM

But also these wifi:auth:fail events. Quite surprising to go back to 7 PM.

{"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"}
info
8/10/2023, 9:54:21 PM
{"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"}
info
8/10/2023, 9:54:21 PM
{"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"}
info
8/10/2023, 9:54:20 PM
{"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"}
info
8/10/2023, 9:54:20 PM
{"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"}
info
8/10/2023, 9:54:20 PM
{"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"}
info
8/10/2023, 9:54:20 PM
{"MAC":":6a","Reason":"mismatch","Status":"","Type":"sae"}
info
8/10/2023, 9:38:05 PM
{"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"}
info
8/10/2023, 7:12:35 PM
{"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"}
info
8/10/2023, 7:12:35 PM
{"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"}
info
8/10/2023, 7:12:35 PM
{"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"}
info
8/10/2023, 7:12:34 PM
{"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"}
info
8/10/2023, 6:56:49 PM
{"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"}
info
8/10/2023, 6:56:48 PM

@rgov commented on GitHub (Aug 11, 2023): Here are the new phone connecting as `:6a` and then again as `:30`: ``` {"Event":"AP-STA-CONNECTED","Iface":"wlan1.4115","MAC":"...:30","Router":"","Status":""} info 8/10/2023, 9:44:40 PM {"Event":"AP-STA-CONNECTED","Iface":"wlan0.4108","MAC":"...:6a","Router":"","Status":""} info 8/10/2023, 9:29:09 PM {"Event":"AP-STA-CONNECTED","Iface":"wlan0.4108","MAC":"...:6a","Router":"","Status":""} info 8/10/2023, 9:29:06 PM {"Event":"AP-STA-CONNECTED","Iface":"wlan0.4107","MAC":"...:6a","Router":"","Status":""} info 8/10/2023, 9:28:58 PM ``` But also these `wifi:auth:fail` events. Quite surprising to go back to 7 PM. ``` {"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"} info 8/10/2023, 9:54:21 PM {"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"} info 8/10/2023, 9:54:21 PM {"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"} info 8/10/2023, 9:54:20 PM {"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"} info 8/10/2023, 9:54:20 PM {"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"} info 8/10/2023, 9:54:20 PM {"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"} info 8/10/2023, 9:54:20 PM {"MAC":":6a","Reason":"mismatch","Status":"","Type":"sae"} info 8/10/2023, 9:38:05 PM {"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"} info 8/10/2023, 7:12:35 PM {"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"} info 8/10/2023, 7:12:35 PM {"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"} info 8/10/2023, 7:12:35 PM {"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"} info 8/10/2023, 7:12:34 PM {"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"} info 8/10/2023, 6:56:49 PM {"MAC":":6a","Reason":"noentry","Status":"","Type":"sae"} info 8/10/2023, 6:56:48 PM ```

kerem commented

2026-03-04 01:34:27 +03:00

Author

Owner

@rgov commented on GitHub (Aug 11, 2023):

Phone connected again as :6a and I was able to compare the sae_passwords file. Indeed it seems to be the ff:ff:ff:ff:ff:ff entry that appears when this device can auth:

$ diff /tmp/{,no-}connect-sort.txt
0a1
> 
9d9
< [shared PSK between my Apple devices]|mac=ff:ff:ff:ff:ff:ff

Confirmed that there is only one entry for this :6a MAC in my devices.json and indeed it does not have a PSK associated with it, as shown in the first post.

@rgov commented on GitHub (Aug 11, 2023): Phone connected again as `:6a` and I was able to compare the `sae_passwords` file. Indeed it seems to be the `ff:ff:ff:ff:ff:ff` entry that appears when this device can auth: ``` $ diff /tmp/{,no-}connect-sort.txt 0a1 > 9d9 < [shared PSK between my Apple devices]|mac=ff:ff:ff:ff:ff:ff ``` Confirmed that there is only one entry for this `:6a` MAC in my devices.json and indeed it does not have a PSK associated with it, as shown in the first post.

kerem commented

2026-03-04 01:34:27 +03:00

Author

Owner

@rgov commented on GitHub (Aug 11, 2023):

Ok, here's my theory. The issue involves having two device entries:

One with the station MAC address assigned, but no PSK as if it's a wired device.
One that's pending, but with the PSK entry populated (because it was duplicated from another entry).

When SPR regenerates the sae_passwords file, it adds a wildcard entry for the pending device, entry 2:

github.com/spr-networks/super@99d7281e66/api/code/radios.go (L56-L60)

The station connects, and provides the password that matches the wildcard entry, so it gets authed.

Somewhere else in the system it uses the station MAC address to decide what IP address, groups, tags, etc. to apply. This matches device entry 1, before it decides to overwrite the "pending" entry. Thus the device gets assigned 10.0.0.66.

@rgov commented on GitHub (Aug 11, 2023): Ok, here's my theory. The issue involves having two device entries: 1. One with the station MAC address assigned, but no PSK as if it's a wired device. 2. One that's pending, but with the PSK entry populated (because it was duplicated from another entry). When SPR regenerates the `sae_passwords` file, it adds a wildcard entry for the pending device, entry 2: https://github.com/spr-networks/super/blob/99d7281e66e0d27e05ed3c4fa0744779a8c70c3d/api/code/radios.go#L56-L60 The station connects, and provides the password that matches the wildcard entry, so it gets authed. Somewhere else in the system it uses the station MAC address to decide what IP address, groups, tags, etc. to apply. This matches device entry 1, before it decides to overwrite the "pending" entry. Thus the device gets assigned 10.0.0.66.

kerem commented

2026-03-04 01:34:27 +03:00

Author

Owner

@rgov commented on GitHub (Aug 15, 2023):

@lts-rad Does this reproduce for you, maybe one of the parts of this issue?

Duplicate a Wi-Fi client. New entry is added with pending MAC address.
Wi-Fi client connects; you get a notification in the browser, but the device list in the browser doesn't update the show the MAC address. The devices.json file is updated to replace the pending entry with the fixed MAC address.
Rename the device. This causes a write to the devices.json file. Because the browser still thinks the device is pending, it ends up creating a new pending entry with the new name, and the same Wi-Fi password.

@rgov commented on GitHub (Aug 15, 2023): @lts-rad Does this reproduce for you, maybe one of the parts of this issue? 1. Duplicate a Wi-Fi client. New entry is added with pending MAC address. 2. Wi-Fi client connects; you get a notification in the browser, **but the device list in the browser doesn't update the show the MAC address**. The devices.json file is updated to replace the pending entry with the fixed MAC address. 3. Rename the device. This causes a write to the devices.json file. Because the browser still thinks the device is pending, it ends up creating a new pending entry with the new name, and the same Wi-Fi password.

kerem commented

2026-03-04 01:34:27 +03:00

Author

Owner

@lts-rad commented on GitHub (Aug 16, 2023):

havent had a chance to try yet. so it sounds like a UI fix is needed

dont rename pending devices
make sure to update devices when the pending device connects

and on the api end
1 ) dont accept calls w/ pending for updating/editing a device

@lts-rad commented on GitHub (Aug 16, 2023): havent had a chance to try yet. so it sounds like a UI fix is needed 1) dont rename pending devices 2) make sure to update devices when the pending device connects and on the api end 1 ) dont accept calls w/ pending for updating/editing a device

kerem referenced this issue

2026-03-04 01:36:26 +03:00

[PR #163] [MERGED] Bug fixes for dns-block build and pfw #patch #352

kerem referenced this issue

2026-03-04 01:36:26 +03:00

[PR #164] [CLOSED] new build, dns fixes #353

kerem referenced this issue

2026-03-04 01:36:27 +03:00

[PR #170] [MERGED] Dev #patch #357