* Checksum problem in tcp-window-tracking
@ 2004-06-12 19:32 Martin Josefsson
2004-06-13 4:28 ` Patrick McHardy
2004-06-14 8:23 ` Jozsef Kadlecsik
0 siblings, 2 replies; 11+ messages in thread
From: Martin Josefsson @ 2004-06-12 19:32 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: Netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]
Hi Jozsef
Upgraded my kernel and started seeing lots of complaints from the
tcp-window-tracking code.
I only get the complaints on localhost<->localhost traffic, all other
traffic is complaint-free and working great :)
Jun 12 21:14:30 tux ip_conntrack_tcp: INVALID: bad T IN= OUT= MAC=
SRC=127.0.0.1 DST=127.0.0.1 LEN=93 TOS=00 PREC=0x00 TTL=64 ID=6306 DF
PROTO=TCP SPT=6667 DPT=32813 SEQ=2226635880 ACK=2237541190 WINDOW=4095
ACK PSH URGP=0
"bad T" can only be this code from unclean()
/* Checksum invalid? Ignore. */
/* FIXME: Source route IP option packets --RR */
if (csum_tcpudp_magic(iph->saddr, iph->daddr,
tcplen, IPPROTO_TCP,
skb->ip_summed == CHECKSUM_HW
? skb->csum
: skb_checksum(skb, iph->ihl*4, tcplen, 0))) {
if (NET_RATELIMIT(ip_ct_tcp_log_invalid))
nf_log_packet(PF_INET, 0, skb, NULL, NULL,
"ip_conntrack_tcp: INVALID: "
"bad TCP checksum ");
return 1;
}
According to tcpdump the checksum is correct (otherwise we'd have a
serious bug in the tcp-stack :)
Any ideas?
--
/Martin
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Checksum problem in tcp-window-tracking
2004-06-12 19:32 Checksum problem in tcp-window-tracking Martin Josefsson
@ 2004-06-13 4:28 ` Patrick McHardy
2004-06-13 20:15 ` Jozsef Kadlecsik
2004-06-14 8:23 ` Jozsef Kadlecsik
1 sibling, 1 reply; 11+ messages in thread
From: Patrick McHardy @ 2004-06-13 4:28 UTC (permalink / raw)
To: Martin Josefsson; +Cc: Jozsef Kadlecsik, Netfilter-devel
Martin Josefsson wrote:
> Hi Jozsef
>
> Upgraded my kernel and started seeing lots of complaints from the
> tcp-window-tracking code.
>
> I only get the complaints on localhost<->localhost traffic, all other
> traffic is complaint-free and working great :)
>
> Jun 12 21:14:30 tux ip_conntrack_tcp: INVALID: bad T IN= OUT= MAC=
> SRC=127.0.0.1 DST=127.0.0.1 LEN=93 TOS=00 PREC=0x00 TTL=64 ID=6306 DF
> PROTO=TCP SPT=6667 DPT=32813 SEQ=2226635880 ACK=2237541190 WINDOW=4095
> ACK PSH URGP=0
>
> "bad T" can only be this code from unclean()
>
> /* Checksum invalid? Ignore. */
> /* FIXME: Source route IP option packets --RR */
> if (csum_tcpudp_magic(iph->saddr, iph->daddr,
> tcplen, IPPROTO_TCP,
> skb->ip_summed == CHECKSUM_HW
> ? skb->csum
> : skb_checksum(skb, iph->ihl*4, tcplen, 0))) {
> if (NET_RATELIMIT(ip_ct_tcp_log_invalid))
> nf_log_packet(PF_INET, 0, skb, NULL, NULL,
> "ip_conntrack_tcp: INVALID: "
> "bad TCP checksum ");
> return 1;
> }
>
> According to tcpdump the checksum is correct (otherwise we'd have a
> serious bug in the tcp-stack :)
>
> Any ideas?
>
It probably fails on the outgoing path, where the meaning of skb->csum
is different. When CHECKSUM_HW on an outgoing packet is set, the device
should compute and store the checksum at skb->h.raw + skb->csum. tcp
sets CHECKSUM_HW in tcp_sendmsg() and do_tcp_sendpages() when the device
has NETIF_F_NO_CSUM set. Using skb_checksum() unconditionally should
fix it.
Regards
Patrick
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Checksum problem in tcp-window-tracking
2004-06-13 4:28 ` Patrick McHardy
@ 2004-06-13 20:15 ` Jozsef Kadlecsik
2004-06-15 13:14 ` Jozsef Kadlecsik
0 siblings, 1 reply; 11+ messages in thread
From: Jozsef Kadlecsik @ 2004-06-13 20:15 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Martin Josefsson, Netfilter-devel
On Sun, 13 Jun 2004, Patrick McHardy wrote:
> > I only get the complaints on localhost<->localhost traffic, all other
> > traffic is complaint-free and working great :)
> >
> > Jun 12 21:14:30 tux ip_conntrack_tcp: INVALID: bad T IN= OUT= MAC=
> > SRC=127.0.0.1 DST=127.0.0.1 LEN=93 TOS=00 PREC=0x00 TTL=64 ID=6306 DF
> > PROTO=TCP SPT=6667 DPT=32813 SEQ=2226635880 ACK=2237541190 WINDOW=4095
> > ACK PSH URGP=0
> >
> > "bad T" can only be this code from unclean()
> >
> > /* Checksum invalid? Ignore. */
> > /* FIXME: Source route IP option packets --RR */
> > if (csum_tcpudp_magic(iph->saddr, iph->daddr,
> > tcplen, IPPROTO_TCP,
> > skb->ip_summed == CHECKSUM_HW
> > ? skb->csum
> > : skb_checksum(skb, iph->ihl*4, tcplen, 0))) {
> > if (NET_RATELIMIT(ip_ct_tcp_log_invalid))
> > nf_log_packet(PF_INET, 0, skb, NULL, NULL,
> > "ip_conntrack_tcp: INVALID: "
> > "bad TCP checksum ");
> > return 1;
> > }
> >
> > According to tcpdump the checksum is correct (otherwise we'd have a
> > serious bug in the tcp-stack :)
>
> It probably fails on the outgoing path, where the meaning of skb->csum
> is different. When CHECKSUM_HW on an outgoing packet is set, the device
> should compute and store the checksum at skb->h.raw + skb->csum. tcp
> sets CHECKSUM_HW in tcp_sendmsg() and do_tcp_sendpages() when the device
> has NETIF_F_NO_CSUM set. Using skb_checksum() unconditionally should
> fix it.
Thank you both the report and the explanation. I'm going to fix it
by checking the hook in order not to loose the fast path in the
hardware-checksummed case.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Checksum problem in tcp-window-tracking
2004-06-13 20:15 ` Jozsef Kadlecsik
@ 2004-06-15 13:14 ` Jozsef Kadlecsik
2004-06-15 18:32 ` Patrick McHardy
0 siblings, 1 reply; 11+ messages in thread
From: Jozsef Kadlecsik @ 2004-06-15 13:14 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Martin Josefsson, Netfilter-devel
On Sun, 13 Jun 2004, Jozsef Kadlecsik wrote:
> On Sun, 13 Jun 2004, Patrick McHardy wrote:
>
> > > I only get the complaints on localhost<->localhost traffic, all other
> > > traffic is complaint-free and working great :)
> > >
> > > Jun 12 21:14:30 tux ip_conntrack_tcp: INVALID: bad T IN= OUT= MAC=
> > > SRC=127.0.0.1 DST=127.0.0.1 LEN=93 TOS=00 PREC=0x00 TTL=64 ID=6306 DF
> > > PROTO=TCP SPT=6667 DPT=32813 SEQ=2226635880 ACK=2237541190 WINDOW=4095
> > > ACK PSH URGP=0
> Thank you both the report and the explanation. I'm going to fix it
> by checking the hook in order not to loose the fast path in the
> hardware-checksummed case.
I committed the fixed version of the patch in cvs. Besides the fix the
talkative log messages were trimmed in order to fit (better) into the
ULOG buffer.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Checksum problem in tcp-window-tracking
2004-06-15 13:14 ` Jozsef Kadlecsik
@ 2004-06-15 18:32 ` Patrick McHardy
2004-06-15 18:51 ` Martin Josefsson
2004-06-15 19:06 ` Jozsef Kadlecsik
0 siblings, 2 replies; 11+ messages in thread
From: Patrick McHardy @ 2004-06-15 18:32 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: Martin Josefsson, Netfilter-devel
Hi Jozsef,
Jozsef Kadlecsik wrote:
> I committed the fixed version of the patch in cvs. Besides the fix the
> talkative log messages were trimmed in order to fit (better) into the
> ULOG buffer.
I think there is still a problem.
+ if (csum_tcpudp_magic(iph->saddr, iph->daddr,
+ tcplen, IPPROTO_TCP,
+ skb->ip_summed == CHECKSUM_HW
+ && hooknum == NF_IP_PRE_ROUTING
+ ? skb->csum
+ : skb_checksum(skb, iph->ihl*4, tcplen,
0))) {
On the outgoing path, the NIC is supposed to checksum the packet when
CHECKSUM_HW is set, so it hasn't got a valid checksum when the check is
performed. Do we need to check the checksum in LOCAL_OUT at all ?
Other than from raw-sockets, invalid packets can not occur.
Regards
Patrick
PS: Martin, how did you trigger these errors ?
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Checksum problem in tcp-window-tracking
2004-06-15 18:32 ` Patrick McHardy
@ 2004-06-15 18:51 ` Martin Josefsson
2004-06-15 19:06 ` Jozsef Kadlecsik
1 sibling, 0 replies; 11+ messages in thread
From: Martin Josefsson @ 2004-06-15 18:51 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Jozsef Kadlecsik, Netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]
On Tue, 2004-06-15 at 20:32, Patrick McHardy wrote:
Hi Patrick
> Jozsef Kadlecsik wrote:
> > I committed the fixed version of the patch in cvs. Besides the fix the
> > talkative log messages were trimmed in order to fit (better) into the
> > ULOG buffer.
>
> I think there is still a problem.
>
> + if (csum_tcpudp_magic(iph->saddr, iph->daddr,
> + tcplen, IPPROTO_TCP,
> + skb->ip_summed == CHECKSUM_HW
> + && hooknum == NF_IP_PRE_ROUTING
> + ? skb->csum
> + : skb_checksum(skb, iph->ihl*4, tcplen,
> 0))) {
>
> On the outgoing path, the NIC is supposed to checksum the packet when
> CHECKSUM_HW is set, so it hasn't got a valid checksum when the check is
> performed. Do we need to check the checksum in LOCAL_OUT at all ?
> Other than from raw-sockets, invalid packets can not occur.
>
> Regards
> Patrick
>
> PS: Martin, how did you trigger these errors ?
Upgraded the kernel on my desktop-machine :)
Kernel 2.6.7-rc3-bk4 + tcp-windowtracking without the latest change made
by Jozsef.
It's just local imap and irc servers (bitlbee for icq) and clients
connecting to 127.0.0.1
I get one logentry per packet or so, in both directions.
I now have 28.000 lines of these complains in a logfile :)
--
/Martin
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Checksum problem in tcp-window-tracking
2004-06-15 18:32 ` Patrick McHardy
2004-06-15 18:51 ` Martin Josefsson
@ 2004-06-15 19:06 ` Jozsef Kadlecsik
1 sibling, 0 replies; 11+ messages in thread
From: Jozsef Kadlecsik @ 2004-06-15 19:06 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Martin Josefsson, Netfilter-devel
Hi Patrick,
On Tue, 15 Jun 2004, Patrick McHardy wrote:
> > I committed the fixed version of the patch in cvs. Besides the fix the
> > talkative log messages were trimmed in order to fit (better) into the
> > ULOG buffer.
>
> I think there is still a problem.
>
> + if (csum_tcpudp_magic(iph->saddr, iph->daddr,
> + tcplen, IPPROTO_TCP,
> + skb->ip_summed == CHECKSUM_HW
> + && hooknum == NF_IP_PRE_ROUTING
> + ? skb->csum
> + : skb_checksum(skb, iph->ihl*4, tcplen,
> 0))) {
>
> On the outgoing path, the NIC is supposed to checksum the packet when
> CHECKSUM_HW is set, so it hasn't got a valid checksum when the check
> is performed. Do we need to check the checksum in LOCAL_OUT at all ?
> Other than from raw-sockets, invalid packets can not occur.
Finally, finally I see. Then we have to get rid of the checksum checking
on the outgoing path, indeed:
+ if (hooknum == NF_IP_PRE_ROUTING
+ && csum_tcpudp_magic(iph->saddr, iph->daddr,
+ tcplen, IPPROTO_TCP,
+ skb->ip_summed == CHECKSUM_HW
+ ? skb->csum
+ : skb_checksum(skb, iph->ihl*4, tcplen, 0))) {
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Checksum problem in tcp-window-tracking
2004-06-12 19:32 Checksum problem in tcp-window-tracking Martin Josefsson
2004-06-13 4:28 ` Patrick McHardy
@ 2004-06-14 8:23 ` Jozsef Kadlecsik
2004-06-14 8:43 ` Martin Josefsson
1 sibling, 1 reply; 11+ messages in thread
From: Jozsef Kadlecsik @ 2004-06-14 8:23 UTC (permalink / raw)
To: Martin Josefsson; +Cc: Netfilter-devel
Hi Martin,
On Sat, 12 Jun 2004, Martin Josefsson wrote:
> I only get the complaints on localhost<->localhost traffic, all other
> traffic is complaint-free and working great :)
>
> Jun 12 21:14:30 tux ip_conntrack_tcp: INVALID: bad T IN= OUT= MAC=
> SRC=127.0.0.1 DST=127.0.0.1 LEN=93 TOS=00 PREC=0x00 TTL=64 ID=6306 DF
> PROTO=TCP SPT=6667 DPT=32813 SEQ=2226635880 ACK=2237541190 WINDOW=4095
> ACK PSH URGP=0
>
> "bad T" can only be this code from unclean()
Why did the prefix get truncated to 'ip_conntrack_tcp: INVALID: bad T'???
Anything special with your kernel?
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Checksum problem in tcp-window-tracking
2004-06-14 8:23 ` Jozsef Kadlecsik
@ 2004-06-14 8:43 ` Martin Josefsson
2004-06-14 8:57 ` Jozsef Kadlecsik
0 siblings, 1 reply; 11+ messages in thread
From: Martin Josefsson @ 2004-06-14 8:43 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: Netfilter-devel
On Mon, 14 Jun 2004, Jozsef Kadlecsik wrote:
> Hi Martin,
Hi Jozsef
> > Jun 12 21:14:30 tux ip_conntrack_tcp: INVALID: bad T IN= OUT= MAC=
> > SRC=127.0.0.1 DST=127.0.0.1 LEN=93 TOS=00 PREC=0x00 TTL=64 ID=6306 DF
> > PROTO=TCP SPT=6667 DPT=32813 SEQ=2226635880 ACK=2237541190 WINDOW=4095
> > ACK PSH URGP=0
> >
> > "bad T" can only be this code from unclean()
>
> Why did the prefix get truncated to 'ip_conntrack_tcp: INVALID: bad T'???
> Anything special with your kernel?
No nothing special, using ULOG for logging.
I thought it was weird as well but I didn't trace the problem. Maybe I'll
look at it later today.
/Martin
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Checksum problem in tcp-window-tracking
2004-06-14 8:43 ` Martin Josefsson
@ 2004-06-14 8:57 ` Jozsef Kadlecsik
2004-06-14 8:58 ` Martin Josefsson
0 siblings, 1 reply; 11+ messages in thread
From: Jozsef Kadlecsik @ 2004-06-14 8:57 UTC (permalink / raw)
To: Martin Josefsson; +Cc: Netfilter-devel
On Mon, 14 Jun 2004, Martin Josefsson wrote:
> > Why did the prefix get truncated to 'ip_conntrack_tcp: INVALID: bad T'???
> > Anything special with your kernel?
>
> No nothing special, using ULOG for logging.
> I thought it was weird as well but I didn't trace the problem. Maybe I'll
> look at it later today.
I found it: the ulog prefix length is 32. I'll try to cut back the strings
to fit into that buffer.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2004-06-15 19:06 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-06-12 19:32 Checksum problem in tcp-window-tracking Martin Josefsson
2004-06-13 4:28 ` Patrick McHardy
2004-06-13 20:15 ` Jozsef Kadlecsik
2004-06-15 13:14 ` Jozsef Kadlecsik
2004-06-15 18:32 ` Patrick McHardy
2004-06-15 18:51 ` Martin Josefsson
2004-06-15 19:06 ` Jozsef Kadlecsik
2004-06-14 8:23 ` Jozsef Kadlecsik
2004-06-14 8:43 ` Martin Josefsson
2004-06-14 8:57 ` Jozsef Kadlecsik
2004-06-14 8:58 ` Martin Josefsson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.