DHCP issues with TP-Link AX5400 VX420-G2v

[rossack]

My Mongoose client is running on a PicoW (MG_ENABLE_TCPIP 1), based on the tutorials->http->device-dashboard example and not using Mongoose Wizard. The device is having trouble with DHCP DORA handshake on one particular router (TP-Link AX5400 VX420-G2v). It works perfectly fine with three other routers I have tried and the same device worked using different software built on LWIP stack.

Observations using Wireshark, Mongoose debug output and router logs.

• The client issues two DHCP DISCOVER messages which are 1 second apart.
• On the first DISCOVER, the router broadcasts an ARP request to check if the IP address is in use.
• When the client sends the second DHCP REQUEST it gets an immediate OFFER followed by the client REQUEST, but in most cases the final ACK is not received.
• The OFFER is always sent after the second REQUEST.
• Same behavior for dynamic and static IP assignment.
• The main loop consists of a single line: mg_mgr_poll(&mgr, 10).
• The device is listed in the router LAN Client list but with a blank IP address, although about 1 in 10 attempts the ACK is received and IP address allocated.

I suspect the DISCOVER retry may be happening too soon for the router's state machine which is waiting for any ARP responses and then gets confused and drops the ACK and doesn't bother with a NACK.

Can I increase the DISCOVER retry interval? If I change mg_timer_expired(&ifp->timer_1000ms, 1000, now) will it cause other problems?

I don't have easy access to this router, so I thought I would ask this question in case I'm on the wrong track.

[cookesan]

Since the same PicoW build works on other routers, I would first compare the failing router's DHCPOFFER against the fields Mongoose actually requires before it sends the REQUEST.

In the current built-in DHCP client, Mongoose sends DISCOVER once per second while the interface is in MG_TCPIP_STATE_UP. The DISCOVER is minimal: message type plus parameter request list for subnet mask and router. On receive, rx_dhcp_client() only accepts an OFFER when all of these are true:

msgtype == 2
state == MG_TCPIP_STATE_UP
yiaddr is non-zero
router/gateway option is present
lease-time option is present

If one router sends an OFFER without option 3 (router) or option 51 (lease time), or with a transaction ID that does not match Mongoose's MAC-derived xid, Mongoose will ignore it and keep sending DISCOVER. That would look exactly like "DISCOVER, DISCOVER, no REQUEST" from the router side.

The useful trace for the issue is the full OFFER options from the bad router versus a working router. If the bad OFFER has yiaddr but no router/lease option, it is probably a compatibility issue between that router's DHCP response and Mongoose's stricter acceptance check.

[rossack]

Hi, thanks for your suggestions. I can confirm:

1. The XID is unchanged across the 2x DISCOVERs, OFFER and REQUEST frames.
2. The router issues the ARP after the first DISCOVER, then always responds with the OFFER on the second DISCOVER.
3. I will check the options in the OFFER, but I'm sure Mongoose is happy with them, as it responds with the REQUEST.
4. Mongoose options in the REQUEST frame look ok, here is a debug output with options hexdump:
   ed5 3 mongoose.c:5362:tx_dhcp_discov DHCP discover sent. Our MAC: 2c:cf:67:98:40:6b
12bd 3 mongoose.c:5362:tx_dhcp_discov DHCP discover sent. Our MAC: 2c:cf:67:98:40:6b
12c2 3 mongoose.c:5501:rx_dhcp_client DHCPOFFER received, offer IP: 192.168.1.145
12c4 3 mongoose.c:5339:tx_dhcp_reques DHCP req sent for 192.168.1.145 from 192.168.1.1
0000 35 01 03 36 04 c0 a8 01 01 32 04 c0 a8 01 91 0c 5..6.....2......
0010 0e 50 69 63 6f 57 2d 34 46 35 41 43 30 32 46 37 .PicoW-4F5AC02F7
0020 02 01 03 ff ....
3958 1 mongoose.c:5918:get_return_l2a 192.168.1.125:58598 TCP: No way back, can't respond

About every 1 in 10 attempts establishes a successful connection, so I don't think options are bad. TP-Link doesn't have a great reputation for robust firmware so I'm assuming the router cant handle the second DISCOVER while its probing the network, then it gets the sulks and doesn't bother with the ACK frame. When I get a chance I will look at the router config to see if ARP checking can be disabled. Also, it's an ISP provided router, so it may have custom firmware(?),

