I’ve been adding FreeRTOS + TCP to my FreeRTOS project. I was able to get everything working in a test environment using a laptop as a DHCP server. I was able to run an FTP server and I tested a UDP connection. I am now trying to connect to a larger university network and I am not getting any reply when I send a DHCP discover message. I’m not sure what the difference could be, I cannot access any network traces as I don’t have access.
Another note about my setup. When debugging initially, I found I needed to set ipconfigPACKET_FILLER_SIZE to 0 in order to read the correct IP address.
Other then that everything is from the example: FreeRTOS_Plus_TCP_and_FAT_ATSAME4E
More details:
Using a SAME70 Xplained board
Using FreeRTOS Kernel V10.0.0
Using FreeRTOS+TCP Labs Build 160919
I’m using a unique MAC address from an on board chip so I don’t think the MAC address is the problem.
Any suggestions what I could do to get this running would be greatly appreciated.
I’m happy to provide more detail if needed.
Check your discover packet, is the UDP checksum present? I found that I had to set checksum options to 0 for my LPC17xx port. If there is no checksum, then some ( most? ) DHCP servers will ignore the packet.
/* The checksums will be checked and calculated by the STM32F4x ETH peripheral. */
#define ipconfigDRIVER_INCLUDED_TX_IP_CHECKSUM ( 0 )
#define ipconfigDRIVER_INCLUDED_RX_IP_CHECKSUM ( 0 )
Thanks for the suggestion! I did initially have a problem with the checksum when testing with DHCP server running on a laptop, that has been fixed now tho. Still not getting any DHCP reply when connecting to the university network. Any other suggestions?
Is everyone allowed to connect to that network and get a DHCP address?
It would be interesting to see a DHCP conversation that is successful and compare it with the embedded request.
On AWS/FreeRTOS Github, you’ll find an easy-to-use demo project under pc. If you are able to run that on the campus, you can see with WireShark the DHCP conversation.
Yes everyone is allowed to connect to the network and get a DHCP address.
I was able to run that demo project. There was still no response. I have attached two captures with the different requests. It looks like there are some different options.
The only surprising thing that I see is the padding byte in the end, in FreeRTOS_xxx.pcapng
It has a ( random ) value of 0x38, where I would expect 0x00.
The driver sends one byte too many, please change the following line in FreeRTOS_dhcp.c :
This line occurs two times, in prvSendDHCPRequest(), and in prvSendDHCPDiscover(). Please change them both.
The driver sends 1 byte too many because the first option byte is counted twice: both in the struct DHCPMessage_t, as well as in the const arrays ( ucDHCPRequestOptions and ucDHCPDiscoverOptions ).
Beside the above, when you use a fixed IP-address, can you communicate to other devices / laptops?
I turned the above change into a pull-request on github, because I believe that the length of the packet is 1 byte too long.
I am not sure if this solves you problem, I hope so.
That did remove the last (random) byte, now there is no padding.
I have since contacted the administrators for the network and it was rejecting the mac address. I have this figured out now and can get a DHCP IP address.
Thanks for your help Hein, it’s much appreciated!
