Testing a TCP/IP implementation

Hi Everyone,

I'm wondering about incorporating a TCP/IP stack into a device. I was wondering if there is a proper way to test if the stack works. Is there a mechanism to test (perhaps on a PC) if the TCP/IP stack works?

Any clues on how to get started?

Thanks & Regards Mohit.

Reply to
Mohit Sindhwani
Loading thread data ...

Might be that there are testsuits available but I figure they would not be cheap.

In general, put the device under as heavy load as you can and have as many clients connect as possible - well, force that much more clients try to simultanousely access your device than ever expected. Rigorousely test all device functions during that phase. Observe the behaviour of those connections that are refused AND those that seem to work. Use a protocol analyzer software and check also on this level that your devices replies are within the specs. I can recommend Etheral (

formatting link
) which is freeware for this. Then, make sure to also test it with very very slow connections forcing timeouts by i.e. debugging the oponent side and have the connection die. Force retransmissions of packets on both the client and your devices end. Also include a test where IP pakets get fragmented. With embedded TCP it's likely that you have configured a certain (smaller?) MSS value that asures the device can perform it's tasks. By configuring another host (PC?) in the network to use an even smaller MSS value and sending an ICMP echo request of the biggest size you expect your device to support, you could force IP fragmentation "on the cheap". It's however sometimes much more convenient to use a another device of yours that you configure to say intentionally swap fragments (see Jeremey Benthams book TCP lean for an example of this) and create all other kind of odd / bad traffic. You should specifically create an "evil" version of your firmware that intentionally resends TCP segments, swap their order and so on. If this is a requirement, also check if the stack would survive a syn flood attack. There are enough "hacker tools" around to simulate that. To defend this, probablyy the best thing you could do is to slightly violate RFC793 and have your stack send syn ack in reply to every syn you get without further action. Then, actually start a connection whenever you get an ack back (third stage of the three way handshake) whoes ack sequence number is within some reasonable limitt compared to what initial sequence number you sent in your replies.

On the source code level, try to find ALL spots where dynamical resources are allocated (i.e. memory buffers from a pool or malloc or whatever). Then, check what the code does if no resources are available. A robust implementation will split all tasks into "transactions" that keep the state of the connection in a sane known state and either perform the transaction or then move it on to a later point in time where resources are available. As an example, if you accept an incoming connection, it's wise to check BEFORE you accept the connection that there are enough resources available to at least finish createing a task (or whatever is needed in your system) to come to a state of your protocol (which ever it is) so as the connection could be gracefully terminated or whatever if the need arises. Or as yet another example, say you have to serve a chunk of HTTP data, supress the task up until you are sure that this chunk can be sent and so on. The worest thing that could happen is if your device would just silently close the connection or such and by examining the source code such spots should be easily identifiable. If you find something like this, check if you can fix it or else move on to another product.

If your device still reacts reasonable throughout this process the implementation is definately not that bad :)

I just finished implementing a TCP protocol suite some weeks ago and during the phase of prepareing myself for that task I studied other implementations. Belive me, some of the even quite popular implementations would not pass above tests. Btw, I implemented my own suite because none of the available implementations fullfilled all the requirements I had.

HTH

Markus

Reply to
Markus Zingg

In addition to Markus' excellent run-through, I would also like to add that running hacker tools also is very useful for general stability testing of the stack in general, besides SYN-flood testing. If a stack does not survive a probe e.g. with nmap

formatting link
it is likely that the stack will collapse quite quickly out in the wild since a lot of people do run those tools.

Many tools have various options for sending malformed packets that have been known to be lethal to other stacks (e.g., the "teardrop" attack towards older versions of Windows), and they can be used to test the stability of the stack in question.

I have noticed that many stacks do not support the TCP MSS option which makes it impossible for such a stack to communicate with a stack with a smaller maximum segment size. Also, not many of the smaller stacks are able to do IP fragment reassembly.

Cheers,

/adam

--
Adam Dunkels - http://dunkels.com/adam/
Reply to
Adam Dunkels

One other test that doesn't ever seem to happen on cheap stacks. Bombard it with a variety of broadcast packets, especially MS-Windows file shares traffic. If you don't do anything else, put it on a subnet with a dozen MS-Windows servers and workstations and try to talk to it for 24 hours. If it survives that without losing a connection, you're in good shape. I've used commercial stacks that didn't.

Bob McConnell N2SPP

Reply to
Bob McConnell

If it's a nifty project, write it up as a story and submit it to Slashdot. If it gets accepted and it survives the slashdoting, then it's pretty solid! (Semi-kidding :^)

--
Ron Sharp.
Reply to
Android Cat

While a slashdotting is a quite nice stress-test of a TCP/IP stack, it usually only testing a limited subset of the TCP/IP functionality. Since it mostly involves bombarding a web server on the slashdotted TCP/IP stack, it does not really test how well outbound connections work for instance. Still, it brings some weird traffic to the stack as a lot of people will probe the device and try to bring the stack down by hitting it with various tools.

(I've witnessed a couple a slashdottings myself as a variety of devices running my uIP stack have been slashdotted. And they have all nicely stood up to it ;-)

/adam

--
Adam Dunkels - http://dunkels.com/adam/
Reply to
Adam Dunkels

Hi Everyone,

Thanks for your replies. I see that there are a lot of things that need to be looked at. I'll try and follow through them.

Adam, I visited your site about uIP. I'm wondering if that would meet my needs, specially since you say that it is well documented.

Thanks, everyone. If I get anywhere with this, I'll get back to you guys with the results.

Cheers Mohit.

Reply to
Mohit Sindhwani

All documentation can be downloaded in printable PDF format from the web site, or viewed on-line in HTML. Whether uIP meets your needs or not depends on your particular application - uIP basically trades communication throughput for code size. So if you have a lot of code space to spare and your application needs to send large amounts of data quickly, another larger TCP/IP stack might be better suited. But if you have a very constrained code space, uIP might be a good fit.

/adam

--
Adam Dunkels - http://dunkels.com/adam/
Reply to
Adam Dunkels

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.