Actually, I don't know -- and looking deeper it's not what I originally
thought.
What I do know: when the netbsd box talks to my 2.1.131 box, 2.1.131
ignores the first copy of each tcp data from the remote machine.
Other machines (2.0.* linux and solaris) don't experience this problem
(and I presume that if lots of people saw it that I'd have encountered
some documentation on the issue).
The netbsd box's tcpdump reports something different for the timestamp
on the afflicted packets than what the linux box reports. Then again,
there don't appear to be any timestamps on the packets between the netbsd
box and a linux machine which doesn't experience this packet lossage.
Also, I just last night took a look at the packets en-route between the
two boxes, and a linux 2.0 box in the middle sees the same timestamps
on the packets in flight as 2.1.131.
So, my current hypothesis is that it's the netbsd box that's screwed up,
but I'd like to turn off whatever the option is that made timestamps show
up for connections to netbsd so I can get a decent connection between
these two boxes. [If anyone knows enough about netbsd to tell me how
to fix the remote machine, I'll pass the information along, but I at
least want to understand this well enough that I don't go saying wild
and crazy things anymore about this particular subject.]
> > [Last time I posted tcpdumps from both ends of a tcp connection, showing
> > bad timestamps on the corrupted packets. Should I post that kind of
> > thing again? Something else?]
>
> I've still got them, I didnt pay it much attention originally.
Well, I no longer think it's packet corruption, but it is a persistent
problem.
Thanks,
-- Raul- 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/