NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
andrew_z
Mar 10, 2026Aspirant
RAXE300 serving DHCP despite AP mode
tl;dr: I have the RAXE300 in AP mode, but it's suddenly serving DHCP. I've had a Netgear Nighthawk RAXE300 (6E) since August 2024, and I always used it in access point mode. My LAN is 10.0.x.x...
andrew_z
Mar 10, 2026Aspirant
Not seeing 192.168.1.x in your TCPDump.
Yes. I'm not an expert here, but I wonder if it would get filtered. The tcpdump was from OpenWRT, while the DHCP response only needs to go between the AP and the Client over Wi-Fi. (DHCP response isn't needed on the wired network.)
I'll try tcpdump on my desktop (wifi).
Finding anything else if you disconnect the RAXE from the system temporarily?
Disabling RAXE would remove most of the devices from the LAN, including my desktop that I use to SSH to OpenWRT. I would like to save this after ruling out some other things.
Is the RS router in AP mode actually? Check the WEB UI.
The Netgear Nighthawk is in AP mode in its Web UI.
Try setting a static AP mode configuration as seen here on the RS Router:
I checked my settings many times and may not have found the fixed IP. When I open that screen, I see it set to AP mode. However, there's no options. I had to switch it to Router Mode, then back to AP Mode, and then it showed the Fixed IP settings. I enabled Fixed IP---thank you.
I'm optimistic this could help. A pattern I saw in tcpdump was the Netgear making DHCP requests every two seconds for crazy lease time 1077411840, while DHCP server responds with 14400 (4 hours).
The address below 10.0.6.21 is a new dynamic address that showed up a few days ago because of the Nightgear's second MAC ..8C:AC is fixed 10.0.4.42, while ...8C:AD is dynamic 10.0.6.21.
12:41:33.900740 br-lan B IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 34:98:b5:72:8c:ad, length 300, xid 0x3a97fa5a, Flags [none] (0x0000)
Client-Ethernet-Address 34:98:b5:72:8c:ad
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
Hostname (12), length 7: "RAXE300"
Requested-IP (50), length 4: 10.0.6.21
Lease-Time (51), length 4: 1077411840
Parameter-Request (55), length 6:
Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
Domain-Name (15), BR (28)
END (255), length 0
PAD (0), length 0, occurs 27
12:41:33.902031 br-lan Out IP (tos 0xc0, ttl 64, id 56155, offset 0, flags [none], proto UDP (17), length 329)
10.0.0.1.67 > 10.0.6.21.68: [bad udp cksum 0x1b5c -> 0xf1a8!] BOOTP/DHCP, Reply, length 301, xid 0x3a97fa5a, Flags [none] (0x0000)
Your-IP 10.0.6.21
Server-IP 10.0.0.1
Client-Ethernet-Address 34:98:b5:72:8c:ad
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Offer
Server-ID (54), length 4: 10.0.0.1
Lease-Time (51), length 4: 14400
RN (58), length 4: 7200
RB (59), length 4: 12600
Subnet-Mask (1), length 4: 255.255.224.0
BR (28), length 4: 10.0.31.255
Default-Gateway (3), length 4: 10.0.0.1
Domain-Name (15), length 3: "lan"
Domain-Name-Server (6), length 8: 10.0.0.1,10.0.0.1
END (255), length 0
FURRYe38
Mar 11, 2026Guru - Experienced User
What IP address did you use for the Static IP address for the AP mode configuration on the RAXE?
You might turn OFF the RAXE and then run another check to see if those 10.x IP addresses are still seen.
Wondering if those IP addresses are passing thru the RAXE and getting masked there actual MACs by the RAXE MAC address.
We've seen odd behaviors with DHCP requests on various products. However in AP mode, shouldn't really be any since the router portion of the RAXE is disabled while in AP mode. Could be some odd behavior though.
- andrew_zMar 11, 2026Aspirant
What IP address did you use for the Static IP address for the AP mode configuration on the RAXE?
10.0.4.42
For almost two years, it was reserved DHCP, and then I used the same IP as static (typed into Netgear Web UI). Since I switched to static IP, everything is better. No more DHCP requests from ...8C:AD. No more rogue DHCP replies.
BTW, I forgot to mention when this issue first started on Sunday , the ...8C:AD MAC showed up with dynamic IP 10.0.6.21 and hostname "rax30", so it called itself RAX3, which was unexpected. However, the tcpdump shows RAXE300, which is expected.