Testing a TCP/IP implementation

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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.

Re: Testing a TCP/IP implementation
Quoted text here. Click to load it

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 ( www.ethereal.com ) 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

Re: Testing a TCP/IP implementation
Hi!

Quoted text here. Click to load it

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 (www.nmap.org), 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.

Quoted text here. Click to load it

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 /


Re: Testing a TCP/IP implementation

Quoted text here. Click to load it

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


Re: Testing a TCP/IP implementation
Quoted text here. Click to load it

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.



Re: Testing a TCP/IP implementation

Quoted text here. Click to load it

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 /


Re: Testing a TCP/IP implementation
Quoted text here. Click to load it

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.

Re: Testing a TCP/IP implementation
Hi!

Quoted text here. Click to load it

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 /


Site Timeline