Messages

I'm not sure how you reached the conclusion that (OPN + EAP) is the problem combination.

With the problem only occurring at 6GHz, which OPN is completely unaware of, I would say the issue is (EAP + Phone) constrained.

Yes, that was what I thought so too, and it may still be the case, but what's thrown a wrench in that theory is that connecting the travel router in AP mode and its Wifi disabled (not double NATed, basically using it as a switch) between Opnsense and the EAP fixed the issue. I mean for all intents and purposes I could just call it a day and leave the router there, but it's bugging me not being able to fix this properly. There's something going on between Opnsense and the EAP773 that's messing with the 6GHz connection with just these Pixel phones, and *just* when the screen is off, that's what seems so weird to me.

It doesn't make sense that Opnsense could do something to affect only the 6GHz connection on a separate AP, but it's also very weird that putting a router in AP mode basically functioning as a switch fixes the issue. Tried a couple of unmanaged switches instead of the travel router and they don't fix the issue so the travel router is not being completely transparent as a normal switch when in AP mode even though Opnsense is still doing DHCP and all the devices in the subnet can communicate as usual.

Hi there, this is a strange issue. At first I blamed it on either the phones or the AP, but the way I worked around it seems like Opnsense might be interacting with this setup in a weird way. I'd like to get some ideas for what can be causing this.

My setup is:

Opnsense 25.1.6_4 on an Intel N200 firewall with 4 Intel I226-V 2.5Gbps ports.
Pixel 8 Pro and Pixel 9 Pro XL on Android 15 May update (latest).
Omada EAP773 WiFi 7 AP, set up separate SSID's for 2.4, 5 and 6 GHz bands. MLO is off for now. This is normally connected directly to the firewall on a separate port than the wired LAN, made a WLAN interface, then bridged to a LAN interface in Opnsense.

Both phones disconnect from the 6GHz AP after about 20 minutes with the screen off, but not while in use, so it pointed at some battery saving issue. Adaptive battery and Adaptive connectivity are turned off, and on Pixels there aren't any options to disconnect WiFi when the phone sleeps. Further, it doesn't happen on 2.4 and 5GHz. I've also tested in safe mode so no third party apps are active. I have also reset network and BT settings on the Pixels. I have a Samsung Tab S10+ and an iPad Mini 7 that behave without problem on 6 GHz as well.

So next was the AP. I tested 320, 160, and 80 MHz channel widths, and disabling 802.11be mode (just 802.11ax), and nothing made a difference. Also many different channels and disabling/enabling PSC channels didn't work. Pixels AFAICT only support WiFi 7 at 160MHz fwiw.

I then disconnected the AP from the firewall, and connected it to the first downstream 2.5GbE switch in the LAN which is unmanaged, but the same problem persisted.


So this is the workaround I found to my surprise:

I connected a GL.inet GL-MT3000 travel router to the LAN to create a double NAT, and connected the EAP773 to this router's LAN port on another subnet. The phones don't disconnect this way on 6 GHz. It seems like some setting on Opnsense might be triggering something on the EAP773 or the phones that make the phones disconnect when they're idle.

Further, then I enabled AP mode on the travel router and turned its wifi off, still using the EAP773 as the AP, so it's all now on the same subnet it originally was (basically using the router as a wired switch), but the problem is still fixed, so the double NAT itself wasn't what fixed it.

The travel router is somehow blocking whatever's causing the issue, and it appears to be an issue between Opnsense and the EAP773, that only affects Pixels on 6GHz.

On Opnsense, I'm using ISC DHCPv4, and I'd originally reserved IPs for these phones, but I've also tried forgetting them and making the FW assign IPs automatically, and also toggled on/off the static ARP for these phones. I don't know what else could be messing with the ability of the phones to stay connected when idle, specifically on 6 GHz. This is all very weird to me!

Any ideas to what I might test next?

Same issue here with dyndns and njalla.

But it seems like the problem has been fixed upstream and now we only have to wait until it makes its way to a release.

I don't know if it has been intentionally dropped but maybe the force update button would be nice to have in ddclient plugin as well for situations like these to test that the update has been done manually.

I got an update today to OPNsense 23.1_6 and os-ddclient 1.11_1 but it doesn't seem to be the fix. You can force update of ddclient via cron btw.

