Hi,
found it.
This is the tcpdump, for your edification.
Note that many packets have "push" set for no good reason,
which generally indicates dropped packets if we're doing a bulk
transfer. But all packets that are visible in the dump reached their
destination..!
The culprit turns out to be the
Matthias Urlichs wrote:
Hi,
Herbert Xu:
Matthias Urlichs <[EMAIL PROTECTED]> wrote:
Any ideas? Is the sending program doing something stupid? If so, what?
Probably. Since you're on the sender's side (192.109.x.x I presume) why
don't you do a strace on the sending process and t
Matthias Urlichs <[EMAIL PROTECTED]> wrote:
>
> The stuff I see in there doesn't look stupid to me.
>
> accept(...) = 216
> setsockopt(216, SOL_IP, IP_TOS, [8], 4) = 0
> setsockopt(216, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> setsockopt(216, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
> followed by a bunch
Hi,
Herbert Xu:
> Matthias Urlichs <[EMAIL PROTECTED]> wrote:
> >
> > Any ideas? Is the sending program doing something stupid? If so, what?
>
> Probably. Since you're on the sender's side (192.109.x.x I presume) why
> don't you do a strace on the sending process and tell us?
>
The stuff I see
Matthias Urlichs <[EMAIL PROTECTED]> wrote:
>
> Any ideas? Is the sending program doing something stupid? If so, what?
Probably. Since you're on the sender's side (192.109.x.x I presume) why
don't you do a strace on the sending process and tell us?
Cheers,
--
Visit Openswan at http://www.opens
Hello,
I have a problem with a TCP connection here which just doesn't
want to have multiple packets on the wire.
I have verified that the sender has enough buffered data (netstat -t
shows 8..10k send buffer). There's no packet loss. The tcpdump
(attached) shows that the receiver increases its win
