TCP/IP Simulator?

[Lithium666]

Hi All,

I am looking for a basic TCP/IP simulator to assist in the testing of client sw.

I need something that will automatically handle the TCP/IP layer (i.e listen/establish incoming connections)and dump the data portion of the packet (no decoding needed). And in the reverse direction allow me to supply IP Address/Port/Data and have the simulator generate the TCP/IP header and send the packet.

Does anyone know of any sw with this functionality?

I guess the alternative is to write it myself.

Thanks for your time

 

[RLE]

What´s your O.S.?
If your are using W2k, you can configure Microsoft Loopback Adapter, see

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q236869

 

[Lithium666]

Hi,

Thanks for the reply but I'm unsure how the loopback adapter will help me.

Perhaps I haven't explained what I'm trying to do very well, here goes again:

I am basically developing a TCP/IP based client. Unfortunately the Corresponding Server is on a secure LAN so I have to travel to the gateway everytime I want to test (quite a trek).

However, I can construct the Server responses myself since I have the proprietary protocol spec. So I was hoping to use a workstation runnning a tcp/ip sniffer/simulator to act as the server.

That way I can connect to simulator/sniffer pc with client, view incoming packets to see if they are correct and construct and send responses. i.e

(OPEN TCP Connection)

Client ----- (SYN J) ----------------> Simulator Sw (Acting as Server)
Client <--- (SYN K & ACK J+1) --- Simulator Sw
Client ----- (ACK K+1) ------------> Simulator Sw

(LOGIN over TCP/IP connection)

Client ---- (TCP/IP DATA:LOGIN MSG) ----------> Simulator Sw

(Manually Construct response msg on sniffer/simulator sw and send)

Client <--- (TCP/IP DATA:LOGIN_RESP MSG) --- Simulator Sw

Unfortunately all the TCP/IP sniffer/simulator utilities I have found fall short when generating packets.

I can currently use Sniffer Pro to grab the incoming packets without a problem. But when generating responses I have to construct the entire packet including the TCP/IP header.

For example when opening the TCP/IP connection I need to respond to the incoming (SYN J) from the client with (SYN K & ACK J+1). Since J is randomised to prevent (or at least hinder) spoofing I have to change my response packet on the fly with sniffer pro:

Client ----- (SYN J) ----------------> Sniffer Pro (acting as Server)

(Change ACK in TCP/IP header. Change Checksum. Send Packet)

Client <--- (SYN K & ACK J+1) --- Sniffer Pro
Client ----- (ACK K+1) ------------> Sniffer Pro

This becomes even more tedious when sending variable data. (Assume J & K start at 0):

Client ------ (TCP/IP Data: 53 48 49 54) ---> Sniffer Pro

(Set ACK 4, Set Checksum, Send Packet)

Client <------ (TCP/IP Data: 31 32 33 34) --- Sniffer Pro

or

Client ------ (TCP/IP Data: 53 48 49 54 31) ---> Sniffer Pro

(Set ACK 5, Set Checksum, Send Packet)

Client <------ (TCP/IP Data: 31 32 33 34) --- Sniffer Pro

As you can see in the second scenario, there is only one additional byte in the client request and my response is the same. But I still have to change the Header of my Packet.

And these are just simplified scenarios to illustrate my point. And we haven't even considered RTT (Round Trip Time) Timer.

Hence what I really need is sniffer/simulator software which will calculate the header for me. So all I need to do is specify PORT/IP/DATA.

All the software I have seen fits into one of the following categories:

- Requires user to define entire packet, including header (i.e. sniffer pro).

- Allows user to specify Port/IP and will calculate Header. BUT data is random or fixed

Any help would be much appreciated.

I am almost resigned to the fact I am going to have to write my own test software....

 

[dilettante]

You'll have to write your own server simulator. I've done this many times.

The problem is, with TCP there is no such thing as a &quot;message&quot; - there are only send and receive streams. &quot;Packets&quot; are used at a layer below TCP of course, but a TCP application has little control over or awareness of TCP packets. When I write TCP clients and servers that think a data arrival event means I got a whole message I've been sorely disappointed. For Winsock at least, an arrival event just means you have gotten one or more packets of data buffered, it doesn't mean you got everything you need. You can sometimes get away with this if your &quot;messages&quot; are pretty tiny, but I often have transactions made up of anywhere from tiny to very long strings of bytes (over 10,000 sometimes).

So a simulator has to have some idea what the traffic is about, to know when it should send even canned replies back to the client.

One thing I've done to make writing such simulators a little easier is to use the simple TCP traffic logger TCPTap. This means I don't have to display or write traffic to a log file in my sim programs.

