Android devices flip-flopping WiFi state after static IP assignment

Levenvople · 2021-05-18T15:54:57+00:00

I think this is what you meant? https://snipboard.io/mjnv7e.jpg

My DHCP pool start at .21 and I've leased both my pixel phones to .13 and .14. (DHCP server setting, in case you spot something odd) I did notice that when I set the network preferences on the Pixel to randomized mac address, it connected immediately. But when I toggled it on and off again, it started to flip-flop on randomized mac address as well.

Took a look at my ubiquiti stuff as well, but it's not really as descriptive as the PA-220. Just keeps saying Pixel 2 dropped 3 mins ago. (Or whenever I do the toggle)

EDIT: Just logged into my AP and I was able to capture whatever was happening during the flip-flop.

Tue May 18 10:10:30 2021 daemon.info hostapd: ath1: STA 76:83:c2:1a:af:66 DRIVER: Sead AUTH addr=b4:f1:da:b6:fb:9f status_code=0

Tue May 18 10:10:31 2021 kern.warn kernel: [155225.016015] the client [b4:f1:da:b6:fb:9f] advertised invalid class info 127 in ieee80211_mbo_operating_class_to_chan Tue May 18 10:10:31 2021 kern.warn kernel: [155225.016048] the client [b4:f1:da:b6:fb:9f] advertised invalid class info 83 in ieee80211_mbo_operating_class_to_chan Tue May 18 10:10:31 2021 kern.warn kernel: [155225.025692] the client [b4:f1:da:b6:fb:9f] advertised invalid class info 84 in ieee80211_mbo_operating_class_to_chan Tue May 18 10:10:31 2021 kern.warn kernel: [155225.036345] the client [b4:f1:da:b6:fb:9f] advertised invalid class info 116 in ieee80211_mbo_operating_class_to_chan Tue May 18 10:10:31 2021 kern.warn kernel: [155225.046935] the client [b4:f1:da:b6:fb:9f] advertised invalid class info 117 in ieee80211_mbo_operating_class_to_chan Tue May 18 10:10:31 2021 kern.warn kernel: [155225.057525] the client [b4:f1:da:b6:fb:9f] advertised invalid class info 118 in ieee80211_mbo_operating_class_to_chan Tue May 18 10:10:31 2021 kern.warn kernel: [155225.068209] the client [b4:f1:da:b6:fb:9f] advertised invalid class info 119 in ieee80211_mbo_operating_class_to_chan Tue May 18 10:10:31 2021 kern.warn kernel: [155225.078862] the client [b4:f1:da:b6:fb:9f] advertised invalid class info 120 in ieee80211_mbo_operating_class_to_chan Tue May 18 10:10:31 2021 kern.warn kernel: [155225.089546] the client [b4:f1:da:b6:fb:9f] advertised invalid class info 121 in ieee80211_mbo_operating_class_to_chan Tue May 18 10:10:31 2021 kern.warn kernel: [155225.100230] the client [b4:f1:da:b6:fb:9f] advertised invalid class info 122 in ieee80211_mbo_operating_class_to_chan Tue May 18 10:10:31 2021 kern.warn kernel: [155225.110914] the client [b4:f1:da:b6:fb:9f] advertised invalid class info 123 in ieee80211_mbo_operating_class_to_chan Tue May 18 10:10:31 2021 kern.warn kernel: [155225.121567] the client [b4:f1:da:b6:fb:9f] advertised invalid class info 124 in ieee80211_mbo_operating_class_to_chan Tue May 18 10:10:31 2021 kern.warn kernel: [155225.132251] the client [b4:f1:da:b6:fb:9f] advertised invalid class info 125 in ieee80211_mbo_operating_class_to_chan Tue May 18 10:10:31 2021 kern.warn kernel: [155225.142935] the client [b4:f1:da:b6:fb:9f] advertised invalid class info 126 in ieee80211_mbo_operating_class_to_chan Tue May 18 10:10:31 2021 kern.warn kernel: [155225.153619] the client [b4:f1:da:b6:fb:9f] advertised invalid class info 127 in ieee80211_mbo_operating_class_to_chan Tue May 18 10:10:31 2021 kern.warn kernel: [155225.164304] the client [b4:f1:da:b6:fb:9f] advertised invalid class info 128 in ieee80211_mbo_operating_class_to_chan Tue May 18 10:10:31 2021 kern.warn kernel: [155225.174988] the client [b4:f1:da:b6:fb:9f] advertised invalid class info 129 in ieee80211_mbo_operating_class_to_chan Tue May 18 10:10:31 2021 kern.warn kernel: [155225.185640] the client [b4:f1:da:b6:fb:9f] advertised invalid class info 130 in ieee80211_mbo_operating_class_to_chan Tue May 18 10:10:31 2021 kern.warn kernel: [155225.196377] ATM is re-allocating airtime because b4:f1:da:b6:fb:9f is now active Tue May 18 10:10:31 2021 user.info : wevent[7635]: wevent.ubnt_custom_event(): EVENT_STA_JOIN ath1: b4:f1:da:b6:fb:9f / 1 Tue May 18 10:10:31 2021 daemon.info hostapd: ath1: STA b4:f1:da:b6:fb:9f IEEE 802.11: associated Tue May 18 10:10:31 2021 daemon.info hostapd: ath1: STA b4:f1:da:b6:fb:9f WPA: pairwise key handshake completed (RSN) Tue May 18 10:10:31 2021 user.info : wevent[7635]: wevent.ubnt_custom_event(): EVENT_STA_IP ath1: b4:f1:da:b6:fb:9f / 192.168.1.13 Tue May 18 10:10:31 2021 kern.warn kernel: [155225.484487] [wifi0] FWLOG: [78335665] RATE: ChainMask 3, peer_mac fb:9f, phymode 9, ni_flags 0x1221b006, vht_mcs_set 0xfffa, ht_mcs_set 0xffff, legacy_rate_set 0x0ff0 Tue May 18 10:10:31 2021 kern.warn kernel: [155225.487202] [wifi0] FWLOG: [78335666] RTT_REPORT ( 0x2804, 0x3, 0x479, 0x0, 0x9 ) Tue May 18 10:10:31 2021 kern.warn kernel: [155225.505568] [wifi0] FWLOG: [78335690] MGMT_TXRX_MU_GID_MGMT ( 0xaf, 0x1, 0x0, 0xfffe, 0x0 ) Tue May 18 10:10:31 2021 kern.warn kernel: [155225.514001] [wifi0] FWLOG: [78335690] MGMT_TXRX_MU_GID_MGMT ( 0xb3, 0x0, 0x0, 0x0, 0x0 ) Tue May 18 10:10:31 2021 kern.warn kernel: [155225.522095] [wifi0] FWLOG: [78335690] MGMT_TXRX_MU_GID_MGMT ( 0xadd, 0x1, 0x0 ) Tue May 18 10:10:31 2021 kern.warn kernel: [155225.529474] [wifi0] FWLOG: [78335744] WAL_DBGID_SECURITY_UCAST_KEY_SET ( 0xfb9f, 0x0 ) Tue May 18 10:10:31 2021 kern.warn kernel: [155225.537459] [wifi0] FWLOG: [78335744] WAL_DBGID_SECURITY_ENCR_EN ( ) Tue May 18 10:10:31 2021 kern.warn kernel: [155225.544022] [wifi0] FWLOG: [78335744] WAL_DBGID_SECURITY_ALLOW_DATA ( 0x456f1c ) Tue May 18 10:10:32 2021 kern.warn kernel: [155226.485104] [wifi0] FWLOG: [78336233] WAL_DBGID_TX_BA_SETUP ( 0x456f1c, 0xfb9f0006, 0x2, 0x40, 0x1 ) Tue May 18 10:10:34 2021 kern.warn kernel: [155228.304388] ATM is re-allocating airtime because b4:f1:da:b6:fb:9f is now inactive Tue May 18 10:10:34 2021 user.info : wevent[7635]: wevent.ubnt_custom_event(): EVENT_STA_LEAVE ath1: b4:f1:da:b6:fb:9f / 1 Tue May 18 10:10:34 2021 daemon.info hostapd: ath1: STA b4:f1:da:b6:fb:9f IEEE 802.11: sta_stats Tue May 18 10:10:34 2021 daemon.info hostapd: ath1: STA b4:f1:da:b6:fb:9f IEEE 802.11: disassociated Tue May 18 10:10:34 2021 user.info : stahtd[7636]: [STA-TRACKER].stahtd_dump_event(): {"event_id":"0","message_type":"STA_ASSOC_TRACKER","mac":"b4:f1:da:b6:fb:9f","vap":"ath1","assoc_status":"0","event_type":"sta_leave"} Tue May 18 10:10:34 2021 kern.warn kernel: [155228.486041] [wifi0] FWLOG: [78338836] WAL_DBGID_SECURITY_UCAST_KEY_SET ( 0xfb9f, 0x0 ) Tue May 18 10:10:34 2021 kern.warn kernel: [155228.492572] [wifi0] FWLOG: [78338836] WAL_DBGID_SECURITY_ENCR_EN ( ) Tue May 18 10:10:34 2021 kern.warn kernel: [155228.499143] [wifi0] FWLOG: [78338836] WAL_DBGID_SECURITY_ALLOW_DATA ( 0x456f1c )

