<SNIP>
> This is something of crazy and should be a bug in porcupine or in the
> middle man.
>
> >and porcupine is waiting for my ack. Does it look like receiver troubles
> >to you?.. or is this just coincidence and tcpdump is being a PITA? It
>
> Don't know. Trusting the SOCK_PACKET code looks like it's a sender bug to
> me.
>
> >Anyone see exactly this problem on a _non_ isdn connection?
>
> Really yesterday I tried an ls in /pub/security and it was very slow (as
> _everything_ else from here) but worked after a while.
>
> Would it be possible that porky (or some other men in the middle) when
> receive the syn-ack it just does (jiffies - tsecr) and use the computed
> value to set a bogus RTO and/or to do some other mess? I don't think it's
> the case but to give a try I changed the 2.2.2-pre2 linux TCP stack to do
> exactly what porcupine does (reverse engeneered from the tcpdump, I don't
> have the time to see which OS is running porcupine) in the synack
> timestamp case.
>
> You may want to give a try to this my patch and see if the bad behavior
> will go away.
Andrea, thank you, the patch fixed the problems I was having. I have a
cable modem connection to the internet. Without the patch ftp would
stall
(to any server), pings response would go to 12 Seconds (12000 mS), and I
would have some problems using sitecopy to a local server (on my
internal
LAN).
With the patch, ftp's no longer stall and ping response is back to 83 ms
for router (next hop) and ~300 ms for servers outside my ISP.
-- Linux Home Automation Neil Cherry ncherry@home.net http://members.home.net/ncherry (Text only) http://meltingpot.fortunecity.com/lightsey/52 (Graphics)- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/