RAW TCP connection issues

Libraries
21

I’m using a function state = FreeRTOS_connect(conn->socket,&server,sizeof(server));
perhaps this waiting time is set by a constant in the configuration file or is it a socket option FREERTOS_SO_RCVTIMEO ? Can you tell me how I can do this? I also assume that the reason is sending the next packet too fast.

22

this is another connection to mqtt virtual server. Proxmox assign this mac (6a:74:ec) to virtual mqtt server

23

just try a proper mac address. Won’t cost you much.

24

Hi @pistoletov1974, would it be possible to post a PCAP file of the complete conversation between de DUT and the terminal on the other side?

It’s just that PCAP’s are much easier to analyse than a picture which doesn’t allow copy/paste.

You can filter the packets with for instance:

    arp || icmp || ip.addr==192.168.88.108 || ip.addr==192.168.88.109 || ip.addr==192.168.88.116

After making a selection, you can press “File → Export specified packets” and save the PCAP. You’ll have to ZIP it before attaching to a post.

Thanks,

25

In the FreeRTOS+TCP logging, an IPv4 address will be printed with the format %xip, which results in e.g. c0a8586dip. An IPv6 address will be printed as %pip, e.g. :

FreeRTOS_printf( ( "NEIGHBOR_ADV from %pip\n", ( void * ) xIPv6Address.ucBytes ) );

If you download and link printf-stdarg.c to your project, the formatting will be as expected:

-    ipARP_REPLY from c0a8586cip to c0a8586dip end-point c0a8586dip
+    ipARP_REPLY from 192.168.88.108 to 192.168.88.109 end-point 192.168.88.109

The printf-stdarg will redefine the [vsn]printf() family in a task- and interrupt-safe manner. It has a very small memory- and stack-footprint.

About the timeout on connect: they are pretty hard-coded. It copies the behaviour of e.g. a telnet client on either Linux or Windows: FreeRTOS_connect() will do 3 attempts:

 9.857.449 [IP-task] Connect[192.168.2.11:32002]: next timeout 1: 3000 ms
12.847.592 [IP-task] Connect[192.168.2.11:32002]: next timeout 2: 6000 ms
18.844.594 [IP-task] Connect[192.168.2.11:32002]: next timeout 3: 11000 ms
29.842.450 [IP-task] Connect: giving up 192.168.2.11:32002 after 11 seconds.

So a failing connect() will last about 20 seconds.

At the top of this post I see:

x.109 sends SYN  x.108
x.116 sends ICMP x.188

x.116 is your Linux machine. Why would it report “Destination unreachable” right after an unanswered SYN request? Therefore it would be handy to see an PCAP file.

Thanks,

26

Thank you very much for the answer, I am attaching the pcap files In it capturing Linux (…88.116) and FreeRTOS (…88.110) packets.

@RAc i change my mac according to your recommendation, but unfortunately it did not change the situation

wireshark.zip (1.6 KB)

28

@htibosch @aggarg @RAc Thanks a lot for your help, I found a bug in my code. These were multiple calls
state = FreeRTOS_connect.....

29

In the PCAP we see 3 successful connect actions, with source ports:

61153
36630
61192

There is a 3-way handshake on each port. Only the last port 61192 is used for HTTP communication, with succcess.

So I think that the problem is solved?

30

Good find - that explains the multiple SYN without previous SYNACK.

1 Like
31

After disconnecting and turning on the network cable, my board starts sending a SYN packet (FreeRTOS_connect) to the device again, the device does not respond ACk until I reboot it. Is this a problem in my code or in the device code? Should I close the connection before calling FreeRTOS_connect for reconection?

32

I wrote about that subject today.

It explains what happens when the Link Status goes down.

And yes, it may help if you close the socket that was used while the Link Status went low.