I want to porte LwIP to LPC2138.I use GPRS.
If i implement that.How to test the TCP/IP?

>I want to porte LwIP to LPC2138.I use GPRS.
>If i implement that.How to test the TCP/IP?

IMHO you would not have to test the TCP/IP part provided your port is
ok but would focus on the physical layer.

You always could test by building up a connection over GPRS to a
server in your own lan and watch the traffic there. There will be lots
of retransmits, lost segments, delays and the like on a GPRS
connection which is probably not that bat in terms of testing. If you
are lucky you even see fragmented IP packets coming in - something
which is often hard to force/test in local lans.

Another option is to (temporarely) add a network controller chip to
your hardware and then first test the stack this way. However, from
experience I thnink that would be disadvantageous because local lans
are ways faster and many real world issues simply do not happen
because of this. Just make sure to get a volume agreement with your
GPRS provider or else the testing will become expensive :-)

HTH

Markus

Markus Zingg escreveu:

> >I want to porte LwIP to LPC2138.I use GPRS.
> >If i implement that.How to test the TCP/IP?
>
> IMHO you would not have to test the TCP/IP part provided your port is
> ok but would focus on the physical layer.
>
> You always could test by building up a connection over GPRS to a
> server in your own lan and watch the traffic there. There will be lots
> of retransmits, lost segments, delays and the like on a GPRS
> connection which is probably not that bat in terms of testing. If you
> are lucky you even see fragmented IP packets coming in - something
> which is often hard to force/test in local lans.
>
> Another option is to (temporarely) add a network controller chip to
> your hardware and then first test the stack this way. However, from
> experience I thnink that would be disadvantageous because local lans
> are ways faster and many real world issues simply do not happen
> because of this. Just make sure to get a volume agreement with your
> GPRS provider or else the testing will become expensive :-)
>
> HTH
>
> Markus

Marcus,

This method would give an overall testing, which is necessary as a
first step, just because you need the basics to be running to do more
in deep testing.
But then you would be bit in the details, like what happens to me, out
of order packet issues, retransmission timing issues, etc.. The list is
really big.

I think the original question is very important, does exists a tcp
check list for implementations ? Also are there tools that would
those testings ?

Thanks,

>Marcus,
>
>This method would give an overall testing, which is necessary as a
>first step, just because you need the basics to be running to do more
>in deep testing.
>But then you would be bit in the details, like what happens to me, out
>of order packet issues, retransmission timing issues, etc.. The list is
>really big.

Look, implementing (or porting) a TCP stack IMHO requieres to really
have a deep understanding of TCP in the first place, but also fully
understand the stack in question. You then know what said stack is
suposed to to in what situation which gives the list of special cases
to test with this very implementation. The remaining part is somewhat
general like connections being aborted in the middle and what you
mentioned. Out of order segments i.e. can be treated quite simply (and
often are treated this way with lightwight stacks as the one the OP
mentioned). One can simply only accept the "next" segment in sequence
order and drop early ones. It's obvious that the fancier your
implementation gets the more complicated testing is needed. One should
look at all the RFC's around the topic of optimizing TCP to get an
idea. Other issues you may run into are not at all really bound to TCP
by itself like if your stack cleans up all resources propperly under
all thinkable situations (and there are some nasty situations
especially with buffering segments). So again, there are no genreal
guidlines available here.

>I think the original question is very important, does exists a tcp
>check list for implementations ? Also are there tools that would
>those testings ?

Not that I would know of. Might be that there are test tools, but
expect them to be VERY expensive. The market for such a test suite is
very very small ( I mean not so many people implement their own TCP
stack and among them not so many have the money to buy such tools).

Below I list some tests I did as they come to mind in no particular
order. I also don't know if this list is complete but it might s:

- Expose the stack to the common attacks (synflood etc.)
- Put the whole system artificially under heavey load, retest this way
- Put it into an as dirty envireonement as possible
- Plan in enouhg time to have an as intense and as wide spread real
world test as possible.
- Have the stack comunicate over a VPN made by hardware routers along
the comunication path (since this will force IP segmentation provided
you send maximum sized segments).
- Make sure you talk to as many TCP implementations you can find.
- Make sure you find a scenario where one side is anouncing a MSS that
the comunication link does not suport.
- Make your implementation robust enough to survife in above scenario
if yet anouther gateway in this path is filtering out the apropriate
ICMP packets.
- Another nasty issue might be a gateway along the path modifying the
stream and anouncing yet another (bigger) MSS than what the original
oponent does. You can expect nice side effects if such an
implementation is broken (and I know of a router doing such things
which is really brocken).
- Consider the advice given in the original RFC as really important.
Be liberal with what you expect and conservative with what you send
out.

HTH

Markus