how tcp listen works

[rajabala]

Hi,

  I am trying to create a connection between enc28j60 and labview via TCP protocol. the device enc28j60 is kept as a client. It has all the functions to work as a client(like sending arp request, checking if received arp reply is correct or not.. etc.,)

  To make those fumctions in a correce sequence, I need to know how TCP functions like TCP listen,TCP Read, TCP Write in LabVIEW works (the signals passed by them).

  thanks in advance

  raja

[nathand]

Is the device you're using this one from Microchip? If so, what device is controlling it? In order to communicate with it over TCP, you need a controller with a TCP stack. The ENC28J60 doesn't handle the TCP protocol at all, it just handles the low-level ethernet details.

The LabVIEW TCP functions are wrappers around calls to the operating system's TCP functions (connect, accept, send, recv, select...). It relies on the operating system's TCP stack.

LabVIEW doesn't handle ethernet at a low level, everything is routed through the operating system.

ARP is a completely independent protocol from TCP. LabVIEW doesn't do ARP at all - that's handled by the operating system.

I really cannot understand what you are asking.

[vickys]

Thanks for the reply.

I am using a microcontroller from arduino to control the enc28j60. My LabVIEW will have "TCP wait on listener" to make it work as a client. The code in the controller will be in a form of state machine where various states are for"arp request send", "arp reply accept","TCP syn send", "TCP ack syn receive" ," TCP ack send" etc., based on the packet received I will switch between the states. 

My problem is when I run the LabVIEW, the flow stops in "TCP wait on listener", and then I burn my program to the controller. This will set the IP and Port to the required values and then starts to switch within the states of the state machine. I expect the state machine to execute in the same order as I have mentioned them in the previous paragraph. (I use ARP because to get the MAC address of the PC) but the packets I receive from PC are not in the format in which I am expecting. So the TCP connection is not getting established.

But at times, the states go in the same order and I get a successful connection. I want to know the reason which is make the connection successful at times and not in other cases. Even if the connection is established, I get a Error1 code in "TCP write"  that I do right after the connection is established. The connection reference is not dead though.

Am I clear now? Can you help me with my problem?

[nathand]

Have you tried installing a packet sniffer such as WireShark to look at the actual network traffic between your device and your computer running LabVIEW?

Do you have a working TCP stack on the Arduino, or are you trying to implement one yourself? Implementing a full networking stack is a difficult project.

Can you upload your LabVIEW code?

If you cannot consistently establish a connection, the problem is most likely in your state machine, and not in the LabVIEW code, since LabVIEW doesn't even know about the low-level TCP details.

[rolfk]

ARP and TCP are completely different parts of the TCP/IP stack. ARP is the Address Resolution Protocol that is an underlaying part when the a conenction is established. It translates between the IP adress and the Ethernet address and nothing more. It is no usually what you are concerned at all when talking TCP, UDP or whatever since it is all handled underneath in the socket driver, which also implements TCP/IP, UDP and some other protocols that are required for a network connection.

LabVIEW itself only works on the TCP/IP and UDP level and even that is in fact completely handled by the OS internally. All LabVIEW does is opening a socket with the socket() call, and then for listen calls bind() to bind it to the desired local address and port and then goes in a loop to use the select() call to see if an incoming connection occured. If select() returns sucessfully the LabVIEW Listen function returns and you can start doing read and write with the TCP Read and TCP WRite functions. That is all and it is all the same for every application that does TCP or UDP communication on modern OSes. No need to do anything about ARP at all, that is all handled by the OS driver and will always be the same for any application that uses the Windows (or Mac or Unix BSD) socket interface.

So there is nothing special about LabVIEW network communication in terms of getting it to work with your Arduino. Create a small C listener on your host using any C compiler of your choice and try to connect to it from your controller. Once that works it will work for LabVIEW too. I suspect your TCP state machine in your controller is still buggy and that is why it doesn't work.

[rajabala]

My LabVIEW code is very simple, just a TCP Listen outside a while loop and TCP write and read inside the while loop. I tried using Wireshark. 

  I dont close the TCP connection propely when I get any error,,  will that affect in reestablishing the connection when I run the VI again? based on the TCP packets that I observed in the Wireshark, I find that even after a connection is established between the PC and device,, PC is sending me an ARP request.. (my device can only work as a client according to my code.It cant make an ARP reply.) why do you think PC might send an ARP request even when a connection is established?

  where am I doing it wrong?

The PC is also sending an packet of NBNS protocol. I hope it doesn't help me in any way in making a TCP connection. why does PC send it ? what should I reply?

can you help me out? I am really struck with this.. 

[nathand]

I'm not an expert in low-level TCP communications, but I do enjoy learning about it through trying to help answer questions like this.

Can you share Wireshark log, showing ONLY the communication between your device and your computer? How much of the TCP communication completes? It seems normal to me that there would be an ARP request in each direction, because in order to maintain communication, both sides need to be able to resolve the remote IP address to a MAC address. In your situation, I'm guessing your device can talk to the computer, but then the computer doesn't know where to send packets back to the device. Depending on timing, it's possible that the TCP listen will succeed once it receives the connection request, but then the matching connection request the other direction to establish communication fails because the MAC address of your device isn't available.

Have you considered putting a simple TCP client on another computer on the same network (possibly written in LabVIEW) and then captured the communication between it and your program to compare the network traffic in a working situation versus with your device? Again, writing a working networking stack is difficult.

It's good practice to close all connections before your program ends, but not doing so should not cause problems here. When a VI stops running, LabVIEW cleans up resources the VI owned such as file handles and network sockets.

I'm fairly certain you can safely ignore the NBNS packet, it's used for Windows-only services.

[rajabala]

          Your idea of wireshark was really helpful for me to know about what is happening.

I have attached all the files that I was using. the folder "Codes for enc28j60' is used to make my devide work as a client. The  file "enc28j60.c" is more specific on device and the files "ip_arp_udp_tcp.c" and "ETHER_28J60.cpp" are related to protocol. the ino format file is the one burnt to the controller that controls the device. 

      To give an overview of the code, I have implemented all the TCP connection establishing steps under "client_process" and data transfers in "client_data" . only one of them is made to execute by controlling a variable called "client_data_ready".

    The Wireshark log is also added. I believe that my PC will get the mac address of the device when my device sends the ARP request, then why is it required for the PC to send another ARP request to get the same MAC address?

    Moreover I was able to send and receive data for 3 or 4 times, after which I am not able to get any. (it feels that even after the connection establishes, they could not talk)

[nathand]

I could be wrong about whether the ARP request from the PC to your device is necessary - as I said, I'm not too familiar with details at that level.

Your ENC28J60 is sending a lot of bad packets, according to the Wireshark log. It is acknowledging receipt of packets that it didn't receive, and there are also a lot of TCP retransmits. We're beyond my level of experience with Wireshark here so I can't tell you exactly what's going on.

As you're aware, this is a LabVIEW community, so probably not the best place to look for assistance with Arduino C code. I don't have the time nor ability to examine your source code, although I can tell you the LabVIEW VI looks fine. I recommend you ask in an Arduino-specific forum where people may be able to provide more help.

Good luck with your project, and if you have more questions on the LabVIEW side of things I'm happy to try to help.

[rajabala]

ok.. I will try to do that.. Anyways, thanks for the help.