From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Thu, 2 Aug 2007 12:23:23 +0300 (EEST)
...Seriously, somebody else than me is probably better in suggesting what
could cause the discarding at the SERVER in this case. SNMP stuff Dave was
asking could help, you can find them from
On Tue, 31 Jul 2007, Darryl L. Miles wrote:
I've been able to capture a tcpdump from both ends during the problem and its
my belief there is a bug in 2.6.20.1 (at the client side) in that it issues a
SACK option for an old sequence which the current window being advertised is
beyond it. This
Ilpo Järvinen wrote:
On Tue, 31 Jul 2007, Darryl L. Miles wrote:
I've been able to capture a tcpdump from both ends during the problem and its
my belief there is a bug in 2.6.20.1 (at the client side) in that it issues a
SACK option for an old sequence which the current window being advertised
...I dropped lkml, it's useless to bother them with this network related
stuff...
On Thu, 2 Aug 2007, Darryl Miles wrote:
Ilpo Järvinen wrote:
On Tue, 31 Jul 2007, Darryl L. Miles wrote:
[...RFC bashing, snip...]
* The older linux kernel for not being 100% SACK RFC compliant in its
I've been able to capture a tcpdump from both ends during the problem
and its my belief there is a bug in 2.6.20.1 (at the client side) in
that it issues a SACK option for an old sequence which the current
window being advertised is beyond it. This is the most concerning issue
as the
Hi,
[CCing netdev as it's where people competent on the subject are]
On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote:
CLIENT = Linux 2.6.20.1-smp [Customer build]
SERVER = Linux 2.6.9-55.ELsmp [Red Hat Enterprise Linux AS release 4
(Nahant Update 5)]
The problems start
On Sun, 29 Jul 2007, Willy Tarreau wrote:
On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote:
CLIENT = Linux 2.6.20.1-smp [Customer build]
SERVER = Linux 2.6.9-55.ELsmp [Red Hat Enterprise Linux AS release 4
(Nahant Update 5)]
The problems start around time index
On Sun, Jul 29, 2007 at 11:26:00AM +0300, Ilpo Järvinen wrote:
On Sun, 29 Jul 2007, Willy Tarreau wrote:
On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote:
CLIENT = Linux 2.6.20.1-smp [Customer build]
SERVER = Linux 2.6.9-55.ELsmp [Red Hat Enterprise Linux AS release 4
From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Sun, 29 Jul 2007 11:26:00 +0300 (EEST)
Is this reproducable? Can you somehow verify that the packets CLIENT is
sending are indeed received by the SERVER...?
One possibility is drops due to checksum errors on the receiver, this
tends to pop up from
On Jul 29 2007 08:45, Willy Tarreau wrote:
On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote:
CLIENT = Linux 2.6.20.1-smp [Customer build]
SERVER = Linux 2.6.9-55.ELsmp [Red Hat Enterprise Linux AS release 4
(Nahant Update 5)]
The problems start around time index
On Sun, 29 Jul 2007, Willy Tarreau wrote:
On Sun, Jul 29, 2007 at 11:26:00AM +0300, Ilpo Järvinen wrote:
On Sun, 29 Jul 2007, Willy Tarreau wrote:
On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote:
CLIENT = Linux 2.6.20.1-smp [Customer build]
SERVER = Linux
On Sun, Jul 29, 2007 at 12:28:04PM +0300, Ilpo Järvinen wrote:
(...)
Limitation for 48 byte segments? You have to be kidding... :-) But yes,
it seems that one of the directions is dropping packets for some reason
though I would not assume MTU limitation... Or did you mean some other
On Sun, 29 Jul 2007, Willy Tarreau wrote:
On Sun, Jul 29, 2007 at 12:28:04PM +0300, Ilpo Järvinen wrote:
[...snip...]
BTW, some information are missing. It would have been better if the trace
had been read with tcpdump -Svv. We would have got seq numbers and ttl.
Also, we do not
13 matches
Mail list logo
