David Miller wrote:
From: Jozsef Kadlecsik <[EMAIL PROTECTED]>
Date: Thu, 14 Feb 2008 16:02:29 +0100 (CET)
Hi,
On Sun, 10 Feb 2008, Jeff Chua wrote:
Please note the lastest git commit is missing one part (which was in Jozsef's
original patch).
Sorry everyone, that's my fault: the patch I sen
From: Jozsef Kadlecsik <[EMAIL PROTECTED]>
Date: Thu, 14 Feb 2008 16:02:29 +0100 (CET)
> Hi,
>
> On Sun, 10 Feb 2008, Jeff Chua wrote:
>
> > Please note the lastest git commit is missing one part (which was in
> > Jozsef's
> > original patch).
>
> Sorry everyone, that's my fault: the patch I s
Hi,
On Sun, 10 Feb 2008, Jeff Chua wrote:
> Please note the lastest git commit is missing one part (which was in Jozsef's
> original patch).
Sorry everyone, that's my fault: the patch I sent for the stable branch
was correct, however I mistyped a state in the patch for the newest
git tree - Je
On Feb 5, 2008 9:47 PM, Patrick McHardy wrote:
On Feb 5, 2008 4:16 PM, Jozsef Kadlecsik wrote:
Patrick, I suppose you need a patch against the latest git, don't you?
Yes, please. I'll take you first patch for -stable though if you
send me a Signed-off-by: line.
Please note the lastest git com
Jozsef Kadlecsik wrote:
On Tue, 5 Feb 2008, Jeff Chua wrote:
On Feb 5, 2008 4:17 AM, Jozsef Kadlecsik <[EMAIL PROTECTED]> wrote:
Actively closed connections are not handled properly, i.e. the initiator of
the active close should not be taken into account. So could you give a try
to the patch
On Tue, 5 Feb 2008, Jeff Chua wrote:
> On Feb 5, 2008 4:17 AM, Jozsef Kadlecsik <[EMAIL PROTECTED]> wrote:
>
> > Actively closed connections are not handled properly, i.e. the initiator of
> > the active close should not be taken into account. So could you give a try
> > to the patch below? Does
On Feb 5, 2008 4:17 AM, Jozsef Kadlecsik <[EMAIL PROTECTED]> wrote:
Actively closed connections are not handled properly, i.e. the initiator
of the active close should not be taken into account. So could you give
a try to the patch below? Does it just suppress the 'invalid packed
ignored' an
Hi,
On Mon, 4 Feb 2008, Jeff Chua wrote:
> > Attached are the dump files mentioned.
>
> Not sure whether the attached files got uploaded. So, I'm sending this one
> more time.
I could reproduce the slow-down by a loop of socat commands. The dump you
sent looks exactly like the traces I got at
On Feb 2, 2008 10:44 PM, Jozsef Kadlecsik <[EMAIL PROTECTED]> wrote:
> Could I ask you to make two another tests? (I have been unable to
> reproduce the bug so far, but it must be my fault.)
You need to send more than 510 jobs to see the problem.
> In both cases enable loggin invalid messages as
Hi Jeff,
On Fri, 1 Feb 2008, Jeff Chua wrote:
> I recaptured it again, and attached are the logs.
[...]
Thank you! One can see a plain connection-initiating SYN, which triggers
the message. No reply from the server, then three seconds later comes a
retransmitted SYN and immediately after the S
David Newall wrote:
I'm not debating that checksums are wrong. The question was how and
where? It's not as if there are any unreliable communication paths in a
loopback interface, so it's surprising that they could be wrong. How? Where?
As I said, loopback doesn't perform full checksum calcula
David Miller wrote:
> From: David Newall <[EMAIL PROTECTED]>
> Date: Fri, 01 Feb 2008 11:17:14 +1030
>
>
>> Patrick McHardy wrote:
>>
>>> Jozsef Kadlecsik wrote:
>>>
Strange, but there are a lot of incorrect checksum packets. How does
it come on the loopback interface?
From: David Newall <[EMAIL PROTECTED]>
Date: Fri, 01 Feb 2008 11:17:14 +1030
> Patrick McHardy wrote:
> > Jozsef Kadlecsik wrote:
> >> Strange, but there are a lot of incorrect checksum packets. How does
> >> it come on the loopback interface?
> >
> > Loopback doesn't perform full checksumming, so
Patrick McHardy wrote:
> Jozsef Kadlecsik wrote:
>> Strange, but there are a lot of incorrect checksum packets. How does
>> it come on the loopback interface?
>
> Loopback doesn't perform full checksumming, so thats expected.
The question remains: How do loopback packets get incorrect checksum?
W
Jozsef Kadlecsik wrote:
Hi Jeff,
On Thu, 31 Jan 2008, Jeff Chua wrote:
On the bad run, I got the following message ...
boston kernel: nf_ct_tcp: invalid packed ignored IN= OUT=
SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=8162
DF PROTO=TCP SPT=1016 DPT=515 SEQ=3834958843 AC
Hi Jeff,
On Thu, 31 Jan 2008, Jeff Chua wrote:
> On the bad run, I got the following message ...
>
> boston kernel: nf_ct_tcp: invalid packed ignored IN= OUT=
> SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=8162
> DF PROTO=TCP SPT=1016 DPT=515 SEQ=3834958843 ACK=0 WINDOW=32792
On Jan 31, 2008 11:25 AM, Patrick McHardy <[EMAIL PROTECTED]> wrote:
> Actually its probably the SYN/ACK that is dropped. Please try whether
>
> modprobe ipt_LOG
> echo 255 >/proc/sys/net/netfilter/nf_conntrack_log_invalid
On the good run, I don't get any message, which is good.
On the bad run,
Jeff Chua wrote:
On Jan 31, 2008 10:41 AM, Patrick McHardy <[EMAIL PROTECTED]> wrote:
Thanks. In the dump we can see that connections reusing ports
always have their first SYN dropped and retransmissted three
seconds later. I'm not sure whats causing this yet, do you have
any firewall rules
On Jan 31, 2008 10:41 AM, Patrick McHardy <[EMAIL PROTECTED]> wrote:
> Thanks. In the dump we can see that connections reusing ports
> always have their first SYN dropped and retransmissted three
> seconds later. I'm not sure whats causing this yet, do you have
> any firewall rules that affect loo
Jeff Chua wrote:
On Jan 31, 2008 10:23 AM, Jeff Chua <[EMAIL PROTECTED]> wrote:
Again, using latest linux, one with
17311393f969090ab060540bd9dbe7dc885a76d5 reverted, and the other
without.
Sorry, here's the attached output files.
Thanks. In the dump we can see that connections reus
On Jan 30, 2008 9:47 PM, Patrick McHardy <[EMAIL PROTECTED]> wrote:
> A binary dump would be more useful:
>
> tcpdump -i lo -w
>
> and I guess Jozsef also wants "-s 0" so the full packets are included.
Attached. Again, both runs with this command to print ...
for((i=1; i<1001;i++)); do echo $i
Jeff Chua wrote:
On Jan 29, 2008 6:53 PM, Jozsef Kadlecsik <[EMAIL PROTECTED]> wrote:
As the problem can be reproduced so easily, could you capture a full TCP
session and send the pcap file? Thus it could be analyzed, replayed, etc.
and found the reason why the patch above slows down the printi
On Tue, 29 Jan 2008, Jeff Chua wrote:
> On Jan 28, 2008 7:18 AM, Jeff Chua <[EMAIL PROTECTED]> wrote:
> > I'm sending printing jobs to a network printer (it's actually printing
> > to the localhost simply creating a file), and running this on
> > Linux-2.6.24 will cause the printing to slow down t
2008/1/29 Krzysztof Oledzki <[EMAIL PROTECTED]>:
> Strange. You stated that 2.6.23.12 is OK, however above patch
> was included in 2.6.23.4:
> Are you 100% sure that 2.6.23.12 is OK?
Sorry, my mistake. I had another system on 2.6.23.12 and was not OK,
so I bisected starting from 2.6.23.
git bise
On Tue, 29 Jan 2008, Jeff Chua wrote:
On Jan 28, 2008 7:18 AM, Jeff Chua <[EMAIL PROTECTED]> wrote:
I'm sending printing jobs to a network printer (it's actually printing
to the localhost simply creating a file), and running this on
Linux-2.6.24 will cause the printing to slow down to 1 pri
On Jan 28, 2008 7:18 AM, Jeff Chua <[EMAIL PROTECTED]> wrote:
I'm sending printing jobs to a network printer (it's actually printing
to the localhost simply creating a file), and running this on
Linux-2.6.24 will cause the printing to slow down to 1 print every 3
seconds after printing 500 time
I'm sending printing jobs to a network printer (it's actually printing
to the localhost simply creating a file), and running this on
Linux-2.6.24 will cause the printing to slow down to 1 print every 3
seconds after printing 500 times.
No such symptoms on 2.6.23.12, or 2.6.20.21.
It's repeatable.
27 matches
Mail list logo
