I am running a TCP client under Qemu, specifically using the implementation from the mps2 demo. As an echo server I am running ncat on a different linux machine.
The problem that I am facing is that the client is not recognizing the SYN ACK messages from the server, thus it continuously tries to initiate a connection, I am attaching the output from wireshark.
client: 131.230.193.1239
server: 10.88.58.107
By stepping through the code, I saw that xProcessReceivedTCPPacket is only called from the client before sending an RST,ACK.
Also, I couldn’t find prvTCPHandleState being called, even though I compiled with DEBUG=1.
Is there something further I can check to understand why the client is not processing the SYN,ACK messages?
While debugging, I noticed that from the client side, the connections get the following states:
eCLOSED->eCONNECT_SYN->eCLOSE_WAIT.
Does a normal ping work well, both from client to server (FreeRTOS_SendPingRequest()) and from server to client?
Note that for ping to work in 2 directions, you will need to define:
The combination of IP-addresses look a bit strange to me:
client: 131.230.193.129
server: 10.88.58.107
The client has a public IP-address, whereas the server has a local IP-address. I wonder if the routing works well in two directions with this combination?
thanks for the suggestions. I tried pinging from both directions:
when the client sends a ping, the server receives it and replies.
when I ping from the server, the client does not reply (I have defined the macros accordingly).
I set the server to a public-IP (same subnet with the client) as well and observe the same behavior. The server sends SYN, ACK but the client never changes state. I thought that maybe there is an issue with the network interface virtualization, I will look into that, but any other suggestions are more than welcome.
I have noticed also that before the client sends a TCP SYN, it sends multiple ARP messages to discover the server, even though the server responds to all of them. Is that expected? Shouldn’t the client get the first server response and proceed to SYN?
my favorite strategy to understand what is happening is adding counters through the system, ie count how many packets make it through the ethernet phy, how many inbound make it through the ARP layer, IP layer, TCP layer etc, then try to determine if any TCP packet goes out et all and how far it gets.
I haven’t worked with other embedded network stacks but lwip in conjunction with FreeRTOS (not quite true, but no elaboration needed), but as far as I can tell, they all work conecptually compatible. I would look for a function called tcp_out which must be called if the TCP layer ties a packet for output. If that function is not reached, the inbound TCP ACK gets discarded somewhere along the way, so next I’d check if there is a function called tcp_input or tcp_in that should be called if the inbound packet makes it all the way up there (note that APR and ICMP traffic never gets that far).
Like htibosch, I’d also look into the routing issue a little closer. What are the subnet mask and gateway addresses configured?
Regarding the configuration addresses, this is what I am using:
subnet mask: 255.255.0.0
gateway: 131.230.193.254
I have run the server on a public IP as well, 131.230.193.XXX, and the behavior is the same.
Following your suggestions, I notice that packets are received by the client at the physical layer but are not categorized as ARP or IPv4 inside prvProcessEthernetPacket.
Additionally, by checking the HEX content on the packets, comparing with Wireshark and FreeRTOS debug logging, most received packet have several bits appended to them, that do not appear in the Wireshark representation of the packet.
I am looking closer now the driver code. Any further suggestions are more than welcome.
That I wouldn’t be too worried about, looks like padding.
By “received by the client at the physical layer” you mean that the packets are being stored in the ethernet driver’s input DMA buffer chain?
If it’s truly IP pakcets, they wouldn’t be dipatched to the ARP layer but should be processed by the IP layer. Is that an issue related to IP checksum offloading?
By that I mean that the packets are received by the client, but inside prvProcessEthernetPacket, the usFrameType is not interpreted as ipIPv4_FRAME_TYPE.
I tried the demo under a different network and there it worked as expected. I have also noticed the following warning in the driver’s code Warning: In case of heavy receiving loads, this register may not be in perfect sync. for smsc9220_peek_next_packet_size. I am not sure though how to verify that this could cause an issue on my setup.
ok, does the frame look anything like the corresponding packet in the wireshark log at all, or does it seem arbitrarily corrupted?
From what you are writing, to me it seems to be more of an ethernet driver issue losing or corrupting frames. Unlikely that you’ll get support for that here unless someone is familiar with this very setup…
