Devices randomly get wrong subnet IP address - FW382.1.2

[1976saint]

Hi All

After a month or so of upgrading my RT-AX58U has started dishing out 192.168.0.x addresses (or something has) and not the configured 192.168.1.x :-(

Here is a log capture of a PS5 trying to get a new IP (last lines show it's MAC and a 0.103 address) - this isn't specific to this device as anything can get a wrong address. My only resolution is either multiple reboots of the device and or reboot router which sometimes resolves it! But today as I couldn't get the PS5 to connect in any shape or form I reinstalled the firmware. After a few router reboots it eventually got a good address.

Is this a bug in 386.1.2 or can someone see something else I might need to investigate.

Thanks All.


SPT=45977 DPT=7340 SEQ=1856932281 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000

Mar 27 23:10:31 wlceventd: wlceventd_proc_event(469): eth5: Deauth_ind 38:8B:59:54:C2:9F, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)

Mar 27 23:10:31 hostapd: eth5: STA 38:8b:59:54:c2:9f IEEE 802.11: disassociated

Mar 27 23:10:32 wlceventd: wlceventd_proc_event(505): eth6: Auth 38:8B:59:54:C2:9F, status: Successful (0)

Mar 27 23:10:32 wlceventd: wlceventd_proc_event(534): eth6: Assoc 38:8B:59:54:C2:9F, status: Successful (0)

Mar 27 23:10:32 hostapd: eth6: STA 38:8b:59:54:c2:9f IEEE 802.11: associated

Mar 27 23:10:32 kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set

Mar 27 23:10:32 hostapd: eth5: STA 38:8b:59:54:c2:9f IEEE 802.11: disassociated

Mar 27 23:10:32 wlceventd: wlceventd_proc_event(486): eth5: Disassoc 38:8B:59:54:C2:9F, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)

Mar 27 23:10:32 hostapd: eth6: STA 38:8b:59:54:c2:9f RADIUS: starting accounting session 42DE38D8F7CBA69A

Mar 27 23:10:32 hostapd: eth6: STA 38:8b:59:54:c2:9f WPA: pairwise key handshake completed (RSN)

Mar 27 23:10:32 dnsmasq-dhcp[24049]: DHCPREQUEST(br0) 192.168.1.214 38:8b:59:54:c2:9f

Mar 27 23:10:32 dnsmasq-dhcp[24049]: DHCPACK(br0) 192.168.1.214 38:8b:59:54:c2:9f Google-Home-Mini

Mar 27 23:10:32 kernel: 38:8B:59:54:C2:9F not mesh client, can't update it's ip

Mar 27 23:10:32 kernel: 4865C:01:83 not mesh client, can't update it's ip

Mar 27 23:10:32 kernel: 04:95:E6:C3:9A:28 not mesh client, can't update it's ip

Mar 27 23:10:35 wlceventd: wlceventd_proc_event(534): eth6: Assoc 1C:98:C1:2E:ED:4C, status: Successful (0)

Mar 27 23:10:35 hostapd: eth6: STA 1c:98:c1:2e:ed:4c IEEE 802.11: associated

Mar 27 23:10:35 kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set

Mar 27 23:10:35 hostapd: eth6: STA 1c:98:c1:2e:ed:4c RADIUS: starting accounting session 925D82E340B24EC8

Mar 27 23:10:35 hostapd: eth6: STA 1c:98:c1:2e:ed:4c WPA: pairwise key handshake completed (RSN)

Mar 27 23:10:39 dnsmasq-dhcp[24049]: DHCPDISCOVER(br0) 192.168.0.103 1c:98:c1:2e:ed:4c

Mar 27 23:10:39 dnsmasq-dhcp[24049]: DHCPOFFER(br0) 192.168.1.143 1c:98:c1:2e:ed:4c

Mar 27 23:10:39 dnsmasq-dhcp[24049]: DHCPREQUEST(br0) 192.168.0.103 1c:98:c1:2e:ed:4c

Mar 27 23:10:39 dnsmasq-dhcp[24049]: DHCPNAK(br0) 192.168.0.103 1c:98:c1:2e:ed:4c wrong server-ID

 

[john9527]

After a month or so of upgrading my RT-AX58U has started dishing out 192.168.0.x addresses (or something has) and not the configured 192.168.1.x :-(

It's not the AX58U, it's the PS5 asking for the the 192.168.0.x address.....the router just says no, you can't have it.

Mar 27 23:10:39 dnsmasq-dhcp[24049]: DHCPDISCOVER(br0) 192.168.0.103 1c:98:c1:2e:ed:4c == PS5 to router, anybody have 192.168.0.103
Mar 27 23:10:39 dnsmasq-dhcp[24049]: DHCPOFFER(br0) 192.168.1.143 1c:98:c1:2e:ed:4c == router to PS5r....you can have 192.168.1.143
Mar 27 23:10:39 dnsmasq-dhcp[24049]: DHCPREQUEST(br0) 192.168.0.103 1c:98:c1:2e:ed:4c == PS5 to router, I want 192.168.0.103
Mar 27 23:10:39 dnsmasq-dhcp[24049]: DHCPNAK(br0) 192.168.0.103 1c:98:c1:2e:ed:4c wrong server-ID == router to PS5...NO, not available here

Check you don't have another DHCP server on the network...a new NAS or switch for example or that you haven't set a static address on the PS5.

 

[ColinTaylor]

You said in one of your other posts that you had a Tenda mesh system attached to your network. That has its own DHCP server.

 

[1976saint]

gives me something to go on, thanks. As mentioned I do have the Tenda mesh set-up and I checked all the nodes and they all have .1 addresses, it is running in bridge mode and I don't see any options in this mode for DHCP, other wifi devices listed as connected to it have .1 addresses, I assumed the tenda would not be interfering?

I have a new HUmax Aura TV box bit again looking at the config on this it doesnt have a DHCP server setting anywhere I can see - this is the only thing introduced recently. Difficult to say if it started when this was connected (wifi).

No static address on Ps5 confirmed (DHCP selected) and nor configured on the router either. But on the network map devices screen I do see a whole bunch of devices with the static tag (inc. PS5) but it definatley isn't assigned a static.

 

[1976saint]

So I eventtually got around to rebooting all devices I could think of that had the ability to accept/send a DHCP request and when I power cycled one of my TPLINK TL-WA890EA (v1) units the issue stopped.

N600 Universal Dual Band WiFi Entertainment Adapter with 4 Ports

N600 Universal Dual Band WiFi Entertainment Adapter with 4 Ports

www.tp-link.com

When I logged in to it the configuration looked fine so I can only put it down to "computers eh!"

On the router log I'm nolonger seeing any addresses with .0 being requested so I consider it fixed.

Thanks to pointing me in the right direction, it helped immensity.

 

[john9527]

According to the manual, that device is configured by default as a DHCP server......you need to manually disable it. (section 4.4.4)

Tp-Link Tp-Link-Tl-Wa890Ea-Users-Manual- Tp-link-tl-wa890ea-users-manual

: Tp-Link Tp-Link-Tl-Wa890Ea-Users-Manual-167393 tp-link-tl-wa890ea-users-manual-167393 tp-link pdf

usermanual.wiki

 

[1976saint]

It was disabled already "computers eh!" must have been a glitch or similar and a reboot fixed it.