conntrack problems

Hi, on a dial-up(56k) machine I'm looking at iptables 1.2.6a with both kernel 2.4.13 and 2.4.18. It's 1 months that I'm having troubles with the conntrack. I have a lot of packets like 'new not syn'(you know what I'm talking about..) with some combos of flags on them:

ACK FIN
ACK PSH FIN
ACK RST
ACK only

They come from connections with web servers like Google.com, SecurityFocus.com and so on and from news server like Powernews.libero.it(Libero is one of the biggest provider in Italy). So, I suspect that, because I've found only few cases like mine, those ones aren't broken at all :)
I think the problem is in my conntrack that loss some(a lot...) of packets. I've used some scripts for the iptables configuration, but it always happen. then, I read about a patch from Rusty some month ago that increase one of the timeouts in the kernel source(It was the TCP_CONNTRACK_CLOSE_WAIT timeout from 60 SECS to 2 MINS). I got it but nothing change. Then, I was thinking it could be really a problem with timeouts, especially because this machine have a poor dial-up access to the Net and it often goes sooo slow...
So I did this: I run tcpdump and capture some sessions that presents the loss of packest trouble. Then I looked at those 'lossed packets' and I noticed that the 'arrival time' of the losed packets had a distance with the one that precede it(and that was traced correctly by iptables) of circa 12-14 SECS(never more than that). I mean:

arrival time type

............    traced packet
18.24.23.4456   traced packet
18.24.35.5678   losed packets
-------------
      12 secs

Then I looked into the kernel source for a timeout that match my(stupid) thought. I've found TCP_CONNTRACK_CLOSE with 10 SECS, and I changed this to 2 MINS. Initially it seems(yep, <cite>I have a dream...</cite> :) to me that the losed packets decrements, but these days I receive costantly a lot of them. With no other ideas, I've played a little with the timeouts, increasing them like this

5 MINS,     /*      TCP_CONNTRACK_CLOSE_WAIT	*/,
1 MINS,     /*      TCP_CONNTRACK_LAST_ACK, */

because I was thinking that maybe the 56k goes really slow some times but I can't see good results :(
So I tried with this stupid methods, have you any advice at this? What it could be? And then, I tried to add the tcp-window-tracking patch(the one in iptables-1.2.6a) by Jozsef Kadlecsik on both 2.4.13 and 2.4.18 but it fails to apply :( What version of iptables(maybe 1.2.7 ???) is known to work properly with 2.4.18 at this time? Maybe a new kernel? What I've to download?

Many thanks for your patience in advice

Hello!

I want to route IPv6 packages differenlty depending on what is in the flowlabel. I've written a flowlabel match module which works flawlessly. I have done an experiment with IPv4 and the TOS flag, where I routed IPv4 packages differently, depending on what was in the TOS flag. I marked packages (fwmark) depending on the TOS flag and set everything up like this:

iptables -A PREROUTING -i eth0 -t mangle -m tos --tos 0 -j MARK --set-mark 1 ip rule add fwmark 1 table host2.out
ip route add default via 192.168.2.3 dev eth2 table host2.out

where 192.168.2.3 is different from what is default gw in the main-table.

All is working fine in the IPv6 case except the last statement (slightly altered for IPv6):

#ip -6 route add default via fec0::192.168.2.3 dev eth2 table host2.out RTNETLINK answers: File exists

Is this approach incompatible with IPv6 in any way? Is there any problems with using IPv6-addresses and the "table" object?

Sincerily,

Gabriel Paues

Hi,

I think this is not a Netfilter-related question, but I try to answer.

The basic rtnetlink functions are supported in IPv6 too, but not all. Configuration options for IPv4:
- TCP/IP networking
- IP: multicasting
- IP: advanced router
- IP: policy routing
- IP: use netfilter MARK value as routing key
With this You set the CONFIG_IP_ROUTE_FWMARK flag in the configuration. This flag is interperted in the IPv4 code, but its whole function is missing from the IPv6 code.

The related files and structures:
/usr/src/linux/net/ipv4/devinet.c
static struct rtnetlink_link inet_rtnetlink_table[RTM_MAX-RTM_BASE+1] /usr/src/linux/net/ipv6/addrconf.c
static struct rtnetlink_link inet6_rtnetlink_table[RTM_MAX-RTM_BASE+1] And severeal other functions and structures in the routing code.

When you try to add a rule with a 'table' object, the 'ip' command - maybe - simply discards the 'table' tag.

Regards,

kisza

    Andras Kis-Szabo       Security Development, Design and Audit
-------------------------/        Zorp, NetFilter and IPv6
 [email protected] /-----Member of the BUTE-MIS-SEARCHlab------>

I guess I have to implement it myself, then...

Be back when I have, with a patch!

Sincerily,
Gabriel

<snip>

Hi. Sorry, I don't have much to add, except to reassure you that I've seen similar in my logs. I hope you will keep the mailing list informed on any progress you make, I hope I can add to your research at some point.

FunkyJesus System Administration Team

Since day one, Shorewall has included the following rule:

457 67312 ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp flags:0x10/0x10

As you can see, I get a fair number packets with the ACK flag that aren't picked up by an earlier ESTABLISHED,RELATED rule. After experimenting with various strategies (DROP, REJECT --reject-with tcp-reset), I settled on ACCEPT as it seemed to have the fewest side effects.

-Tom

Tom Eastep    \ Shorewall - iptables made easy
AIM: tmeastep  \ http://www.shorewall.net
ICQ: #60745924  \ [email protected]