heinbali01 wrote on Sunday, October 14, 2018:
Hi Peter, that is an interesting observation.
…but Wireshark reports a problem with the Frame Check Sequence of the arp reply.
Ok
At some point, FreeRTOS-TCP sends a gratuitous arp, and after that the
PC is able to communicate with the embedded code.
Good. Sending gratuitous ARP’s has the advantage that double IP addresses can be discovered earlier, and also that your PC’s ARP- and routing-tables remain up to date.
I suspect that the PC is rejecting the ARP reply, due to the invalid checksum.
I have attached a screenshot of Wireshark, showing the incorrect arp reply.
There are 3 types of checksums, belonging to 3 layers:
- Protocol checksum, calculated by the IP-task or peripheral ( TCP or UDP layer )
- IP checksum, calculated by the IP-task or peripheral ( IP layer )
- Frame checksum, calculated by the Ethernet peripheral ( hardware layer )
The IP-stack is not responsible for the Frame checksum. I think there is a problem with the packet length: an ARP reply is normally 60 bytes long. In your case, the ARP reply is 64 bytes long, and the extra 4 bytes seem to have a random value. Those are interpreted as the Frame check-sum.
Normally the Ethernet peripheral makes sure that all packets have the required minimum length of 60 bytes ( excluding the frame checksum, which is not visible in Wireshark ).
If that doesn’t work, you can define in your FreeRTOSIPConfig.h:
#define ipconfigETHERNET_MINIMUM_PACKET_BYTES 60
Do you have ipconfigETHERNET_MINIMUM_PACKET_BYTES defined?
What hardware are you using?