Seeing the same after the update to 23.1 on os-ddclient 3.10, using DuckDNS. The IPs do get updated properly on DuckDNS but since Opnsense doesn't think the IPs are updated, it updates the server every time, instead of checking the WAN first to see if the IP has changed, before forcing an update.

This is the log:

Code Select Expand

2023-01-27T09:22:31-08:00 Notice ddclient[25031] 58089 - [meta sequenceId="72"] FAILED: updating ********.duckdns.org: Server said: '0'
2023-01-27T09:22:31-08:00 Notice ddclient[25031] 57487 - [meta sequenceId="71"] RECEIVE:
2023-01-27T09:22:31-08:00 Notice ddclient[25031] 57126 - [meta sequenceId="70"] RECEIVE: 0
2023-01-27T09:22:31-08:00 Notice ddclient[25031] 56686 - [meta sequenceId="69"] RECEIVE: OK
2023-01-27T09:22:31-08:00 Notice ddclient[25031] 55957 - [meta sequenceId="68"] RECEIVE: 2
2023-01-27T09:22:31-08:00 Notice ddclient[25031] 55697 - [meta sequenceId="67"] RECEIVE:
2023-01-27T09:22:31-08:00 Notice ddclient[25031] 55234 - [meta sequenceId="66"] RECEIVE: X-Frame-Options: DENY
2023-01-27T09:22:31-08:00 Notice ddclient[25031] 54804 - [meta sequenceId="65"] RECEIVE: X-Clacks-Overhead: GNU Terry Pratchett
2023-01-27T09:22:31-08:00 Notice ddclient[25031] 54033 - [meta sequenceId="64"] RECEIVE: Server: nginx/1.20.0
2023-01-27T09:22:31-08:00 Notice ddclient[25031] 53564 - [meta sequenceId="63"] RECEIVE: Set-Cookie: AWSALBCORS=**************; Expires=Fri, 03 Feb 2023 17:22:31 GMT; Path=/; SameSite=None; Secure
2023-01-27T09:22:31-08:00 Notice ddclient[25031] 52923 - [meta sequenceId="62"] RECEIVE: Set-Cookie: AWSALB=************; Expires=Fri, 03 Feb 2023 17:22:31 GMT; Path=/
2023-01-27T09:22:31-08:00 Notice ddclient[25031] 52511 - [meta sequenceId="61"] RECEIVE: Connection: close
2023-01-27T09:22:31-08:00 Notice ddclient[25031] 51833 - [meta sequenceId="60"] RECEIVE: Transfer-Encoding: chunked
2023-01-27T09:22:31-08:00 Notice ddclient[25031] 51399 - [meta sequenceId="59"] RECEIVE: Date: Fri, 27 Jan 2023 17:22:31 GMT
2023-01-27T09:22:31-08:00 Notice ddclient[25031] 50596 - [meta sequenceId="58"] RECEIVE: HTTP/1.1 200 OK
2023-01-27T09:22:31-08:00 Notice ddclient[25031] 50352 - [meta sequenceId="57"] SENDING:
2023-01-27T09:22:31-08:00 Notice ddclient[25031] 50352 - [meta sequenceId="56"] SENDING: Connection: close
2023-01-27T09:22:31-08:00 Notice ddclient[25031] 50352 - [meta sequenceId="55"] SENDING: User-Agent: ddclient/3.10.0
2023-01-27T09:22:31-08:00 Notice ddclient[25031] 50352 - [meta sequenceId="54"] SENDING: Host: www.duckdns.org
2023-01-27T09:22:31-08:00 Notice ddclient[25031] 50352 - [meta sequenceId="53"] SENDING: GET /update?domains=*********.duckdns.org&token=*********&ip=***.***.***.*** HTTP/1.1
2023-01-27T09:22:31-08:00 Notice ddclient[25031] 49805 - [meta sequenceId="52"] CONNECTED: using SSL
2023-01-27T09:22:30-08:00 Notice ddclient[25031] 49352 - [meta sequenceId="51"] CONNECT: www.duckdns.org
2023-01-27T09:22:30-08:00 Notice ddclient[25031] 48890 - [meta sequenceId="50"] UPDATE: updating *********.duckdns.org
2023-01-27T09:22:30-08:00 Notice ddclient[25031] 48179 - [meta sequenceId="49"] INFO: setting IP address to ***.***.***.*** for *********.duckdns.org