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
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
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 -
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 -
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 sent for the
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 sent
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
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
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 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 it just
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 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'
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
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 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' and
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
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
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
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
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,
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?
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
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
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
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
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?
Where
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?
Loopback doesn't
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
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
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
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
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
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
On Jan 30, 2008 9:47 PM, Patrick McHardy [EMAIL PROTECTED] wrote:
A binary dump would be more useful:
tcpdump -i lo -w outfile
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; i1001;i++)); do echo $i |
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
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 loopback
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 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, I got
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
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
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
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
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
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
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
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 bisect
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
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
53 matches
Mail list logo
