SSIDs disappear when router reboots

Access Points
1

Have a concern/question about the ability of Alta APs to still provide internal wifi when the core internet router is having maintenance performed on it (i.e., firmware update, reboot, etc…)

Router = Netgate 6100 running pfSense
All Alta APs have static ip address defined, management vlan of ‘1’, fallback upon failure ‘off’, always on ‘enabled’, mesh ‘off’.

Upon reboot of router, all wired devices can still communicate if they are on vlan 1. I expect vlans other than 1 (which are created/originated on the router itself), to not work. Monitoring for the Alta APs (icmp reply) is still working and does not drop when the router reboots.

Upon reboot of router, Alta APs stop broadcasting wifi on all configured vlans, including an ssid configured on vlan 1 (within the ssid settings, default network vlan is ‘1’. By this, I mean if the router is rebooted, the ssids are no longer present on wifi client devices.

Should the APs still broadcast, at minimum, the ssid on vlan 1, since that is still present on the switch that is connected downstream of the router?

2

Hello :wave:

The AP’s should still broadcast yes, can you confirm the firmware version the APs are on? Can you see any errors on the AP at all when the router reboots? tail -f /var/log/messages

1 Like
3

@carrottspc Within the settings of each AP, there is a setting called “Always On”. If this is toggled to the “on” position, in the event the internet to your site goes down, the APs should continue to broadcast all of your SSIDs. If its toggled to the “off” position, if the APs see a loss of internet, they will stop broadcasting their SSIDs. Mind taking a look at that setting for the site in question for us?

Screenshot 2024-07-22 at 9.12.26 AM

4

It is set to always on, as I stated in my post. :slight_smile: Firmware is latest, but have seen this issue with previous versions as well. Figured might as well ask about it now while I’m thinking about it & encountered it again when I updated my router this weekend.

5

Next time you do a reboot or simulate one take a look at the logs and see if it points anything out :slight_smile:

6

@carrottspc Man, breezed right past that part in your post. My apologies. Thanks for the correction/clarification.

7

No worries Chase. Below are logs from an access point during a router reboot. Is this just the devices (in this case I’m watching from iPhone during router reboot) not able to ‘use’ internet over wifi and delcaring that since that path isn’t there, that that ssid doesn’t exist? Or is it something from the AP side?

[2024/07/23 05:14:02:3519] N: JSON: {“stats”:120}
[2024/07/23 05:14:02:3379] N: JSON: {“reqStats”:{“start”:1721729581,“stop”:1721729642,“period”:“seconds”,“clientId”:“avQqY03qX9hOraCbrFk2”}}
[2024/07/23 05:14:02:2971] N: JSON: {“stats”:120}
[2024/07/23 05:13:09:6896] N: JSON: {“reqStats”:{“start”:1721729528,“stop”:1721729589,“period”:“seconds”,“clientId”:“avQqY03qX9hOraCbrFk2”}}
[2024/07/23 05:13:09:2565] N: writing subscribe: site/kQbzBAIDlvx7v72WGU1Sm/ZFQR5iGEW7PX5QsTFGOXY
[2024/07/23 05:13:09:2558] N: writing subscribe: devs/kQbzBAIDlvx7v72WGU1Sm
[2024/07/23 05:13:09:0700] N: writing cfg 86aecda409122ddfd5400cac5a77232a
[2024/07/23 05:13:09:0692] N: writing subscribe: ZFQR5iGEW7PX5QsTFGOXY
[2024/07/23 05:13:08:9137] N: writing connect
[2024/07/23 05:13:08:9135] N: callback_unilever: established
[2024/07/23 05:13:08:7935] N: __lws_lc_tag: ++ [wsicli|0|WS/h1/default/manage.alta.inc] (1)
[2024/07/23 05:13:08:7929] N: fullpath: /mqtt
[2024/07/23 05:13:08:5683] N: __lws_lc_tag: ++ [vh|1|default||-1] (2)
[2024/07/23 05:13:08:5639] N: __lws_lc_tag: ++ [vh|0|netlink] (1)
[2024/07/23 05:13:08:5631] N: __lws_lc_tag: ++ [wsi|0|pipe] (1)
[2024/07/23 05:13:08:5620] N: lws_create_context: LWS: 4.3.3-2.0w, NET CLI H1 H2 WS ConMon IPV6-off
[2024/07/23 05:13:08:5605] N: /usr/lib/libwebsockets-evlib_uloop.so
[2024/07/23 05:13:08:5396] N: __lws_lc_untag: – [vh|1|default||-1] (0) 2.952d
[2024/07/23 05:13:08:5328] N: __lws_lc_untag: – [wsi|0|pipe] (0) 2.952d
[2024/07/23 05:13:08:4230] W: reg6 failed
Warn: curl -s … rc: 1792
run "curl -s -f -6 -m 7 -X POST https://manage.alta.inc/api/device/boot -o /var/run/boot.json -H ‘Content-Type: application/json’ -d '{ “id”: “bcb92300c460”, “model”: “1”, “version”: “2.0w”, “pubkey”: "AAAAB3NzaC1yc2EAAAADAQABAAABA
netd: cloudflare ret: 143
netd: Failed, failures: 4
netd: Failed, failures: 3
netd: Failed, failures: 2
run "curl -s -f -6 -m 7 -X POST https://manage.alta.inc/api/device/boot -o /var/run/boot.json -H ‘Content-Type: application/json’ -d '{ “id”: “bcb92300c460”, “model”: “1”, “version”: “2.0w”, “pubkey”: "AAAAB3NzaC1yc2EAAAADAQABAAABA
[2024/07/23 05:11:39:6544] W: reg4 failed
Warn: curl -s … rc: 1536
netd: Failed, failures: 1
netd: Next state: enet_normal
netd: cloudflare ret: 143
netd: Failed, failures: 10
run "curl -s -f -4 -m 7 -X POST https://manage.alta.inc/api/device/boot -o /var/run/boot.json -H ‘Content-Type: application/json’ -d '{ “id”: “bcb92300c460”, “model”: “1”, “version”: “2.0w”, “pubkey”: "AAAAB3NzaC1yc2EAAAADAQABAAABA
netd: Failed, failures: 9
netd: Failed, failures: 8
netd: Failed, failures: 7
netd: Failed, failures: 6
[2024/07/23 05:11:29:5770] W: reg6 failed
Warn: curl -s … rc: 1536
netd: Failed, failures: 5
netd: Failed, failures: 4
netd: Failed, failures: 3
netd: Failed, failures: 2
netd: Failed, failures: 1
run "curl -s -f -6 -m 7 -X POST https://manage.alta.inc/api/device/boot -o /var/run/boot.json -H ‘Content-Type: application/json’ -d '{ “id”: “bcb92300c460”, “model”: “1”, “version”: “2.0w”, “pubkey”: "AAAAB3NzaC1yc2EAAAADAQABAAABA
[2024/07/23 05:11:24:5393] W: reg4 failed
Warn: curl -s … rc: 1536
netd: Next state: enet_normal
netd: cloudflare ret: 143
netd: Failed, failures: 10
netd: Failed, failures: 9
run "curl -s -f -4 -m 7 -X POST https://manage.alta.inc/api/device/boot -o /var/run/boot.json -H ‘Content-Type: application/json’ -d '{ “id”: “bcb92300c460”, “model”: “1”, “version”: “2.0w”, “pubkey”: "AAAAB3NzaC1yc2EAAAADAQABAAABA
netd: Failed, failures: 8
[2024/07/23 05:11:18:6439] N: __lws_lc_untag: – [wsicli|4|WS/h1/default/manage.alta.inc] (0) 1.063d
[2024/07/23 05:11:18:6431] E: callback_unilever: connection attempts exhausted, waiting 849ms
[2024/07/23 05:11:18:6428] N: callback_unilever: closed
[2024/07/23 05:11:18:6426] E: Forcing disconnect!
[2024/07/23 05:11:18:6423] E: ping timed out. reconnecting…
netd: Failed, failures: 7
netd: Failed, failures: 6
netd: Failed, failures: 5
netd: Failed, failures: 4
netd: Failed, failures: 3
netd: Failed, failures: 2
netd: Failed, failures: 1

8

The logs shared so the management client unable to communicate with cloud management, and that the network is down, which I’d expect given that the gateway is down.

The quoted comment stands out to me. What device have you been checking other than your iPhone? Also, how are you checking whether it’s up or down on your iDevice? For example, with Wi-Fi Assist enabled (default is on), the Wi-Fi icon will always disappear from the status during router reboots, but that doesn’t mean that the network has stopped beaconing.

Outside of the above, can you please connect to one of the APs via shell and issue the following and share the output? ls /var/run/netd.*

If you haven’t setup SSH keys, you can also access shell from web management. Go to https://manage.alta.inc, click Network, and then Shift+Click on the text part of the name of the AP to open the web terminal.

9

@carrottspc I’ve tried to reproduce what you are seeing, and haven’t been able to so far. Can you submit full logs including the timestamp of when the router goes down?

Also if you are able to run this to see if beacons are going out, that would be helpful:

wifitelemetry -A -r -c -i “$VAP_NAME” | grep “Tx Beacon Count”

Replacing $VAP_NAME with the name of your VAP (you can find it with “iw dev” if you don’t know it).

10

@Alta-Chase @Alta-Jeff @Alta-MikeD Yes, main devices in hand are Apple iOS/iPAD OS devices. And it appears that the wifi assist is being the instigator there, causing the illusion that the SSIDs were not working. I verified correct ssid operation during time of router reboot/isp not available by working with non Apple devices during a reboot test this morning. As expected, those devices that were on vlan 1 continued to reply, while those on other vlans dropped icmp replies until the router reboot completed. All the while the SSIDs continued to broadcast as seen by Netspot. I should have been more thorough in my troubleshooting to begin with. Sorry about that.

2 Likes
11

Personally, I’d rather have you report something that may end up being a non-issue, than not reporting it at all. Software bugs are bugs, and while we strive not to introduce them, they can happen. Appreciate you taking the time to report this and the details shared. I’m glad it ended up being the simplest explanation.

1 Like