You set up TCPTap as a TCP relay. Then you have your client connect to TCPTap, which when your client connects will in turn connect to your server. Once the pass-through is established, TCPTap will transparently pass data bidirectionally, and log everything to a text file - formatting it in hex as well as in ASCII, EBCDIC, or both. Control characters are zapped to periods, so the TCPTap log can be viewed in NotePad or WordPad or a text viewer, or even printed.

Since I started using TCPTap I almost never use a packet sniffer to debug TCP clients and servers. One big exception is FTP, because TCPTap can't handle the second port properly - it gets set up dynamically. I use the TCPTap logs to document my client/server protocols too. It makes it a LOT easier to include sample interchanges in my software docs.

TCPTap can be downloaded from

http://www.angelfire.com/mi4/bvo/tcptap.html

and perhaps other download sites. Might be worth a look, though it won't solve your whole problem.

 

[Lithium666]

Thank you kindly for the reply.

It's true the IP packet layer sits below the TCP layer in the Stack. And yes TCP is essentially involved in controlling transmissions (&quot;send and recieve streams&quot as the name suggests.

I can't see that I have suggested otherwise or used the term &quot;TCP Message&quot; anywhere. Where I have used the word message:

Client <--- (TCP/IP DATA:LOGIN_RESP MSG) --- Simulator Sw

I am reffering to the proprietary messages which are being transported over TCP/IP (in the data portion of the packet(s)/segments) between the Client and Server Apps. (Hence &quot;TCP/IP DATA:&quot.

In my case the proprietary messages are small enough to fit inside a packet/segment, which does make writing the client simpler. (Rather then reconstructing from the various segments).

&quot;So a simulator has to have some idea what the traffic is about, to know when it should send even canned replies back to the client.&quot;

No it doesn't. The simulator merely has to:

1) Listen for incoming connections and establish.(I.E. respond to incoming SYN segment with its own SYN + ACK segment).
2) Recieve the incoming packets and display the data layer so I can see if the proprietary message is correct. (NOTE: Something which most simulators/sniffers can do).
3) Send the Data I specify (by file or shell or GUI) back to the client in the data portion of a TCP/IP packet/segment, setting the (sequence number)/(ack no)/(checksum) in the header accordingly.

The data sits above the TCP layer and so its meaning has little or no bearing on TCP protocol functionality. The protocol only facilitates the correct transmission of X bytes from A to B. Segmentation, Sequencing, Acknowledgement, etc but NO interpretation.

I am suprised no such software exists. Without it, testing a TCP/IP based client/server would have to be done by generating packets/segments manually.

Do people test new clients directly on mission critical servers???

I am new to writing clients for TCP/IP based servers. But when interconnecting telecoms switches for example you must first prove your switch complies to the various protocol specs. (I.E. Q763 for ISUP). The same applies for ATM switches, SDH ADM's, etc... (For all these protols I have found test tools which do a similar job).

Sorry for digressing at the end...

 

[dilettante]

Hmmm...

Maybe knowing what platform you are writing the client for would help, as well as what you are using for an API?

Normally I'd expect even embedded system developers to be using something like a socket library or Winsock component. In such a case your application never deals with SYN or ACK sequences.

It sounds like you're plugging into the IP layer instead of TCP, or implementing your own protocol stack on top of a packet driver or something.

All I know is I have a lot of applications where I doubt any generic simulator can drive my clients. How would a web browser function against such a thing? I'd expect it to just lock up as soon as it made a request and got back something that it didn't expect - and HTTP is just text over a dumb Telnet connection much of the time.

There's a thought... if your interactions are simple, you might be able to simulate your server using a 3rd party Telnet daemon that will accept anonymous connections and run a simple script. The script could accept any input, send back your canned responses.

If your application is simple enough you might also try the simple echo service or echo daemon supported by most operating systems. This normally runs over TCP port 7, but remapping the port is easy using TCPTap, plus you'd get a capture of your data. It might not be too hard to relocate echo to another TCP port either if you have no need to log the traffic.

Like I said before, I've been in almost EXACTLY the boat you're in now several times. I was writing a client, and I didn't have access to the server for it during development because it was behind a firewall. There was no way they'd open the port I needed, so I wrote a simulator. That meant another round of testing later on behind the firewall of course. But at least I got the gross bugs out of the program using the sim.

I didn't mean to imply you don't know what you're doing earlier. I've just had to bail out too many newbies who wrote software ignoring segmentation: Tested fine over ethernet but failed over WAN connections, etc. Worked with their test messages but failed on longer production messages... you can imagine.