> >>>>> "Arnt" == Arnt Gulbrandsen <agulbra@troll.no> writes:
>
>
> Arnt> Since several people have expressed distrust in the ftpd, I
> Arnt> tried using ttcp and reproduced the problem. (ttcp is a
> Arnt> smll ttcp test program, ftp://sgi.sgi.com/sgi/src/ttcp/ has
> Arnt> source.)
>
> Arnt> Here's the part of a packet trace. On one end
> Arnt> (mail.linpro.no, 2.0.28), I did
>
> Arnt> $ ttcp -t -p 5007 -b 51200 thud.freebsd.org <
> Arnt> xppp1B-x86-ELF.gz
>
> Arnt> and on the other (thud.freebsd.org, freebsd 3.0-current):
>
> Arnt> $ ./ttcp -r -p 5007 -b 51200 | tar ztf -
>
> Arnt> and the resulting output shows clearly that something is
> Arnt> wrong, but not, to me, what. (I get essentially the same
> Arnt> behaviour as this when both ends run linux 2.0.28, btw.)
>
> [snip]
>
> 21:42:05.444548 mail.linpro.no.1064 > thud.FreeBSD.ORG.5007: . 144541:146001(1460) ack 1 win 15360
> 21:42:05.444548 mail.linpro.no.1064 > thud.FreeBSD.ORG.5007: P 146001:147461(1460) ack 1 win 15360
> 21:42:06.024548 thud.FreeBSD.ORG.5007 > mail.linpro.no.1064: . ack 144541 win 17520 (DF)
> 21:42:07.704548 mail.linpro.no.1064 > thud.FreeBSD.ORG.5007: . 144541:146001(1460) ack 1 win 15360
> 21:42:12.244548 mail.linpro.no.1064 > thud.FreeBSD.ORG.5007: . 144541:146001(1460) ack 1 win 15360
> 21:42:21.324548 mail.linpro.no.1064 > thud.FreeBSD.ORG.5007: . 144541:146001(1460) ack 1 win 15360
> 21:42:39.484548 mail.linpro.no.1064 > thud.FreeBSD.ORG.5007: . 144541:146001(1460) ack 1 win 15360
> 21:43:15.794548 mail.linpro.no.1064 > thud.FreeBSD.ORG.5007: . 144541:146001(1460) ack 1 win 15360
> 21:44:28.424548 mail.linpro.no.1064 > thud.FreeBSD.ORG.5007: . 144541:146001(1460) ack 1 win 15360
> 21:46:28.404548 mail.linpro.no.1064 > thud.FreeBSD.ORG.5007: . 144541:146001(1460) ack 1 win 15360
>
> two things could have possibly happened:
> 1) you lost network connectivity to thud.freebsd.org
> 2) that packet checksum is wrong
>
> 1) can happen because of packet filters for instance ;-)
>
> If you suspect of 2) please grab the packet with tcpdump -x option and
> compute the TCP checksum over it...
> (you can also edit tcp_ipv4.c and turn checksum debugging on, and for instance
> try a C version of the csum instead of the assembler one).
>
> ./Pedro.
>
What happens to linux TCP if network connectivity is temporarily lost,
let's say for a few seconds? Existing TCP connections seem to die off
when network connectivity is lost for more than 15 seconds, and never
recover onwards (tested with 1.3.55, not sure newer kernels exhibit this
problem or not).
This is important because wireless interfaces may be temporarily out of
radio coverage and lose network connectivity for that time period.
In Mobile-IP, a linux machine can move from one IP network to another IP
network. Will the consequent change of routes affect linux TCP in any
adverse way? (for instance timing, state of TCP connection)
Is there any documentation on the net regarding the implementation of
Linux's TCP/IP stack, particularly the TCP portion?
Thanks,
CCFoo
More info about a Mobile-IP implementation for Linux can be obtained from
http://mip.ee.nus.sg
Another implementation is available in
http://anchor.cs.binghamton.edu/~mobileip