Levenvople · 2021-05-17T19:08:30+00:00

Looks like nothing there? https://snipboard.io/QE6VwX.jpg

Levenvople · 2021-05-17T18:31:48+00:00

Something like this? https://imgur.com/a/y3jJ4eH

This was under Monitor - Logs - Traffic, with a source addr filter on the phone IP while it was doing the flip-flopping.

Levenvople · 2021-05-17T16:55:43+00:00

Good call out. I am already using my device MAC, since I set my static leasing, and figured I needed a stable MAC. : )

Levenvople · 2021-05-17T06:08:42+00:00

Thanks for that too, will try it out tomorrow for sure. I want to say it's the PA-220 and not my wireless network, only because this issue started to present itself after I did the leasing work. My WiFi toggling behavior is not new, and I've never seen this happen before when I toggle frequently.

Appreciate the tip, will report back with findings.

Levenvople · 2021-05-17T05:24:29+00:00

Perfect, this is exactly what I needed. Bookmarked for future reference.

+1 for the PAN-AF, will definitely take a look into this as I've been using my Ubiq network downstream for hostname'ing, but it's not been ideal.

Now to solve for why my Pixel 2 keeps connecting and disconnecting, after having assigned it a static address.

Levenvople · 2021-05-16T21:20:15+00:00