On my network I scretched out the 1 second timer to 1.8 seconds and everything seems fine, but given other things rely on that timer I wanted to ask if there would not be any side affects.

PS: here is a sample of the router log file showing one successful connection with quite a few failed ones:
2026-04-21 17:39:03 [5] DHCPD: Recv DISCOVER from 2C:CF:67:98:40:6B
2026-04-21 17:39:03 [5] DHCPD: Send OFFER with ip 192.168.1.145
2026-04-21 17:39:03 [5] DHCPD: Recv REQUEST from 2C:CF:67:98:40:6B
2026-04-21 17:39:31 [5] DHCPD: Recv DISCOVER from 2C:CF:67:98:40:6B
2026-04-21 17:39:31 [5] DHCPD: Send OFFER with ip 192.168.1.145
2026-04-21 17:39:32 [5] DHCPD: Recv DISCOVER from 2C:CF:67:98:40:6B
2026-04-21 17:39:32 [5] DHCPD: Send OFFER with ip 192.168.1.145
2026-04-21 17:39:32 [5] DHCPD: Recv REQUEST from 2C:CF:67:98:40:6B
2026-04-21 17:39:32 [5] DHCPD: Send ACK to 192.168.1.145
2026-04-21 17:40:10 [5] DHCPD: Send OFFER with ip 192.168.1.145
2026-04-21 17:40:11 [5] DHCPD: Recv DISCOVER from 2C:CF:67:98:40:6B
2026-04-21 17:40:11 [5] DHCPD: Send OFFER with ip 192.168.1.145
2026-04-21 17:40:11 [5] DHCPD: Recv REQUEST from 2C:CF:67:98:40:6B

Interesting the log file doesnt show the first DHCP DISCOVER on each attempt

[scaprile]

@rossack Please attach a Wireshark capture, I can't follow a description of the traffic.
I know how Mongoose works and what it does, we only take offers that we can actually use, we're not a full-blown computer but a small embedded system. What I need to see is why the dialog with your DHCP server is not working. Please attach the requested sniff capture, we've already have issues with cheap boxes doing foul play.
Thank you.

PS: 1 sec should be enough, lots of stuff is linked to that, so I can't guarantee you won't mess up some other stuff if you change it. You with this server are the only one in all our user base having such an issue.
PS: ARP replies are usually faster than 1s. All I can suggest, if things happens as you describe, is that you add a "frequency divider" to the DHCP Request generation, that is, leave the timer as it is, but add a down counter to use 1 in 2, 1 in 4, whatever. This way you'll have retries every 2 or 4s (etc) instead of every 1s, and the rest of the stack works as expected.

[rossack]

See attached (XID=0x6798406b). Unfortunately I wasn't able to use monitor mode, so I don't see the unicast frames.
dhcpdebug-1.zip
Excellent suggestion re the down counter on the 1s timer, thankyou.

[scaprile]

See attached (XID=0x6798406b). Unfortunately I wasn't able to use monitor mode, so I don't see the unicast frames.

Yeah, I usually run Wireshark on the gateway itself... and have kept a pair of good old hubs for other cases... That log helps, I also run OpenWrt on my AP to catch other stuff with tcpdump, if that router is yours and you like to be in control, and there happens to be a port for it, that can be another option.
I can see what you described and seem to agree on what you infer.

Excellent suggestion re the down counter on the 1s timer, thankyou.

My pleasure, I don't think we'd be going to do that ourselves since yours is the only case, let us know if you need something else.

[rossack]

all good tips, thanks again. I wish I had kept my old dumb switches, but I do have a managed switch I can port mirror with. The misbehaving TP-Link router is not mine, it's my son's at his place across town. I will try the timing change on the tx_dhcp_discover(ifp) call and maybe let you know the result.

[rossack]

Hi Sergio,
I changed the retry time to 3 seconds - however, this did not solve the problem.
Looking at Wireshark, I notice that in addition to the router sending an ARP on the first DISCOVER, it also sends two ARP's when it receives the DHCP REQUEST (they have same timestamp). At this point, Mongoose is waiting for the DHCP ACK before assigning the IP address causing the router cancel the lease and drop the ACK. I checked my other routers and they don't send ARP requests until well after the ACK.

