1

Running Ubuntu.

I have machine A -> machine B (one-way connection from A to B) . Machine A goal is to forward tcp packets to machine B (it dosnt has tcp connection with machine B. it just forward tcp packets that it get from other machines) In machine A there are c++ code that collect some tcp packets based on business rules and write them by raw socket to machine B.

I want to do performance test for my code on machine A, so in order to do this I need to send massive TCP packets to machine A my c++ code will forward them to B. At the end i will validate that all packets were revived in machine B. Do you have any recommendation for tools? tools that will simulate massive send and tools that will help in the assertions (can be assert by amount, checksum, any other idea)

I think on upload big file file to A dump the upload traffic and than replay it with tcpreplay (i will create 100 threads that replay the same upload dump in order to have massive tcp stream). In order to validate i will analyze the tcpdump on the receiver to check if its has the same excepted amount of packets as sent.

This is not about tcp as protocol only generate real tcp packets (as structure) send massive of them and validate by compare payload or amount or any other way. Any advice?

Avihai Marchiano
  • 612
  • 3
  • 16
  • 32
  • 1
    What about calculating a checksum over all the data? Have the sender calculate a checksum and send it after the data and have the receiver calculate a checksum on the received data and compare the two. If they match, you're all done. – larsks Aug 08 '12 at 16:23
  • 1
    This sounds like a case where you're trying to do something and you think that this is the appropriate intermediate step. I don't think this is the step you want in the middle. What is the bigger goal you're trying to accomplish? – Jeff Ferland Aug 08 '12 at 16:40
  • I explain the scenario. – Avihai Marchiano Aug 08 '12 at 17:17

1 Answers1

1

I have machine A -> machine B (one-way connection from A to B) . I need to send massive TCP packets from A to B and validate that all packets revived. Do you have any recommendation for tools?

I recommend TCP, which ensures reliable, ordered delivery of data.
(You are asking us for a tool to do what the underlying protocol already does.)

Also note that TCP is inherently bidirectional: ACKs have to get sent back from Machine B to machine A. A "one-way connection" is impossible - No ACKs means transmission will stall forever.

I think on upload big file from A to B (do this when they has two-way connection) dump the traffic from A to B and than replay it with tcpreplay (i will create 100 threads that will replay it in order to have massive tcp stream). In order to validate i will analyze the tcpdump on the receiver to check if its has the same excepted amount of packets as sent.

TCP doesn't work that way. The packet count over the wire may be different due to differing window/MTU sizes, dropped-and-retransmitted packets, delayed ACKs (resulting in double transmission of a few packets), etc.

You can't just shove the same data over the wire and expect it to work exactly the same way -- In practice this often works (and is the basis of replay attacks), but TCP is governed by a state machine, and you really need to run through that for each connection.

If you need to generate a large amount of TCP traffic and don't care about the data you should simply start multiple streams sending the data to listeners on the remote system (which presumably can just discard it).

If you care about the data you should do as lasrks suggested and checksum the received data (in its entirety) after it's exited the TCP/IP stack...

Wesley
  • 32,690
  • 9
  • 82
  • 117
voretaq7
  • 79,879
  • 17
  • 130
  • 214
  • Sorry , my question was not clear i hope that it cleared now. I dont realy have tcp connection , so this is the reason that i work one-way. o just need to deal with massive tcp packets. – Avihai Marchiano Aug 08 '12 at 17:18
  • @user1495181 your clarification doesn't change the nature of your question (and therefore doesn't change my answer): TCP (in conjunction with IP for the routing bit) is **designed** to do what you're asking for, without any other tools. You can't look at a TCP data stream and know that it's "complete" -- you rely on the *protocol* to ensure that everything that was sent was received, and it's the job of the *application* to determine that what is received is well-formed/valid/as-expected (via a checksum or similar mechanism) – voretaq7 Aug 08 '12 at 17:31
  • I dont care about tcp as a protocol. i need a way or tool to create massive tcp packet (not tcp connection only send tcp packets). i forward the packets as they are (by copy incoming packets and send with raw socket), so i need a tool to count or compare packet tcp payload against the sent tcp payload. – Avihai Marchiano Aug 08 '12 at 17:34
  • @user1495181 You cant have that. There is *no such thing* as a TCP packet without a connection. If you're talking about comparing one **packet dump** to another "known correct" packet dump that's not comparing TCP packets - that's comparing two files *which happen to contain copies of TCP packets*, and reduces to checksumming like larsks already mentioned... you can netcat /dev/random from one machine to another, capture the stream on both ends and compare them, but that's not a useful test (what is sent may be > what is received) – voretaq7 Aug 08 '12 at 17:38
  • machine a get tcp packets and forward them . it forward only tcp packets. and by tcp i dont mean to tcp protocol. i mean to tcp structure. packet that ip protocol is tcp. – Avihai Marchiano Aug 08 '12 at 17:45