RP2040 W5500 and DHCP about mongoose HOT 14 CLOSED

Thanks for the explanation. It has helped my understanding a great deal.

from mongoose.

I have tested it just now and it works perfectly. Thanks!

from mongoose.

Good idea. In fact, our usual hexdump can be happily swallowed by Wireshark - I did that many times. Maybe just add hexdumps with MG_LL_VERBOSE ? It should not be very noisy, cause the IP is not configured at that stage anyway.

from mongoose.

Please do not paste screen captures, I need to see a Wireshark capture file to be able to guess what is going on in your network.
Please post a capture file of the traffic when your device is starting up and requesting an IP address, and the corresponding Mongoose log dump.
Out of curiosity, just in case, please write down your gateway brand name and model.

from mongoose.

Hopefully this is what you need. The router is a TPLink Deco M9.
Wireshark capture files and Mongoose log dump.zip

from mongoose.

You need to capture in a place where the traffic can be actually seen, and be kind not to include irrelevant traffic.
If your device MAC is 5a:38:83:2e:25:36, then use a capture filter for that.
You need suitable networking tools to do networking development, you need either a switch with monitor capability or a hub or a gateway that can run Wireshark or at least tcpdump, in order to be able to get the device traffic.
In your capture I see the device sends a DHCP Discovery, I don't see the answer because probably you captured in some random computer and some random switch in the middle of your network won't forward to that port any non-broadcast traffic that is not destined for that computer.
In your capture I see the device later sends a DHCP Request, I don't see the answer (same reason).
For some reason that I can't see (same reason), server id is not set in that request, and it should.
I can't see if your DHCP server never answers or our stack can't handle what it receives, all I see is that it stays in Req state, so probably your DHCP server never answers.

from mongoose.

Thanks for the advice. Unfortunately, it seems I don't have the right equipment.

Nevertheless, it seems odd that I can flash exactly the same hardware with firmware using an alternative TCPIP stack, attached to the same network cable, switch, router etc., and the whole DHCP process works fine: on debug I can see the Discover, Offer, Request and Acknowledgement packets and the process is practically instant.

from mongoose.

What is weird to me is that you are the only one having an issue like this, I offered my help to find the reason and if it turns out to be our problem, fix it. I can't do that if I don't see what is on the net. We could add extra debugging to make Mongoose log everything it sees, but that takes a lot of time.
Try to get that info and I will gladly work on it. Please reopen the issue when you have it. Regards.

from mongoose.

I appreciate the offer of help, I really do. I can also understand my problem seeming weird to you, for sure! I will see if I can find some proper network hardware to get the information requested.

Nonetheless, I noticed in a verbose debug log from rx_ip() that the packet received immediately after the DHCP request was sent contained my router IP address, but pkt->dhcp->siaddr which is passed to rx_dhcp_request_sel() was set to 0. It turns out that if I change line 4880 in rx_dhcp_client() from:

tx_dhcp_request_sel(ifp, ip, pkt->dhcp->siaddr);

to:

tx_dhcp_request_sel(ifp, ip, pkt->ip->src);

then DHCP allocation works. Maybe my router is sending back a packet with information missing that you expected to be present? Or maybe what I have done above is inappropriate for reasons I don't understand?

from mongoose.

Protocols should stay within their layer of incumbency, at least in theory.
A DHCP request takes the server IP address from that announced inside the DHCP datagram. If I understand you correctly, your DHCP server is not filling that.
The comment in that line is a reference to the section in the RFC named above, which reads:

If the parameters are acceptable, the client records the address of
the server that supplied the parameters from the 'server identifier'
field and sends that address in the 'server identifier' field of a
DHCPREQUEST broadcast message.

So, if that is correct, technically your gateway is not playing fair.
What we could do is a fallback like you did, something like:

  // select IP, (4.4.1) (fallback to IP source addr on foul play)
  tx_dhcp_request_sel(ifp, ip, pkt->dhcp->siaddr ? pkt->dhcp->siaddr : pkt->ip->src);

from mongoose.

tx_dhcp_request_sel(ifp, ip, pkt->ip->src);

then DHCP allocation works. Maybe my router is sending back a packet with information missing that you expected to be present? Or maybe what I have done above is inappropriate for reasons I don't understand?

This is perhaps the issue, thank you Sam!

Sergio, your fallback logic seems good, could you please send a PR

from mongoose.

Sure, I was waiting for the OP to test it as all our DHCP servers play nice.

from mongoose.

@sas229 Sam, your efforts are much appreciated!

from mongoose.

@cpq Should we add a minimum functionality tcpdump-like to be enabled on cases like this ? Only dump our frames and those for us, but do it in a way that can later be opened with Wireshark. Easily enabled with an allegoric macro like MG_TCPDUMP. Except for old and bald salty dogs, no one is expected to have a hub and getting device traffic becomes hard for most people.

from mongoose.