No server reply to client SYN TCP connection request

asked 2020-11-10 19:51:07 +0000

mi7WSuser
1 ●5 ●2

updated 2020-11-10 20:13:40 +0000

Hi, I apologize if any of the following seem dumb but I'm relatively new to ethernet and TCP/IP embedded programming, even high-level programming at that. I'm trying to establish a TCP 3-way handshake connection from NXP FRDM-K64 development board to a passive PC that has no application actual app running except WireShark and sometimes Internet Explorer, when I open the browser. NOTE that FRDM-K64 uses LWIP protocol stack, "around" TCP/IP stack. I send out SYN from the code. I see WireShark captures that the SYN packet was sent out - both src and dest IP addresses are correct. Also the port I put on the request is 80 (http). The FRDM board normally comes up in original code as a "web server". That connection works fine. I recently (since last week) started coding the board as a client too by simply adding the calls to tcp connect. Today, I added more TCP header "options" besides the MSS - windows scale = 2, shift by 2 or x4, and SACK permitted options. Why? because when I use this PC to GET website from FRDM webserver, that is the way it formats it's SYN TCP packet and the FRDM replies back with SYN-ACK... and the 3-way handshake started by PC client succeeds in establishing a TCP connection with PC as client and FRDM as server.
The additional TCP header options did not have any effect, still no SYN-ACK. I increased retries from 6 to 11 thinking the PC is just backed-up with connection requests and so it has not gotten to the FRDM's SYN packet. I only went up to 11 because pre-processor compiler complains about going >12 retransmissions (I didn't want to doctor the code any further). Wireshark shows the 1st SYN transmission from FRDM to PC and all the 11 retransmissions too. Also NOTE: I don't really think this PC backed-up with many SYN requests, because it's ethernet cable is currently only directly hooked-up to the FRDM so there really would not be many requesting to TCP-connect with SYN to it except the board. None of these approaches solves the problem. FRDM's SYNs do not get ACKed. I read somewhere maybe I should enable TIMESTAMP? in the option? while other readings said I should not so I have not done that. QUESTIONS: * Why is the PC not replying to the FRDM board with ACK? * Do I need to have a server-app program running on the PC just to have the server endpoint respond to the SYN? * Would simply opening a web browser suffice? * What am I missing on the FRDN client side? * What else should I do on the PC side that will be transparent to any other server - that any other server should or should not be doing to respond with an ACK to the FRDM board under their ethernet TCP/IP network protocol stack standard procedure to do 3-way handshake connection establishment?

Thanks for your help.

Comments

Something needs to be listening for the connection on the PC.
Here's an overview of the handshake: TCP Fundamentals Part 1 - Wireshark Talks at Sharkfest

If the PC can run WSL (Windows Subsystem for Linux) then you could use nc command as a listener.
Or use the Windows version of ncat.
Once a listener is running, verify that the Windows firewall isn't blocking connections to it.

Chuckc ( 2020-11-10 20:15:25 +0000 )edit

Chuckc, that makes sense. I'll look into this and let you know. Thanks.

mi7WSuser ( 2020-11-10 20:18:27 +0000 )edit

I finally got to establish a 3-way handshake connection with FRDM-K64 as client initiating SYN packet and the PC as server ACK-ing back with SYN-ACK packet and FRDM reply with ACK. So connection state is ESTABLISHED.

After reading through some more suggestions on how to listen, I just ended-up using simple Windows cmd line "netstate -a". There I saw the target PC's IP address:port in "LISTENING" state. It so happen its IP:139. So I replaced port "80" (http) with "139" and voila! the PC port sent back an SYN-ACK and all things went well from there.

Now I have a connection to send out data to from the FRDM board.

I note that port 139 is a port for SMP protocol that enables inter-process communication. The server sent back RST-ACK in a few seconds because my FRDM board's program has not done any "upper-layer" data transfer ...(more)

mi7WSuser ( 2020-11-10 22:37:39 +0000 )edit

add a comment

