0

I'm using a 3B running Raspian Buster, 5.10.17-v7+. It is running in a specialty device that goes with a telescope setup to track weather. On the telescope is a router with one SSID, let's call it "T".

When I have it near the house there is also a home network, let's call it "H", and sometimes the telescope AP is not even up.

I have it set with equal (i.e. none specified) priority for both H and T. It can connect to both, and if there's a large difference in signal (or one is down) it connects properly to the stronger.

However, multiple times now, when I have nearly the same signal strength, it connects to H, then after maybe a minute switches to T, then after another minute or two switches to H. I know because I'm SSH'd in, and get kicked off about the time I get to my 2nd or 3rd command. I have also set up pings to each address (different subnets by the way) and can see it switching there. No, the rPi did not reboot during this switch (it was recently booted but only once).

This so far has only happened when both signals are VERY strong, like a few feet from the AP's when I have the gear in storage. The AP is seeing signal of -35dbm give or take, so nothing marginal at all.

The AP for each is up, was up for days before and after, there's no race conditionin bringing up the AP. I have no idea why it switches. After this back and forth once it appears to "stick", it only does it initially (and not every time then).

I am reluctant to put in a priority, as do not want it to grab a really weak signal from either; grabbing the stronger signal is a good thing. But I thought once it associated, it stuck.

I have not yet found any messages (e.g. dmesg) as to why it is changing. I may not be looking in the right places.

Is there anything to do to make it more sticky, or to find out what's driving it to flap back and forth like this?

Linwood

Per a comment here is the supplicant data sans password and ssid:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=US
network={
  ssid="T"
  psk="TPWD"
}

network={
  ssid="H"
  psk="HPWD"
}

Per request dhcpcd logs. I munged the V6 addresses as I think some of mine are public, also replaced SSID's to conform to the above. This test was done by powering up the access point "T". It is about 2' from the rPi. The more powerful router R is about 13' away so they are probably similar signal strength. Notice it connected to the "T" briefly -- and I had pings running to both, I got about 40 pings (at 1/s) before it switched to "H". Please note when this started it was associated with "H".

