DHCP reponse lost on AP Mode Flint AX1800 Firmware 4.8.3

Router
1

I have a AX1800 for almost more than a year and it had been working great.

I have it in AP mode, and my main router is another AX1800. I set both routers to the same SSID to allow for roaming. Both are using WPA2/WPA3 mixed mode on oth 2.4GHz and 5GHz.

I noticed that once upgraded to 4.8.3 on the AP, when switching from the router to the AP, connection will be lost on the connecting device. Based on logs and tcp dump, it seems that it has trouble getting DHCP:

Log on main router:

Sun Apr 26 14:20:43 2026 daemon.info dnsmasq-dhcp[11807]: DHCPDISCOVER(br-lan) 7a:94:42:62:18:43
Sun Apr 26 14:20:43 2026 daemon.info dnsmasq-dhcp[11807]: DHCPOFFER(br-lan) 192.168.8.49 7a:94:42:62:18:43
Sun Apr 26 14:20:47 2026 daemon.info dnsmasq-dhcp[11807]: DHCPDISCOVER(br-lan) 7a:94:42:62:18:43
Sun Apr 26 14:20:47 2026 daemon.info dnsmasq-dhcp[11807]: DHCPOFFER(br-lan) 192.168.8.49 7a:94:42:62:18:43
Sun Apr 26 14:20:48 2026 daemon.info hostapd: wlan1: STA cc:f4:11:af:a4:f9 IEEE 802.11: disconnected due to excessive missing ACKs
Sun Apr 26 14:20:48 2026 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED cc:f4:11:af:a4:f9
Sun Apr 26 14:20:49 2026 daemon.info dnsmasq-dhcp[11807]: DHCPDISCOVER(br-lan) cc:f4:11:af:a4:f9
Sun Apr 26 14:20:49 2026 daemon.info dnsmasq-dhcp[11807]: DHCPOFFER(br-lan) 192.168.118.47 cc:f4:11:af:a4:f9
Sun Apr 26 14:20:55 2026 daemon.info dnsmasq-dhcp[11807]: DHCPDISCOVER(br-lan) 7a:94:42:62:18:43
Sun Apr 26 14:20:55 2026 daemon.info dnsmasq-dhcp[11807]: DHCPOFFER(br-lan) 192.168.8.49 7a:94:42:62:18:43

tcpdump on device:

14:20:43.538694 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 7a:94:42:62:18:43, length 306
14:20:47.903799 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 7a:94:42:62:18:43, length 304
14:20:55.407905 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 7a:94:42:62:18:43, length 304
14:21:05.260312 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 7a:94:42:62:18:43, length 306

No logs show up on the AP itself.

Only after about 3-4mins, do I get a DHCPACK on the router and tcpdump will finally capture a DHCP response. The connection will work fine after that, but the same will happen after switching to the router and back the the AP again.

It seems like something is losing the DHCPOFFER sent by the main router.

This happens even with all default settings other than using Access Point Mode, WPA2+WPA3, and changing the SSID. Using only WPA2 also reproduces the problem.

Once downgraded to 4.6.8 everything works well again.

GL-ATX1800 Slate AX in Access Point mode fails to assign IP address with FW versions 4.8.2 and 4.8.3
2

Hi

Thanks for your report.

Could you please follow the guide and share both routers with us via GoodCloud so we can check it remotely?

Kindly note to send us the MAC address and the router password via private message so we can access it

image
image632×233 19.1 KB

4

Both are connected and DMed the details!

I kept the AP on 4.6.8 for now or my home setup would be sort of unusable, but upgrading to 4.8.3, both automatic and local upload upgrades reproduces it everytime.

5

In this case, it seems difficult to troubleshoot the issue remotely.

Could you help upgrade the firmware to 4.8.3 again, reproduce the issue and, on the AX1800 acting as an AP, capture packets on the following interfaces at the same time?

# Install the tcpdump
opkg update && opkg install tcpdump

# Uplink interface
tcpdump -i eth0 -n -e 'udp and (port 67 or port 68)' -w /tmp/eth0_dhcp.pcap 

# Wi-Fi interfaces
## 2.4 GHz
tcpdump -i wlan0 -n -e 'udp and (port 67 or port 68)' -w /tmp/wlan0_dhcp.pcap 

## 5 GHz
tcpdump -i wlan1 -n -e 'udp and (port 67 or port 68)' -w /tmp/wlan1_dhcp.pcap 

# Bridge interface
tcpdump -i br-lan -n -e 'udp and (port 67 or port 68)' -w /tmp/br_dhcp.pcap

After that, please export the logs from both the main router and the AP router, and send them to us via private message along with the packet captures.

6

I’m having the same problem with an AXT1800 Slate. I can see the DHCP responses leaving the upstream router but they are somehow being dropped at the AXT1800 and don’t reach the destination smartphone. The scenario is exactly as yours: trying to switch from the main router to the downstream AXT1800. After a few minutes, it finally connects. @will.qiu told me R&D is looking into it.

1 Like
7

Yea, I provided the packet captures and @will told me they’ll look into it.

1 Like
8

So while setting up the other part of my network I now realize I have the inverse problem.

My main router is on 4.8.3 and my access point is reverted to 4.6.8. Now, when I move from the access point to the router (instead of the other way round like above), I can’t ping the access point anymore. Basically the trend across the two is that when connected to the wifi on 4.8.3, it can’t reach the hosts connected via ethernet, in both AP and Router mode. After a few minutes it again recovers.

This fits the DHCP problem described above too, because from the AP’s wifi it can’t reach the router which is connected via ethernet.

With the tcpdump I see the ping request leaving both my wifi client and the router on br-lan, but no response is recorded. I was unable to tcpdump on my AP for now, but another host via ethernet seem to show the response being sent but never arriving on the router’s br-lan interface.

9

Hi

Please try upgrading the device to the following firmware to see whether the issue improves:

If you still encounter issues, please continue exporting the device logs and send them to us for further analysis.

Thank you for your patience and cooperation!

10

Just managed to get to this and seems like the link expired. Do you mind updating it or sending me another?

11

javier has already helped test this beta firmware, and it appears that the issue still exists. We have already asked the development team to continue analyzing the logs.

If there are any updates or progress, we will let you know.

12

I am having the exact same issue.

13

Hi,

We apologize for the inconvenience caused.

Our development team is still continuing to investigate this issue further.
If there are any updates, we will try to let you know.

For now, please temporarily downgrade to the v4.6.x firmware if you need to use AP mode.

15

Hi, just checking, did we ever get a resolution on this?

16

Hi,

Our team is still investigating this issue.

We are currently trying to adjust some low-level parts of the firmware, but have encountered some compilation issues.

We will let you know if there are any updates or progress.

17

Hi,

Sorry for the delayed reply. And thank you for your continued patience.

We recently resolved the compilation issues and are now able to provide a new debug firmware.

Please check your private messages—we've sent you the download link for the debug firmware.

Could you please test this version and let us know whether it resolves the AP mode instability you experienced previously?

Please note that, due to significant low-level changes, this firmware must be flashed via U-Boot. Please refer to the following guide:

Also, this firmware is intended for debugging purposes only. We have not yet completed full functional testing, so we recommend using it only temporarily. After testing, you may want to use U-Boot again to revert to the previous stable firmware.

Thank you again for your continued cooperation and patience.