DHCP offer not being accepted

Libraries
1

I’m working on my first IP enabled project/test using an STM32F769NI-Disco board. I’m using the latest FreeRTOS 202210 LTS release + TCP from the same package. I’ve manually added FreeRTOS to my project and verified it is working with SWO printf as well as the usually blinking LEDs. + TCP has also been added and it compiles and runs.

From Wireshark, I can see that it is requesting an IP address from the DHCP server and is using the correct hostname I have assigned to it. The DHCP server (WS 2019 DHCP) is responding nearly instantly with an IP address on the expected subnet with all the correct parameters.

Unfortunately, that is as far as the Disco gets. It never accepts the offer and instead, goes through the increasing delays before once again requesting an IP and then ignoring the offer once again. After DHCP times out, it assigns the default IP address I have set (again, with the correct subnet/mask/gateway) and calls it a day.

At this point, if ping the board, I get no response. I’ve tried this withe the DHCP and IP hooks enabled with the same (lack of) results.

I know the hardware itself works as I have successfully pinged the board using LWIP based test programs, both with and without DHCP. My gut tells me it is not “hearing” the offer (or anything else for that matter so it could be a sockets or even hardware configuration issue.

Where should I start looking first? SWO is working so I can get reliable output from the application to help with debugging.

Any help would be greatly appreciated.

2

You can use xApplicationDHCPHook to track and verify the DHCP processing to see what’s going on on the client side. See also the related TCP stack configuration ipconfigUSE_DHCP_HOOK.

3

lwip has different drivers. I suspect that your Rx side is broken and thus you do not see any packets at all. Can you set a breakpoint in the ethernet driver isr where an Rx packet is processed? If that reveals no in packets, the next step would be to take snapshots of the MCU SFRs after sytem setup (in particular, NVIC, DMA and Ethernet) for your lwip and FreeRTOS+ based software, respectively, and compare those against each other.

4

Thanks for the pointer RAc. I didn’t even think about comparing the two or checking the ISRs. Hopefully, I’ll be able to get back on this by Friday.

5

Just to add on top of the previous replies.
There can be 2 possibilities here:

  1. Issue in normal RX path
  2. Issue in DHCP path

To rule-out point 1, please disable the DHCP service initially and just try ping using static IPs. If this works, then issue is in the DHCP path , but if this does not work, then you know where to look. And already others have suggested good ways to step-in the RX path ISR, you can try the same.

6

And finally, it may be worth to check the declarations of the network buffers. In readme.md you find some text about the D-cache.

The buffers that are shared between the driver and DMA are all located in the data section .first_data like this:

/* Ethernet Rx MA Descriptor */
__attribute__( ( aligned( 32 ) ) )
    __attribute__( ( section( ".first_data" ) ) )
    ETH_DMADescTypeDef DMARxDscrTab[ ETH_RXBUFNB ];

It was called first_data because the first 64 KB of RAM are not cached.

Also see if the clocks are all enabled, and if the GPIO pins are configured correctly.

You can also disable D-cache, but that may heavily affect the performance.

1 Like
7

I did create the .first_data section in the linker script, but I will check to make sure I did it correctly and the correct attribute is attached to the buffers.

Thanks!

Clint

8

After DHCP times out, the static IP I define is attached (and reported out on SWO). Still no response to pint with that IP (or the one the DHCP server is TRYING to give it). Looks like my receive path is borked.

9

Yes, this confirms that something to do with the receive path. Please check the receive path ISR entry point.

10

Will do. And thanks for taking the time to help!

11

but I will check to make sure I did it correctly

A good way to check it is to inspect the LSS listing of the project. DMARxDscrTab should appear in the top of the 'data segment.

In case you didn’t know, you can create an LSS file as follows:

    arm-none-eabi-objdump -S RTOSDemo.elf > RTOSDemo.lss

Also, would it be possible to create a PCAP of the conversation and attach it in a ZIP file? You can filter by simply writing “dhcp” and press enter. And then “File-> Export specified packets”

12

Just getting started on reviewing this today. I’ll be off next week, so I will definitely put some some time into getting this working. DMARxDscrTab is at 0x20000000 followed by DMATxDscrTab at 0x20000080, first two items in memory, so it looks like I did get THAT correct…

Ok! Success! After reviewing the schematics vs. the HAL_ETH_MspInit function I had implemented, I was missing configuring the ETH_RX_ER pin. After fixing that, my board WOULD reply to a ping, but only the IP address I had setup in in case DHCP failed.

Fixing that was very quick: in xApplicationDHCPHook → eDHCPPhasePreRequest I was checking the offer subnet against the default subnet and then setting “eDHCPUseDefaults” if they matched. Not what I wanted to do… Setting that to “eDHCPContinue” fixed it and the board is now getting and using the DHCP address assigned by my DHCP server.

Thanks for the help everyone! It is greatly appreciated! Now on to NTP…

3 Likes
13

Hello @clcorbin, have you made any progress with the above issue?

Regards,