May 21 16:40:56 raspberrypi dhcpcd[418]: wlan0: Router Advertisement from fe80::24f5:xxxx:xxxx:1f0b
May 21 16:43:19 raspberrypi dhcpcd[418]: wlan0: Router Advertisement from fe80::24f5:xxxx:xxxx:1f0b
May 21 16:44:50 raspberrypi dhcpcd[418]: wlan0: Router Advertisement from fe80::24f5:xxxx:xxxx:1f0b
May 21 16:49:05 raspberrypi dhcpcd[418]: wlan0: Router Advertisement from fe80::24f5:xxxx:xxxx:1f0b
May 21 16:49:18 raspberrypi dhcpcd[418]: wlan0: Router Advertisement from fe80::24f5:xxxx:xxxx:1f0b
May 21 16:50:22 raspberrypi dhcpcd[418]: wlan0: carrier lost
May 21 16:50:22 raspberrypi dhcpcd[418]: wlan0: deleting address 2601:6c1:xxxx:xxxx:43a:9a69:xxxx:xxxx/64
May 21 16:50:22 raspberrypi dhcpcd[418]: wlan0: deleting address fd5c:xxxx:xxxx:0:9657:4d47:xxxx:xxxx/64
May 21 16:50:22 raspberrypi dhcpcd[418]: wlan0: deleting route to fd5c:xxxx:xxxx::/64
May 21 16:50:22 raspberrypi dhcpcd[418]: wlan0: deleting route to 2601:6c1:xxxx:xxxx::/64
May 21 16:50:22 raspberrypi dhcpcd[418]: wlan0: deleting default route via fe80::24f5:xxxx:xxxx:1f0b
May 21 16:50:22 raspberrypi dhcpcd[418]: wlan0: deleting address fe80::xxxx:xxxx:3912:9330
May 21 16:50:22 raspberrypi dhcpcd[418]: wlan0: deleting route to 192.168.130.0/24
May 21 16:50:22 raspberrypi dhcpcd[418]: wlan0: deleting default route via 192.168.130.1
May 21 16:50:22 raspberrypi dhcpcd[418]: wlan0: carrier acquired
May 21 16:50:22 raspberrypi dhcpcd[418]: wlan0: connected to Access Point `T'   <<<<<<<<<<<<<<<<<  This is when the telescope came back up
May 21 16:50:22 raspberrypi dhcpcd[418]: wlan0: IAID eb:e0:01:f9
May 21 16:50:22 raspberrypi dhcpcd[418]: wlan0: adding address fe80::xxxx:xxxx:e1ba:da8e
May 21 16:50:23 raspberrypi dhcpcd[418]: wlan0: soliciting a DHCP lease
May 21 16:50:23 raspberrypi dhcpcd[418]: wlan0: soliciting an IPv6 router
May 21 16:50:26 raspberrypi dhcpcd[418]: wlan0: offered 192.168.135.3 from 192.168.135.1
May 21 16:50:26 raspberrypi dhcpcd[418]: wlan0: probing address 192.168.135.3/24
May 21 16:50:31 raspberrypi dhcpcd[418]: wlan0: leased 192.168.135.3 for 600 seconds
May 21 16:50:31 raspberrypi dhcpcd[418]: wlan0: adding route to 192.168.135.0/24
May 21 16:50:31 raspberrypi dhcpcd[418]: wlan0: adding default route via 192.168.135.1
May 21 16:50:45 raspberrypi dhcpcd[418]: wlan0: no IPv6 Routers available
May 21 16:51:22 raspberrypi dhcpcd[418]: wlan0: carrier lost
May 21 16:51:22 raspberrypi dhcpcd[418]: wlan0: deleting address fe80::xxxx:xxxx:e1ba:da8e
May 21 16:51:22 raspberrypi dhcpcd[418]: wlan0: deleting route to 192.168.135.0/24
May 21 16:51:22 raspberrypi dhcpcd[418]: wlan0: deleting default route via 192.168.135.1
May 21 16:51:23 raspberrypi dhcpcd[418]: wlan0: carrier acquired
May 21 16:51:23 raspberrypi dhcpcd[418]: wlan0: connected to Access Point `H'    <<<<<<<<<<<<<<<<<<<<<<< For reasons unclear it switched back
May 21 16:51:23 raspberrypi dhcpcd[418]: wlan0: IAID eb:e0:01:f9
May 21 16:51:23 raspberrypi dhcpcd[418]: wlan0: adding address fe80::xxxx:xxxx:3912:9330
May 21 16:51:23 raspberrypi dhcpcd[418]: wlan0: rebinding lease of 192.168.130.234
May 21 16:51:23 raspberrypi dhcpcd[418]: wlan0: probing address 192.168.130.234/24
May 21 16:51:23 raspberrypi dhcpcd[418]: wlan0: soliciting an IPv6 router
May 21 16:51:28 raspberrypi dhcpcd[418]: wlan0: leased 192.168.130.234 for 86400 seconds
May 21 16:51:28 raspberrypi dhcpcd[418]: wlan0: adding route to 192.168.130.0/24
May 21 16:51:28 raspberrypi dhcpcd[418]: wlan0: adding default route via 192.168.130.1
May 21 16:51:33 raspberrypi dhcpcd[418]: wlan0: Router Advertisement from fe80::24f5:xxxx:xxxx:1f0b
May 21 16:51:33 raspberrypi dhcpcd[418]: wlan0: adding address 2601:6c1:xxxx:xxxx:43a:9a69:xxxx:xxxx/64
May 21 16:51:33 raspberrypi dhcpcd[418]: wlan0: adding address fd5c:xxxx:xxxx:0:9657:4d47:xxxx:xxxx/64
May 21 16:51:33 raspberrypi dhcpcd[418]: wlan0: adding route to 2601:6c1:xxxx:xxxx::/64
May 21 16:51:33 raspberrypi dhcpcd[418]: wlan0: adding route to fd5c:xxxx:xxxx::/64
May 21 16:51:33 raspberrypi dhcpcd[418]: wlan0: soliciting a DHCPv6 lease
May 21 16:51:33 raspberrypi dhcpcd[418]: wlan0: adding default route via fe80::24f5:xxxx:xxxx:1f0b
May 21 16:51:34 raspberrypi dhcpcd[418]: wlan0: DHCPv6 REPLY: No Addresses Available
May 21 16:51:35 raspberrypi dhcpcd[418]: wlan0: DHCPv6 REPLY: No Addresses Available
May 21 16:51:37 raspberrypi dhcpcd[418]: wlan0: DHCPv6 REPLY: No Addresses Available
May 21 16:51:42 raspberrypi dhcpcd[418]: wlan0: DHCPv6 REPLY: No Addresses Available
May 21 16:51:50 raspberrypi dhcpcd[418]: wlan0: DHCPv6 REPLY: No Addresses Available
May 21 16:52:07 raspberrypi dhcpcd[418]: wlan0: DHCPv6 REPLY: No Addresses Available
May 21 16:52:07 raspberrypi dhcpcd[418]: wlan0: Router Advertisement from fe80::24f5:xxxx:xxxx:1f0b

