Hello, Here's my detailed question: There's a Windows C# driver to a Database(which contains the server). I have analysed the client-server communication on Wireshark between these two. How can I know which particular packets are responsible for opening the socket, establishing connection and closing the socket? My idea is to send the same type of packets from a PLC(Non-windows) to the Database to 'recreate' the driver functionality. What I have understood so far: 3-way TCP handshake is necessary for opening a socket. asked 15 Dec '15, 01:26  Arjun S edited 15 Dec '15, 04:56  sindy |
2 Answers:
3-way tcp handshake is necessary for establishing a tcp session (which, from the client application point of view, is equivalent to opening the socket). But after successfully establishing the session, it is necessary to send packets with properly formatted tcp headers to let the tcp session fulfil its purpose of delivering application data sent to the socket. So sending just a couple of properly formatted packets will not do the job. So the first thing you need is a complete tcp stack, not just an ability to send two packets. Next, you need to understand the application protocol which uses tcp as transport, so that you could send proper queries to the database and understand the answers. answered 15 Dec '15, 01:59 sindy showing 5 of 11 show 6 more comments |
Can you be more specific about what you're trying to do with your DB? TCP 3-way handshake is not normally something a DB programmer will be concerned with. On Windows programmers would generally use an ODBC driver, or possibly a DB specific driver. The driver abstracts out all the low-level details such as TCP handshake and allows the programmer to concentrate on their task of querying the db. For C#, there is a MongoDB driver available here. answered 15 Dec '15, 02:33  grahamb ♦ Thanks for the reply, Grahamb. :) I want to insert documents from a PLC into MongoDB(NoSQL) but the PLC doesn't have a driver for MongoDB which is why I looked at the socket communication for client and MongoDB using C# to get a rough idea. Since there is no driver at all, is it possible to send the same packets for opening a socket, connecting, closing, et al as seen on Wireshark from a PLC to DB as a string, maybe? (15 Dec '15, 02:42) Arjun S |
Thanks for the detailed answer, Sindy.
I am using a Mongo Database so as you said, I do need to query the database. But not using query commands, rather with the packet data(used for Windows) itself.
Also, since I am using the Mongo Wire protocol, it says 'Clients should connect to the database with a regular TCP/IP socket. There is no connection handshake.' Since there is no connection handshake for this one, how does it affect the entire thing?
I would understand
the way that there is no (need for) connection handshake at application level (the query/answer format/protocol used to talk to the database), because tcp is a reliable transport in terms that it itself takes care about retransmission of eventual lost packets, delivering the bytes of the messages in proper sequence in case that the packets' order swaps in transmission etc.
So once a tcp session is established (which from the application point of view is equal to successful opening of a socket), you can write your query to the socket, and read back from it the answer, without worrying about reliability of the transmission, because the tcp transport below does that for you.
That once again leads us to need to have a working tcp stack on the PLC, as without it, you'll simply not be able to send your application queries and receive the answers.
If there is no tcp stack available for the PLC (possibly due to memory limit or due to complete absence of IP stack, you haven't told us about what the PLC can do at network level), you may need an intermediate box which would understand the protocols which the PLCs already can talk and would act as a mediation gateway to the TCP (or even IP) world, translating the queries in PLC's native protocol to queries to Mongo transported using TCP, and vice versa.
The PLC has asynchronous function blocks TCP for connecting, sending data, receiving data and finally closing the connection. I have used them in my program to in order to communicate with the Database. But the only hurdle is I cannot query to the database at all, since there is no driver available.
OK, in that case everything seems much simpler. In that case, we come back to the area of using Wireshark to reverse-engineer a protocol and verify our own clone of that protocol.
When you capture the communication of an existing client with the MongoDB, you can right-click a packet (in the packet list pane) which you know to be part of the session (e.g. the one which says SYN and has the MongoDB IP as source or destination) and then choose Follow -> TCP stream. A new window will pop up, showing you the payload of the conversation over that tcp session (it means without the tcp overhead, it means actually the byte streams which an application writes to the socket and reads from it). Switch the "show data as" to "hex dump", and you'll see the queries and answers distinguished by colour and offset from the left. This should help you understand what is missing in your queries that Mongo rejects or ignores, especially if you do the same on a capture taken between your PLC running your code and Mongo and compare the results.
ah okay, it seems much clearer and that's probably what I was looking for.
So, I have 2 questions:
Since there are many frames with SYN, should I select just one of them because there are different payload for different frames with SYN in it?
Should I check for the payload of the conversation in which only SYN is present or [SYN, ACK] and [ACK] as well?
I don't think there's any need to reverse engineer the MongoDb protocol, it's specified here.
Wireshark also includes a dissector for MongoDB, so it should be able to show you the packet details straight away, unless you're running MongoDB on another port (other than 27017), in which case you can modify the MongoDB dissector preference for the port you're using.
Each tcp session starts from the "three way handshake", which is
the client sends a packet with no payload, SYN bit in flags set to 1, and some (as-if-random) sequence number,
the server sends a packet with no payload, ack number matching the sequence number of the previously received packet, and its own, completely unrelated, sequence number, also with SYN bit of flags set to 1
the client sends a packet (which already may have a payload but I am not sure here) whose ack number matches the sequence number of the server's sequence number.
Normally, a single tcp session is re-used for more than one request-response pair between a client and a server, but it depends on particular implementation. So if you have, in a relatively short capture, several packets with
tcp.flags.syn == 1and the source/destination IP matching the one where the MongoDB is running, you have to look also at tcp port at MongoDB server side and at the other IP (if you capture on the MongoDB server and many clients are connected).In any case, the packets with SYN = 1 do not carry any payload, but are easy to identify and a good base for "follow tcp stream".
Grahamb,
Yes, I am running the DB on 27017. The different fields inside the Structure Message Header appear on the Wireshark pane. Now that I have those, I can compare the field values of the Windows driver with those of PLC and see where it is going.
Thank you very much. :)
Sindy,
You said 'you have to look also at tcp port at MongoDB server side'. I am only checking the connections from the client side via Wireshark. Is it a necessity to check on the server side as well or can I check it from the client computer itself? And there is only 1 client and 1 server involved.
I've said that in a context where you've complained about many packets matching display filter
tcp.flags.syn == 1in your capture. It is enough to capture on the client computer, and applying a display filtertcp.flags.syn == 1 and tcp.dstport == 27017should be sufficient to tell whether just a single tcp session has been established between the client PC and the server during the capture, or more than one. But even if there are several such packets in a capture from successful communication, any of them can be used to "follow tcp stream" (which will replace the display filter withtcp.stream == xx), as for your purpose there is little difference between the sessions.When capturing to debug your PLC application (probably on the server, with capture filter set to
host ip.add.re.ss, where ip.add.re.ss is the IP of your PLC device), you should see the three-way handshake to complete successfully first, and if this is true, you should see also some packet(s) whose protocol name in the packet list is "MONGO", because it carries some payload and the source or destination tcp port is 27017. These two conditions should be enough for the mongo dissector to kick in, although what you send may be a garbage yet.This answer helped me a lot to understand about the payload. Thanks a lot for your valuable time. :)