In my app i sent packet by raw socket to another computer than get packet back and write the return packet to another computer by raw socket.
My app is c++ application run on Ubuntu work with nfqueue.
I want to test sent packets for both computer1 and computer2 in order to check if they are as expected.
I need to write an automation test that check my program, this automation test need to listen to the eth load the sent packets and check if they are as expected (ip,ports, payload).
I am looking for a simple way (tool (with simple API), code) to do this.
I need a simple way to listen (automate) to the eth .
I preffer that the test will check the sender , but it might be difficult to find an api to listen the eth (i sent via raw socket) , so a suggested API that will check the receivers computers is also good.
The test application can be written in c++, java , python.
The only way to check if a packet has been sent correctly is by verifying it's integrity on the receiving end.
Auto generate a large list of random packets, give the list to both computers and start sending them and when received, have them checked against the list. Computer 1 will send and then wait for a reply from computer 2. Computer 2 will check the packets and then send either a success or failure packet. Log the results on either computer (doesn't matter) and then you could generate statistics from the log file. Use this method in both directions to test both connections if needed. Should be extremely simple in python.
Or go crazy and use Hamming Codes:
http://en.wikipedia.org/wiki/Hamming_code (wiki)
http://lionel.textmalaysia.com/hamming-code-in-python.html (explanation and some code)
I operate tcpdump on the reciver coputer and save all packet to file.
I analysis the tcpdump with python and check that packet send as expected in the test.
Related
Forgive me for the following, as my understanding of winsock is not quite yet complete (I have only started looking in to it over the past two days). For now, my question is brief and more of a "can I do this the way I want to do it?" ordeal. On to the inquiry itself:
A member of my lab has written a nice winsock server that communicates with a client to transmit instructions to various instruments connected via serial. That part is already written and thankfully I do not have to touch; it works universally for all serial devices. However, the existing clients are all written in MatLab, and I'm trying to rewrite them in C/C++.
I've managed to successfully connect to the server and establish a socket. I can receive the data it sends and display it on the client. Great!
The problem I'm having thus far - after all of the initial data (containing instructions) is sent to the client, I cannot do anything. It will display the received data as text, but does not break the simple do while loop I have and ask the user for an input to transmit.
I'm wondering if it possible to set up a receive-then-transmit loop between the server and the client, such that I can send a command and receive the response with one socket in the client until I am done with talking to the server?
I will post my code tomorrow morning once I'm back at my lab computer!
Thank you for your time.
I need to do some validation testing of a new feed handler I have made. I have some pcap data that I captured from the production network and I would like to have my development feed handler connect to the "replay" of this data and compare the results.
My pcap:
I have a prod application that connects to a data feed, a TCP connection to an external server lets call assume this is 123.456.789.1:1234. This external sever then sends data to my application there is almost no client to server communication the server just sends the client data until the client drops. I have a pcap of all the packets sent to and from port 1234. I got this pcap by mirroring the production port (SPAN) on the switch and attaching tcpdump to an interface plugged in to the mirrored network port. When I look at the PCAP in wireshark it has all the data I would expect.
My problem:
I am in no way a network engineer and I am unsure how I can use this pcap to test my application. What I would like to do is "replay" this stream form the pcap and connect to it with my development application to validate that the data is being handled the same was it was on the prod connection.
I would like to some how "replay" the data sent from 123.456.789.1:12344 on 127.0.0.1:1234 and then connect to 127.0.0.1:1234 with my dev application. I looked at tcpreplay but from the documents I can not seem to figure out if it can do this, I get the feeling that they do not handle the tcp session data, and I could do this if it was a UDP stream, but tcpreplay can not act as the external server. Did I read this wrong or is there another tool that will let me do this?
thanks!
You may want to use netcat if you just want to throw some data back at your tool, and you don't care about what the tool sends.
You would do this by extracting the raw data sent by your tool from the pcap file (this tool may be helpful) and then piping that into netcat.
I try to make a server "messages" via websocket under boost.
Currently, I can often send large messages or series of messages from the server.
when I hit "send", it sends tons of data.
The difficulty is that when the server receives a command in a websocket message like "Stop", "Pause" ... this command runs until the end of the previous message. I try to stop the execution of the previous command.
I tried to read the buffer between sending data. but it does not work. I try to check if there is one receiving orders with async_read_some.
I based on the example of
http://www.codeproject.com/Articles/443660/Building-a-basic-HTML5-client-server-application
and HTTP server boost
http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/examples.html
Do you have any idea? I reworked my code several times but I can not execute the new real-time control as it appears at the end ..
thank you
If the data has already been sent to the network adapter, there is very little you can do to alter the order of packets. Network adapter will send the packets as and when it gets round to it, in the order you've queued them.
If you want to be able to send "higher priority" messages, then don't send off all the data in one go, but hold it in a queue waiting for the device to accept more data, and if a high priority message comes in, send that before you send any of the other packets off.
Don't make the packets TOO small, but I guess if you make packets that are a few kilobytes or so at a time, it will work quite swiftly and still allow good control over the flow.
Of course, this also will require that the receiver has the understanding of "there may be different 'flows' or 'streams' of information, and if you send a 'pause' command, it means that the previously sent stream is not going to receive anything until 'resume' is sent" obviously adjust this as needed for the behaviour you need, but you do need some way to not just say "put 'STOP' as data into the rest of the flow", but interpret it as a command.
If you send large message in the network as a single packet by the time server receives all the data the server receives stop message you may not have control over it until you complete receiving data.
It's better you implement priority message queue. Send the message as small chunks from client and assemble server instead of single large packet. Give message packets like stop(cancel) high priority. While receiving the messages at server end if any high priority message exists like stop(cancel) you don't need to accept remaining messages you can close the websocket connection at server.
Read the thread Chunking WebSocket Transmission for more info.
As you are using Boost, have you looked at WebSocket++ (Boost/ASIO based)?
I have used C++ & Winsock to create both server and client applications. After connecting to the server, the client displays an animation sequence. The server machine can handle multiple client connections and keeps a count of the total number of clients connected.
Currently, the client animation sequence begins as soon as the client connects. What I want to happen, is when 2 clients have connected to the server, the server should send a message to client 1 to call the Render() function (which is in the client) then, at a later time, send another message to client 2 which calls the same Render() function.
Just looking for some help as to the best way to achieve this.
Thanks
You can't send function calls (in any direct meaning of the word), since functions live within a single process space and can't (easily) be sent across a socket connection.
What you can do is send a message which the client will act on and call the desired function.
Depending on what protocols you are using, this could be as simple as the server sending a single byte (e.g. 'R' for render, or something) to each client's TCP connection, and the client code would know to call Render() when it receives that byte. More complex protocols might encode the same information more elaborately, of course.
In interpreted languages (e.g. Java or Python) it is possible to send actual code across the socket connect, in the form of Java .class files or Python source text, or etc. But it's almost always a bad idea to do so, as an attacker could exploit the mechanism to send malware to the client and have the client execute it.
I'm Working in an embedded linux environment.
it launches a telnet daemon on startup which watches on a particular port and launches a program when a connection is received.
i.e.
telnetd -l /usr/local/bin/PROGA -p 1234
PROGA - will output some data at irregular intervals. When it is not outputting data, every X period of time it sends out a 'heartbeat' type string to let the client know that we are still active i.e. "heartbeat\r\n"
After a random amount of time, the client (use a linux version of telnet, launched by: telnet xxx.xxx.xxx.xxx 1234) will fail to receive the 'heartbeat\r\n'
The data the client sees:
heartbeat
heartbeat
heartbeat
...
heartbeat
[nothing, should have received heartbeat]
[nothing forever]
heartbeat is sent:
result = printf("%s", heartbeat);
checking result, it is always the length of heartbeat. Logging to syslog shows us that the printf() is executing with success at the proper intervals
I've since added in a tcdrain and fflush which both return success, but do not seem to help the situation.
Any help would be appreciated.
**UDPATE: got a wireshark capture from the server side. Very Clearly the heartbeat is being sent continuously. No Hicups, no delays. Found something interesting on the client though. The client in this test case (telnet on Ubuntu 9.04) seems to suddenly stop receiving heartbeat (as describes above). Wireshark confirms this, big pause in packets. Well, once the client had stopped receiving the heartbeat, pressing any keystroke (on the client) seems to trigger a spew of data from the client's buffer (all heartbeats). Wireshark on the client also shows this massive amount of data all in one packet.
Unfortunately I don't really know what this means. It this a line mode on/off thing? Line endings (\r\n) are very clearly coming through.
**Update 2: running netcat instead of telnetd, the problem is not reproducible.
The first thing I would do is get out Wireshark and try to find out if the server is truly sending the message. It would be instructive to run Wireshark at the server as well as third party PC. Is there anything different about the last heartbeat?
Edit. Well, that was an interesting find on your client.
It seems like there's some sort of terminal thing in the way. You may want to use the netcat program rather than telnetd. netcat is designed for sending arbitrary data over a TCP session in raw mode, without any special formatting, and it has the ability to hook up an arbitrary process to a socket. On a Windows machine you can use PuTTY in raw mode to accomplish the same thing.
It may still be worth examining traffic with a third party between your client and server. The kernel may be optimizing away writes to the network and internally buffering data. That's the only way to ensure that what see is what's really happening on the wire.