Once it flaps once or twice it seems to then stay there. I have not seen it change spontaneously without a reboot of something.

Postscript 5/22/2021 0114UTC: I checked the router logs on both sides of the last flip-flop. This one went back and forth twice before settling, but did it at 60 second intervals (+/- 1s). On the "H" side (running OpenWRT) it shows disassociation due to inactivity (not true, I was running continuous pings):

Sat May 22 01:06:57 2021 daemon.info hostapd: wlan1: STA b8:27:eb:e0:01:f9 IEEE 802.11: authenticated
Sat May 22 01:06:57 2021 daemon.info hostapd: wlan1: STA b8:27:eb:e0:01:f9 IEEE 802.11: associated (aid 1)
Sat May 22 01:06:57 2021 daemon.notice hostapd: wlan1: AP-STA-CONNECTED b8:27:eb:e0:01:f9
Sat May 22 01:06:57 2021 daemon.info hostapd: wlan1: STA b8:27:eb:e0:01:f9 WPA: pairwise key handshake completed (RSN)
Sat May 22 01:06:58 2021 daemon.info dnsmasq-dhcp[19611]: DHCPREQUEST(br-lan) 192.168.130.234 b8:27:eb:e0:01:f9
Sat May 22 01:06:58 2021 daemon.info dnsmasq-dhcp[19611]: DHCPACK(br-lan) 192.168.130.234 b8:27:eb:e0:01:f9 RebootTElescopeWeather
Sat May 22 01:07:56 2021 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED b8:27:eb:e0:01:f9
Sat May 22 01:07:56 2021 daemon.info hostapd: wlan1: STA b8:27:eb:e0:01:f9 IEEE 802.11: disassociated
Sat May 22 01:07:57 2021 daemon.info hostapd: wlan1: STA b8:27:eb:e0:01:f9 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

On the other AP (RouterOS) at the same second it simply says (at 1:07:57)

B8:27:EB:E0:01:F9@T: connected, signal strength -33

When it left "T" one minute earlier it said:

B8:27:EB:E0:01:F9@T: disconnected, received disassoc: sending station leaving (8)

Which on the face of it sounds like the rPi decided it wanted to leave and sent a disassoc. That this happens at even 1 minute intervals seems beyond coincidence, I just do not know what it means. Again, once settled (this time after two round trips), it never dropped again.