This router (TTP-Link VX420-G2v) appears to follow:

• Receive DHCP REQUEST:
• Immediately send two ARP's
• Then send ACK if ARP response, drop if not.

Can you confirm if Mongoose will respond to the ARP's in this instance? If so, maybe taking too long?

[rossack]

The modem has custom firmware provided by the ISP (iiNet), I will let them know about this.
As a quick test, can I just add to the end of tx_dhcp_request_sel() the line: ifp->ip = ip_req; ??
thanks again for your help on this.

[scaprile]

The stack is partially state-agnostic, the ARP section is dumb enough to be fooled into that:

mongoose/src/net_builtin.c

Lines 577 to 593 in 97c53ec

	static void rx_arp(struct mg_tcpip_if *ifp, struct pkt *pkt) {
	if (pkt->arp->op == mg_htons(1) && pkt->arp->tpa == ifp->ip) {
	// ARP request. Make a response, then send
	// MG_VERBOSE(("ARP req from %M", mg_print_ip4, &pkt->arp->spa));
	uint8_t *l2p = (uint8_t *) ifp->tx.buf;
	struct arp *arp = (struct arp *) mg_l2_header(
	ifp, MG_TCPIP_L2PROTO_ARP, ifp->mac, mg_l2_getaddr(ifp, pkt->l2), l2p);
	*arp = *pkt->arp;
	arp->op = mg_htons(2);
	memcpy(arp->tha, pkt->arp->sha, sizeof(pkt->arp->tha));
	memcpy(arp->sha, ifp->mac, sizeof(pkt->arp->sha));
	arp->tpa = pkt->arp->spa;
	arp->spa = ifp->ip;
	MG_DEBUG(("ARP: tell %M we're %M", mg_print_ip4, &arp->tpa, mg_print_mac,
	ifp->mac));
	driver_output(ifp, mg_l2_trailer(ifp, sizeof(*arp), (uint8_t *) (arp + 1)));
	} else if (pkt->arp->op == mg_htons(2)) {

so your workaround is likely to fool ARP into responding, and the IP section is stateless also, it should work.
The DHCP handshake should continue and eventually the proper state be reached and things go as expected.

In case it doesn't work, besides static IP, we have an example on how to do Auto-IP.

[scaprile]

No problem, nice to help when the counterpart knows what he's doing

[rossack]

I have sent iiNet support team describing this problem but not holding my breath for a solution.

• In case it doesn't work, besides static IP, we have an example on how to do Auto-IP.

Yes, I did think of just doing a self assigned IP address but that's a bandaid over the problem. I'm deep enough down the rabbit hole I might as well keep going.

I have changed the DHCP Flags field to Broadcast instead of Unicast, so now I will see all the DHCP datagrams. When I go back to the site I will do more packet capture and examine the Options used by other devices that successfully connect. I have a feeling this double ARP behaviour is triggered by something missing in the REQUEST Options.

PS: Great speaking to someone with deep knowledge of TCP/IP networking and Mongoose source code author.

[scaprile]

Cool, yeah, let's find out and fix if necessary. We usually don't go strict RFC but keep things simple, I remember enforcing some RFC stuff a couple of years ago due to issues with multiple DHCP server scenarios.
For now I'm assuming the router remembers the lease and tries to renew it, instead of assigning a new one; add to that the fact that it seems to want to avoid any statically configured hosts with addresses overlapping the DHCP-assigned range. Looks like the typical case of the "try to make it work for the dumb and end up breaking it for the savvy" culture, though yes, there can be something we missed or a different interpretation of the process.
Eagerly waiting

[rossack]

Reporting on progress, sorry this is long, but writing this down helps clarify my thinking.
Re your comments:

• I'm assuming the router remembers the lease and tries to renew it
  Even if I reboot the router?
• typical case of the "try to make it work for the dumb and end up breaking it for the savvy" culture
  Agree. I can understand that mentality, the router is for the home users who mostly have no idea what they are doing.

On with my report. Changes made:

• Removed the countdown timer to wait for 3 seconds before resending DISCOVER, put back to the original mg code.
• Added: ifp->ip = ip_req; at the end of tx_dhcp_request_sel() - a dodgy hack just to see what happens.
• Set bootp flags: Broadcast 0x8000

I tested this build on my home network and can see:
PicoW: DISCOVER
Router: ARP Who has 192.168.0.172? Tell 192.168.0.254
Router: OFFER (about 150ms later)
PicoW: Request
Router: ACK
Beautiful!! Just what I wanted to see.

Then I visited the rouge network. Result:

• Only one DHCP discover sent by the PicoW and the router responds with the OFFER within 100ms.
• This is followed by PicoW DHCP REQUEST
• Router ACK is still not received.
• No response to the router ARP request.

During my monitoring I noticed most other devices when joining the network perform INIT-REBOOT and just send REQUEST directly (no DISCOVER), so I forced my Google Pixel7 to rejoin the network to watch what it's doing:

• Pixel7: DHCP Discover
• Router: unicast-offer-not-captured
• Pixel7: DHCP Request IP: 192.168.1.110
• Router: unicast-ack-not captured
• Router: ARP Who has 192.168.1.110? Tell 192.168.1.1
• Pixel7: sent 2 additional REQUESTs

While I didn't see the ARP reply, the Pixel7 joined the network ok.
So:

• why now only a single DISCOVER and no initial ARP
• why did my Pixel7 succeed and PicoW fail?
  Comparing the REQUEST Options in both I notice the Pixel7 includes Option (61) Client Identifier and in PicoW it's missing. It's not mandatory, but (stab in the dark) I might try including it and see if any different.

I noticed there is 802.3 LLC control frame from the CYW43 sent before the initial DISCOVER but I assume this is ignored by the router and not related to the problem.
I noticed there is a device with a randomised mac address eth.addr == 9a:a2:f4:20:c7:fd doings lots of ARP's and it has two IP addresses - that's weird (malware?) but not related to the problem.

Wireshark snippet attached. PicoW eth.addr == 2c:cf:67:98:40:6b, Pixel7 eth.addr == ae:0d:77:e9:3e:18
dhcp7.zip

One other thing, the ISP provider have said they will look into this and get back to me - so maybe a chance they can help.
That's it for now.

[scaprile]

No problem with length, it is info.

• I'm assuming the router remembers the lease and tries to renew it
  Even if I reboot the router?

Well, usually servers have a /var/lib/dhcpd/dhcpd.leases or equivalent, leases must survive reboots as they're time dependent and there can be more than one server on a network
The only way to know for sure is to either wait for the lease time to expire or change to a new, unseen, MAC address; anything that triggers the creation of a new lease, instead of a possible renewal.

I'll check the rest later, thanks.

[scaprile]

It just dawned on me... are you using 7.21 or HEAD ? Because we fixed something that could somehow be related, though IIRC it shouldn't. Anyway, I should be able to see that when I take a detailed look at your traffic, though right now I'm a bit overwhelmed and that will happen in a not so short while.

[rossack]

Using 7.20. I noticed 7.21 a few weeks ago but haven't upgraded yet.
Also, in your article Raspberry Pi Pico-W meets Mongoose you show the idle loop includes a call to driver_pico_w_poll();
But I notice in version 7.20 the function mg_tcpip_driver_pico_w_poll() you have this line:
cyw43_arch_poll(); // not necessary, except when IRQs are disabled (OTA)

[scaprile]

I don't recognize 0x2E00 ethertype, and we're supposed to control (most of) what the CYW sends... maybe Pico-SDK is trying to outsmart someone, we use their driver, sadly.
Our code is for deeply embedded environments we only implement the most common and stable features, otherwise we'd end up with bloated code with lots of configuration options and there are lots of those around... so, our friend the RFC says that
INIT is the standard init, at least when you don't know what your IP was before. You DISCOVER, all available servers send you their leases, then you SELECT one of them and REQUEST that IP. https://datatracker.ietf.org/doc/html/rfc2131#section-4.4.1
INIT-REBOOT only applies when you already know your address https://datatracker.ietf.org/doc/html/rfc2131#section-4.4.2

If you don't see the ARP response, then the hack is not working, I fail to guess why.

One other thing you might try, is to actually send a random xid... In order not to waste space saving something that is only used once, we don't generate a random xid but use the MAC last 4 bytes

mongoose/src/net_builtin.c

Line 489 in c937144

memcpy(&dhcp.xid, ifp->mac + 2, sizeof(dhcp.xid));

The rx portion is then able to compare

mongoose/src/net_builtin.c

Line 657 in c937144

if (memcmp(&pkt->dhcp->xid, ifp->mac + 2, sizeof(pkt->dhcp->xid))) return;

to try that, you should replace the first line to generate a random uint32_t instead, and store it somewhere, then the second line should memcmp against where you stored it... something the likes of

mongoose/src/net_builtin.c

Line 2031 in c937144

mg_random(&ifp->eport, sizeof(ifp->eport)); // Random from 0 to 65535

We had a similar strategy for the ephemeral port base you see there, but for the sake of "security" we needed to add that. DHCP code is from that era, but it stayed as it was, as no server ever complained.
It wouldn't hurt to try... my interpretation of the RFC is not that any subsequent reboot must have a different xid, it only states that it must be different from any other client, hence our choice of the MAC last 4 bytes...

I was wrong, the RFC does mention ARP, though it says that it is the client that SHOULD check the server-assigned address is unique, not the server...

[rossack]

PS on my comment re my Pixel7 connecting to the network.
I said:

• Pixel7: sent 2 additional REQUESTs

That looks like the device failed the INIT attempt and continued with INIT-REBOOT attempts.

[rossack]

• I don't recognize 0x2E00 ethertype,
  Nor did I. ChatGPT tells me this is a: CYW43 (Broadcom) firmware event / control frame encapsulated as 802.3 + LLC/SNAP used internally by the Wi-Fi chip to signal link state changes, interface readiness...

• If you don't see the ARP response, then the hack is not working, I fail to guess why.
  I assumed the ARP response, if it is sent, is Unicast so my packet capture wont see it.

• One other thing you might try, is to actually send a random xid...
  That's a good idea, will do, thanks for the code suggestions. RFC says Selecting a new 'xid' for each retransmission is an implementation decision. A client may choose to reuse the same 'xid' or select a new 'xid' for each retransmitted message.
  Though in my most recent capture exercise the router was responding on the first DISCOVER. This wasn't happening previously, maybe something was cleared on rebooting the modem.

Also your comment re lease memory:

• Well, usually servers have a /var/lib/dhcpd/dhcpd.leases or equivalent, leases must survive reboots as they're time dependent and there can be more than one server on a network
  The PicoW board I'm using had a previous life on the same network using my poorly written software which used LWIP stack. It was located in an area where the WiFi signal was weak, but it did work - for a while. Then apparently it stopped working and that's when I decided to move to Mongoose especially because I could incorporate OTA updates. I didn't bother to investigate the reason back then. Now I'm wondering if the ISP has pushed a firmware update that's introduced this bug.

Should I upgrade to 7.21 or HEAD code?
PS: If/When we solve this I will owe you a beer :-)

[rossack]

Watching the PicoW connect to my network, I notice the following:
Wireshark capture sequence is:

• PicoW: DHCP Discover
• Router: ARP Who has 192.168.0.172? Tell 192.168.0.254
• Router: DHCP Offer 192.168.0.172
• PicoW: DHCP Request 192.168.0.172
• Router: DHCP Ack
• PicoW: Who has 192.168.0.254? Tell 192.168.0.172

I would expect the PicoW to respond to the ARP in sequence, but it doesn't.
Here is PicoW Debug output which contains MG_DEBUG statements on both ARP request and response in function rx_arp():

1e74 3 mongoose.c:5364:tx_dhcp_discov DHCP discover sent. Our MAC: 2c:cf:67:98:3a:c5
1f05 3 mongoose.c:5504:rx_dhcp_client DHCPOFFER received, offer IP: 192.168.0.172
1f07 3 mongoose.c:5340:tx_dhcp_reques DHCP request sent for 192.168.0.172 from 192.168.0.254
1f0e 3 mongoose.c:5509:rx_dhcp_client DHCPACK received, IP: 192.168.0.172
1f0f 2 mongoose.c:5513:rx_dhcp_client Lease: 4294967295 sec (4294974)
1f13 3 mongoose.c:5413:rx_arp ARP resp from 192.168.0.254

Weird that it didn't log the ARP Request which arrived just after 1e74, and the ARP response is sent after the ACK and it all works just fine.

The more I look at this the more I'm convinced the problem is not related to XID's, Options etc, it is the bad router unwilling to send the ACK until it gets an ARP response and the PicoW is unable to respond to the ARP until it gets the ACK. And, I think this behaviour was introduced in the latest OTA firmware update from the ISP some months ago (which Im currently following up with iiNet).

[scaprile]

Well, I'm not fond of ChatGPT and AIs in general, feel like using them takes the fun out of discovering stuff. That frame resembles some LLC after the proprietary ethertype, though.
You should perhaps wait and go for 7.22, we're close to release time.

WRT your last comment, remember Mongoose is a bit different.
For the sake of being able to work asap, we initially assume the router and DHCP server have the same IP, we can be corrected later, and we "proactively" try to get the router MAC as soon as we can, we don't work with an ARP cache. So, that ARP request you see is us trying to get the router MAC based on the assumption that is the same as the DHCP server.
Some other stacks may send it before, to get the server MAC, we cheat and get it from the Ethernet frame, hope you don't tell the ISO police about that.

The hacked ARP response won't be logged, I think, don't remember now but I think I saw that when checking the path for the hack.

WRT xid, my understanding of the word "retransmission" in that phrase is that applies to re-sends of the same datagram, not to new negotiations.

So, keep in touch.

WRT that beer... I don't think I'll go to Australia in this life, my aussie friend is now American and he lives in the US, so I'll keep listening to AC-DC, Madness, and of course Men at Work, though my closest approach to down under was dinner at Outback... Tried a Foster and liked it. Google me up and feel free to PM me, nice meeting you, g'donya mate.

[rossack]

• Well, I'm not fond of ChatGPT and AIs in general, ..
  My biggest concern is that AI tools are threatening the most valuable skill essential for this current generation, that is critical thinking. Kids don't need to think anymore, they have so much information blasted at them they dont get time to think.

• You should perhaps wait and go for 7.22, we're close to release time
  Great, I shall wait for 7.22 - thanks.

• WRT your last comment, remember Mongoose is a bit different
  Different yes, but it makes perfect sense to me, and works everywhere except this particular router. I'm still betting my beer on a bug in the router. I am still waiting for the ISP to get back to me.

While I've been waiting I also installed Linux Mint on my laptop so I can use my Panda WiFi adapter in monitor mode to capture 802.11 traffic. I can now see what the CYW43 driver is sending/receiving. I notice on my network the radio packets are quite different to the L2 Ethernet packets I have been monitoring. For example I see two DISCOVER packets on the air before the OFFER, REQUEST and final ACK and then another REQUEST appears. I do see the PicoW sending ARP to check the router address. Plenty of ACK's and Block ACK's in all this too.
I went to my son's place last night with great anticipation to do some packet captures but when I opened my laptop I had flat battery :-(

[scaprile]

• My biggest concern is that AI tools are threatening the most valuable skill essential for this current generation, that is critical thinking. Kids don't need to think anymore, they have so much information blasted at them they dont get time to think.

Exactly, that is mine too. Hopefully my kid is 29 and he's already had his attention span trashed, may his critical thinking survive... and in my case I just want to enjoy what I do. We're going way off-topic, I'll only add that my deepest learning was by investigating stuff when I had absolutely no information available, and every piece of it, gathered from some paragraph in some book or magazine, would make a difference and stay with me.

[rossack]

I got a reply from the ISP that supplies the modem. In response to what I have observed they said:

• this behaviour does suggest a potential firmware‑level issue with DHCP/ARP handling that may affect certain client implementations on this router model and firmware version. At this stage, we can confirm that firmware for iiNet‑supplied TP‑Link modems is centrally managed and cannot be manually downgraded or modified..... Please note that our support for the supplied modem is limited. While we can assist with ensuring the modem is connected to the internet and that devices are able to connect to the modem itself, we are not generally trained on all advanced features or settings of the modem, nor can we provide extensive support for device‑specific compatibility or configuration beyond basic connectivity....

They did suggest to disable features such as Smart Connect (band steering) and test using a dedicated 2.4 GHz SSID, so I will give that a go and see what happens.

Re our off topic conversation. I'm recently retired, but have taken up a new role as Chief Scientist to my grand children. My mission is to ensure these kids develop inquisitive minds and find out stuff on their own.

[scaprile]

ISP: they are clueless
Off-topic: Cool ! I played Jean Piaget to my kid (now 29). That's the coolest job for a grandpa.