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 of
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
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
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
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
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 in there