Update: 5/23/2021 - I was incorrect about it being stable once settled, today while using it it continually flip-flopped back and forth. As a test, I moved the rPi further away, this set the signal from "T" as much lower than "H". It connected to "H" on reboot and stayed there and never changed. It appears this is occurring only when both signals are exceptionally strong (like -35db). Also worth noting, I have put separate devices (cell phone, laptops) on both H and T and neither of them move back and forth, all pick one and stick (when in the high signal, near equal signal area). It's just the rPi that is flapping.

5
  • 1
    You have provided ABSOLUTELY NO details of what you did to set it up or configuration, no evidence of problem etc. so how do you expect anyone to know?
    – Milliways
    May 20 at 22:36
  • I'm not sure what info is useful to you, it's a vanilla setup, but I can put the wpa_supplicant.conf file contents in the posting (and will). otherwise I put the hardware and O/S specific versions, and the scenario. As to "evidence of problem" I gather you think I am mistaken in my clearly stated observation?
    – Linwood
    May 21 at 1:18
  • What does systemctl status dhcpcd show?
    – Milliways
    May 21 at 7:35
  • Thank you, I had not known of that, most helpful -- well, in showing it; I did not learn why from it, perhaps something will jump out at you.
    – Linwood
    May 21 at 16:06
  • At this point I am giving up. I set up my system in the back yard last night, and despite being physically closest to the AP near it, it grabbed the other for some reason (it is amore powerful AP), which gave it a different IP (long story why). I'm just going to configure it only for the when-live AP and give up on having a backup link (other than a wire). If someone comes along with a prioritization technique please post.
    – Linwood
    Aug 8 at 17:46
0

Your description is not what normally happens with the Raspberry Pi or dhcpcd, which retain the last connected AP.

In fact the log does explain what is happening.

May 21 16:50:22 raspberrypi dhcpcd[418]: wlan0: carrier acquired
May 21 16:50:22 raspberrypi dhcpcd[418]: wlan0: connected to Access Point `T'

May 21 16:51:22 raspberrypi dhcpcd[418]: wlan0: carrier lost

May 21 16:51:23 raspberrypi dhcpcd[418]: wlan0: carrier acquired
May 21 16:51:23 raspberrypi dhcpcd[418]: wlan0: connected to Access Point `H'

The connection was established at 16:50:22 and carrier lost at 16:51:22 whereupon it tried the other interface.

I am surprised it happened so quickly, my expectation is that this should take 5 minutes.

# The station can associate again with the AP if it is still in range;
# this inactivity poll is just used as a nicer way of verifying
# inactivity; i.e., client will not report broken connection because
# disassociation frame is not sent immediately without first polling
# the STA with a data frame.
# default: 300 (i.e., 5 minutes)
#ap_max_inactivity=300

This indicates some problem external to the Pi.
It is possible there is interference between the AP (are they on the same channel?) or that the AP is actually going down.
Even if on different channels there is potential interference because channels overlap.

Whatever the cause, it is unlikely to be the Pi (although I have occasionally experienced problems with very strong signals).

2
  • The T is channel 1 at 2.4ghz, the H has channels 11 and 36, so they shouldn't interfere with each other. T was only associating with that one device (different SSID for special purposes). It's a Mikortik running routeros by the way. If you notice, both said "carrier lost". There's no way both had separate problems a minute apart. H in particular, it has dozens of devices and continuous monitoring with Zabbix. Also, I was rewiring the 12V on the telescope and moved things around -- now I cannot make it flap, it sticks to "T". I think I was somehow right on the cusp of equal signals before?
    – Linwood
    May 22 at 1:02
  • Correction, it just did it again after a reboot (of the rPi only). It went to H, then T, then H then back to T. The log showed "Carrier lost" each time. What's beyond suspicious is each "lost" was exactly 60 seconds apart (journalctl showing only seconds precision). Afterwards it stayed on T. I checked T's log and it said "received disassoc, sending station leaving" indicating that the rPi decided to leave, I think. Postscript: Found a clue in the "H" log, will post above).
    – Linwood
    May 22 at 1:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.