answered 2020-11-11 08:54:47 +0000

grahamb

flag of United Kingdom of Great Britain and Northern Ireland

23835 ●4 ●976 ●227 https://www.wireshark.org

You can't just connect to any random port listening port on your machine and expect it to "echo" random values you have sent to it.

All those ports currently shown as listening are because services running on your machine have opened those ports specifically for inbound connection for their specific protocol. If you run netstat -ab from an elevated prompt you can see which process is listening on the port.

As noted by @Chuckc above you need to run a process on your PC that will listen on a TCP port and, if you wish, echo it back. One such utility is echo server. Run it, using an unused port > 1024 on your PC, e.g. path\to\echoserver.exe /p tcp /s 8080 and modify your embedded software to connect to the port you have used (8080) in my example and you should see any data sent by the embedded board echoed back.

edit flag offensive delete link

Comments

P.S.

And best of all, I am able to run BOTH webserver as well as client connection (2 sockets) in bare-metal (no RTOS) on this single FRDM-K64. There was a slight delay in the website, most probably due to the tons and tons of PRINTF Terraterm console debug displays via UART-OpenSDA line that I have coded in to trace the code on my development PC, which is besides the WireShark sniffer on the spare PC that I use as "server" node.

I'll be programming data transfer callback application functions as CLIENT to send data to the PC node next, which eventual target will be a website in the cloud as server receiver.

QUESTIONS: * Now that I have 2 sockets to monitor on Wireshark (later on if connected to a switch there will even be plenty more IP addresses that will show up), is there a wild ...(more)

mi7WSuser ( 2020-11-11 15:25:56 +0000 )edit

hi @grahamb, I appreciate yours and @Chuckc explanation and instructions. I'm definitely taking all these info in and brewing in the mind to figure out many things for this development. I understand that the connection establishment with port 139 is fateless because it is a "deadend" (PC Windows NetBios SMB node that's "empty" application). Yes, I'm searching for such a Windows program whether cmd line or GUI that I will launch that will not just listen on specified port but also receive and handle/process any data payload that arrives to that port. I will check out echo server. Any comments about "Port Listener"? Thanks. P.S. previously, since port 80 was not "listening" or open for listening on that target PC, I hooked-up my board to an ethernet switch and send SYN connection request to google.com IP: 80, port "80". In my limited knowledge, I ...(more)

mi7WSuser ( 2020-11-11 15:36:47 +0000 )edit

Port Listener does just as it says, it listens on a port and shows what's received, it will never transmit anything back.

There are many ways to achieve what you want, ncat is flexible but most of the help out there for it is written around using it on Linux so isn't helpful for a Windows user. Most scripting languages have support for tcp sockets, with additional libraries providing more full featured support, e.g. scapy for python. PowerShell can use the .Net classes, an example here. Note that creating and running such a utility is off-topic for this site.

Wireshark has both capture filters that limit what packets are captured and display filters that limit what is displayed from a capture, their syntaxes are slightly different. Both those wiki pages have examples that handle your question.

A capture filter for a range of IPv4 addresses (e.g ...

(more)

grahamb ( 2020-11-11 15:58:56 +0000 )edit

Yes, I found a stackoverflow and a wireshark Q&A post on filter patterns and I figured out and use those subnet range method to display in ip.addr ==... / ... I haven't tried yet as I'm still building call back functions for data transmission but I believe how you described Port Listener is good enough right now - to simply display what I send, e.g. hello world or any data record line. later on, when FRDM needs to talk to actual webserver, the app layer should definitely parse for http replies as 200 OK or 404 and such which I'll probably pattern from how the PC handles FRDM's webserver response as such. It will be another "research" effort how to program such reply on the FRDM unless I find existing function internally as I found the previously UNUSED connect() function existed but I now have to supply the ...(more)

mi7WSuser ( 2020-11-11 19:22:32 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

No server reply to client SYN TCP connection request

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

No server reply to client SYN TCP connection request edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

No server reply to client SYN TCP connection request