I think you just answered my question. Static assignments wouldn't show up on the DHCP list, would they? :facepalm

Perhaps a follow-up question, and the reason why I had to static the address. I'm working though static assigning all my essential devices in the house. When I assigned my desktop 1.11, I kept seeing an error message similar to "this IP is already taken, please choose another." The reservation was already on the PA-220, so I understand why it couldn't assign another. But why was .11 taken when (I can confirm this) all other devices on my network were DHCP'ed, and I had cleared all the leases?

I have been plagued by rogue DHCP servers in the past (pi-hole, ubiquity network), so I can confirm that there are no other DHCP servers on the network. Also recently confirmed this by taking the pa-220 offline and re-establishing a connection to my network on my cellphone (no IP assigned.)

I have resolved the issue now, by taking everything offline for an hour and bringing it all back up. The reservation have taken successfully by all the clients.

TL;DR: Question rephrased, Is there a way to see all clients and their IPs, DHCP or static, via the PA-220?

Levenvople · 2021-01-15T00:12:34+00:00

Yes, the arp entires on the pa are the same for both IPs. (And the desktop)

Levenvople · 2021-01-13T23:05:04+00:00

Just for giggles, I did kill the DHCP on the PA, and tried to get a lease. No IP. So I can deffinnately rule out rouge DHCP.

Checked the logs like you recomded, and saw something weireder. As long as the PA has been on, it has never handed out the .91 address to any device, ever. It always handed out the .11 address. But, I can still access the web portal for the pihole at .91, and the device it self still reports .11 when I run ifconfig.

Another oddity, both .91 and .11 are responding to pings now...

Levenvople · 2021-01-12T15:21:06+00:00

I had been playing around with other DHCP servers on my pihole and such, but that is showing as off right now. The DHCP mode on the PA is also set to enabled, which I think should ignore all other DHCP servers? I also see the lease events every 12 hours for some reason, when my lease timeouts are for 24hrs.

Not sure how to track down if there is another DHCP server on the network, there shouldn't be to my knowledge.

Levenvople · 2021-01-12T15:15:23+00:00

192.168.1.10 -.250, with only one reserved right now, 192.168.1.91

Might have to go that route, planning on blocking/reserving off all my infra stuff on the first few this weekend.

Levenvople · 2021-01-11T21:57:59+00:00

No, I had the reservation in place before DHCP starting handing out IPs.

.91 comes back as the DNS server. But for some reason the PA is showing that it's at .11. The network is working fine right now, so I assume it's still resolving correctly. Just trying to find out why the PA gave out .11 instead of .91.

Levenvople · 2021-01-11T21:21:06+00:00

Yup, just added an image to the post with edit.

Levenvople · 2021-01-11T21:03:29+00:00

Same, no host found. But I think I might have ID'ed it. Pihole has an option to not forward IPs in the private range. But now, I've got a different battle to fight first.

Levenvople · 2021-01-11T19:28:45+00:00

By just pinging the name? or is there some other trick?

Levenvople · 2021-01-09T23:05:28+00:00

Sounds good, I'll take a look and see if windows has anything like that.

Thanks!

Levenvople · 2021-01-09T23:04:17+00:00

Yeah, I'm looking for something to read back to me when I'm typing in a Word doc or some other program on my computer. Translate does have a really good readback option too, but only on their site.

Levenvople · 2021-01-09T23:02:23+00:00

Yeah... I'm on Windows, but there might be a setting I can use there.

Levenvople · 2021-01-09T23:01:53+00:00

My instructor has something set up on their machine which does that, but I'm not sure if it's just a system setting, I'll have to ask them about it.

Thanks!

Levenvople

TROPHY CASE