FRDM-K64 as CLIENT use tcp_connect() to connect to remote server

[mignacio]

Hi,

I have used the the base SDK project, proj_lwiphttpsrv_bm, which configures the FRDM-K64 as a Web server and that all works fine, where my PC setup as specified IP address acts as the client with browser to GET the default index.html webpage on its browser.  I have even modified the webpage to display something other than the default index.html.

Now as the subject line says, I have started programming the FRDM-K64 as a TCP client that will start a TCP raw "socket" by using tcp_new_ip_type() and then establish a connection to remote node using tcp_connect() to send SYN out to target "server" - by 3-way SYN-SYN/ACK-ACK handshake.

PROBLEM:  the FRDM client is not getting any ACK or SYN/ACK reply to the SYN it sends out to the target IP address I specified on PCB and put as input argument to tcp_connect().   I see the SYN traveling over the ethernet line as captured on Wireshark from FRDM-K64 (IP: 192.168.0.102) sent to PC (IP: 192.168.0.100) but the PC just keeps sending out BROWSER and NBNS packets as multicast(?) IP: 192.168.0.255 but NO clearcut SYN-ACK to the FRDM's SYN.

OTHER ISSUES:  I'm not sure I understand what I'm supposed to put in the function "tcp_connected()" callback function also specified as input argument to tcp_connect().   Based on readings, I deduced it will be called back only AFTER the SYN-SYNACK-ACK 3-way handshake is complete, when connection has been established, just as I have observed in Wireshark monitoring for server mode of the FRDM-K64.

QUESTIONS: 

What am I missing to do in setting up FRDM-K64 as a client in RAW mode bare-metal?

I mean, I don't have to do any bind() or listen() or accept() operations, do I?

All I currently do for setup is to call tcp_new_ip_type(IPADDR_TYPE_V4) - should I use TYPE_ANY? - to get a new pcb and if successful, I call tcp_setprio() and setup callback function for connected.

Then pass the created pcb to tcp_connect() together with the target/remote IP address as this:

tcp_connect(pcb,netif_ip4_gw(netif), LWIP_IANA_PORT_HTTP,tcp_connected);

NOTE: I setup port as "http" = 80, webserver.

Basically, I let the FRDM-K64 initialize as regular web server mode, setup its ipaddr, mask, gw IP addresses in netif structure,... let it do all regular init function calls based on original SDK.

I don't right away do the tcp_connect right there.   Instead, I let the network come-up, then inside ip4_input() I parse for incoming IP addresses.   When I see the target address is the same as incoming source, that's when I do the tcp_connect() call.

And so, the SYN goes out and is received by the other side (PC) but how come the PC is not sending back ACK to the SYN?  as I can see on Wireshark monitor.

So I figured maybe the switch will make a difference and hooked-up cables so all nodes are in a star networked via a switch.  Nope.

So maybe because I don't have a PC app running as a server that is "listening" so I decided to connect to www.google.com, thinking that's a webserver somewhere there so I used google.com IP address.   I see the SYN went out there in the www-land with IP address to google.com but still NO ACK from google.com.  I would think google.com is ALWAYS running as a "server" listening for client connection to it.  Why do these "servers" ignore my FRDM-K64's SYN to connect to their TCP layer at least and complete the 3-way handshake?

So what is wrong or is missing in my code? 

Is it where I make the call to connect?

Do I have to broadcast/announce the FRDM-K64 node out there before trying out tcp_connect() so "listening" server can ACK to it?

Thanks for the help.

MI

[mignacio]

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.

[mignacio · Accepted solution]

Hi,

I posted my question on WireShart forum and with someone's suggestion for a "listerner" app on PC side,  the mind started grinding gears and this is what I did which solved my problem;  hopefully it helps someone.

https://ask.wireshark.org/question/19902/no-server-reply-to-client-syn-tcp-connection-request/

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 application at this point which is what I will be doing next. If anyone has any suggestion on any PC application I can run that is binded to port 139 which my data transfer application (e.g. display "hello world" at first on server side), please let me know.

Also, if I have time, I'll see what the effect of this if I disable/remove the "window scaling", "multiplier" and "SACK permitted" TCP header options and just keep it as original just "MSS" option on the SYN packet. Any comments?

I hope this solution will help others who have struggled with establishing a TCP connection with 3-way handshaking at client initiation.

Thanks.