TCP window tracking patch status query for further design considerations

TCP window tracking patch status query for further design considerations

[Roberto Nibali]

Hello guys,

Is/Are there any news about the possibly impaired functionality of the TCP 
window tracking patch? I recall the thread about the mailinglist problems where 
Harald concluded that it was this patch that caused headaches to several people 
trying to send emails to the netfilter lists. Has the problem been investigated 
any further or is the status still unclear?

Unfortunately we depend on it because we do not use netfilter in a 'Intranet <-> 
Internet' way but in a 'multiple zones -> multiple zones' way. We do not have 
any trusted zones and without the TCP window tracking patch for example someone 
sending a RST can delete ESTABLISHED entries from the conntrack table. This is 
not an issue if you come from a trusted network like your Intranet for example, 
but it sure takes all the fun away if you have different customers on each NIC.

You can test things very efficiently with sendip (example to flush entries):
./sendip <dst> -p tcp -is <src> -ts <sport> -td <dport> -tfr 1

Without this patch, netfilter is completely useless to us. Could someone please 
give me a status report of this patch? What about a possible inclusion into 
mainstream kernel (this question is important to our management to create 
appropriate SLAs)?

TIA and best regards,
Roberto Nibali, ratz

PS.: FYI, I'm running and testing the stuff with the latest iptables, kernel 
2.4.20-pre8 and latest pom. I've not applied other patches yet.
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc

Re: TCP window tracking patch status query for further design considerations

[Jozsef Kadlecsik]

Hi,

On Mon, 7 Oct 2002, Roberto Nibali wrote:

> Is/Are there any news about the possibly impaired functionality of the
> TCP window tracking patch? I recall the thread about the mailinglist
> problems where Harald concluded that it was this patch that caused
> headaches to several people trying to send emails to the netfilter
> lists. Has the problem been investigated any further or is the status
> still unclear?

The problem hasn't still been investigated. :-( I have been totally buried
with other tasks in the last weeks. :-((

I hope in this month I'll be able to run an excessive testing of the
delayed SMTP delivery caused by the patch and find the solution.

> Without this patch, netfilter is completely useless to us. Could
> someone please give me a status report of this patch? What about a
> possible inclusion into mainstream kernel (this question is important
> to our management to create appropriate SLAs)?

Even after the problem is fixed, some time will be required for further
testing the patch before considering submitting into the kernel. Also,
a decision will be required on the the proc interface of netfilter due to
the new level introduced by the patch.

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

Re: TCP window tracking patch status query for further design considerations

[Roberto Nibali]

Hi,

Thank you very much for your reply.

> The problem hasn't still been investigated. :-( I have been totally buried
> with other tasks in the last weeks. :-((

I understand that. All good people are buried in work.

> I hope in this month I'll be able to run an excessive testing of the
> delayed SMTP delivery caused by the patch and find the solution.

If I can be of any help, let me know. I can run some tests in my lab since I 
have to test this patch anyway. I currently work with packet generation tools to 
send specially crafted IP packets to see if I can evade some functionality.

At least it seems to be quite stable so far. The only problem I'm experiencing 
is the interaction of the TCP state transition table modification influence when 
using LVS. In LVS we have done a similar state transition definition but IIRC it 
differs from yours. So now we have proc-fs exports for TCP state transition 
timing with your window tracking patch and proc-fs exports for the same timing 
entries from LVS.

> Even after the problem is fixed, some time will be required for further
> testing the patch before considering submitting into the kernel. Also,
> a decision will be required on the the proc interface of netfilter due to
> the new level introduced by the patch.

Let me know when you work on it again so I can maybe help you. I see that your 
patch does break some user space scripts that assume certain proc-fs entries for 
the conntrack_max variable. I hope though that nevertheless the netfilter team 
will be working on a future inclusion of this patch.

Thanks a bunch for your time,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc

Re: TCP window tracking patch status query for further design considerations

[Roberto Nibali]

Hello Jozsef,

Sorry for the length of the email.

> The problem hasn't still been investigated. :-( I have been totally buried
> with other tasks in the last weeks. :-((

I kind of have a case here where I can reliably generate a hang. It's quite 
complex to reproduce though. So far you need multiple interfaces, some secondary 
IP addresses and a rule that only allows connections to the sshd on the packet 
filter (I think it has nothing to do with the setup though). Then you log in and 
do some work. After a while, it seems like a buffer is getting too big, it 
stalls and I start getting DENIES in the kernlog. Sorry for not being more 
specific but I will try to work out an easy test case so you can debug it.

milk-net_tfxdev:~# show-rules && show-routes
RuleNr     Source           Destination      Table    Special
0          all              all              local    n/a
100        all              all              main     n/a
65000      all              all              1        n/a
Destination        Gateway         Source             Iface    R_Type RT_table 
192.168.0.0/24     0.0.0.0         192.168.0.1        eth1            main 
10.10.1.0/24       0.0.0.0         10.10.1.1          eth2            main 
224.0.0.0/24       0.0.0.0         0.0.0.0/0          all      BL     main 
172.27.0.0/16      0.0.0.0         172.27.232.12      eth0            main 
default            172.27.0.1      172.27.232.12      eth0            1
milk-net_tfxdev:~# ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
     link/ether 00:01:02:96:f9:05 brd ff:ff:ff:ff:ff:ff
     inet 172.27.232.12/16 brd 172.27.255.255 scope global eth0
milk-net_tfxdev:~# ip neigh show
172.27.0.1 dev eth0 lladdr 00:50:04:ac:5e:33 nud reachable
milk-net_tfxdev:~# netstat -an | grep ESTA
tcp        0     48 172.27.232.12:234       192.168.7.1:39094       ESTABLISHED 
milk-net_tfxdev:~# cat /proc/net/ip_conntrack
tcp      6 432000 ESTABLISHED src=192.168.7.1 dst=172.27.232.12 sport=39094 
dport=234 src=172.27.232.12 dst=192.168.7.1 sport=234 dport=39094 use=1
tcp      6 258780 CLOSE_WAIT src=192.168.7.1 dst=172.27.232.12 sport=45152 
dport=234 src=172.27.232.12 dst=192.168.7.1 sport=234 dport=45152 use=1
tcp      6 258906 CLOSE_WAIT src=192.168.7.1 dst=172.27.232.12 sport=45233 
dport=234 src=172.27.232.12 dst=192.168.7.1 sport=234 dport=45233 use=1
tcp      6 258696 CLOSE_WAIT src=192.168.7.1 dst=172.27.232.12 sport=45052 
dport=234 src=172.27.232.12 dst=192.168.7.1 sport=234 dport=45052 use=1
milk-net_tfxdev:~#
milk-net_tfxdev:~# #new connection request from 192.168.7.1
milk-net_tfxdev:~#
milk-net_tfxdev:~# netstat -an | grep ESTA
tcp        0      0 172.27.232.12:234       192.168.7.1:45835       ESTABLISHED 
tcp        0     48 172.27.232.12:234       192.168.7.1:39094       ESTABLISHED 
milk-net_tfxdev:~# cat /proc/net/ip_conntrack
tcp      6 432000 ESTABLISHED src=192.168.7.1 dst=172.27.232.12 sport=39094 
dport=234 src=172.27.232.12 dst=192.168.7.1 sport=234 dport=39094 use=1
tcp      6 258742 CLOSE_WAIT src=192.168.7.1 dst=172.27.232.12 sport=45152 
dport=234 src=172.27.232.12 dst=192.168.7.1 sport=234 dport=45152 use=1
tcp      6 258868 CLOSE_WAIT src=192.168.7.1 dst=172.27.232.12 sport=45233 
dport=234 src=172.27.232.12 dst=192.168.7.1 sport=234 dport=45233 use=1
tcp      6 258657 CLOSE_WAIT src=192.168.7.1 dst=172.27.232.12 sport=45052 
dport=234 src=172.27.232.12 dst=192.168.7.1 sport=234 dport=45052 use=1
tcp      6 431992 ESTABLISHED src=192.168.7.1 dst=172.27.232.12 sport=45835 
dport=234 src=172.27.232.12 dst=192.168.7.1 sport=234 dport=45835 use=1
milk-net_tfxdev:~#
milk-net_tfxdev:~# #some work and then hang
milk-net_tfxdev:~#
milk-net_tfxdev:~# netstat -an | grep ESTA
tcp        0   7776 172.27.232.12:234       192.168.7.1:45835       ESTABLISHED 
tcp        0     48 172.27.232.12:234       192.168.7.1:39094       ESTABLISHED 
milk-net_tfxdev:~# cat /proc/net/ip_conntrack
tcp      6 432000 ESTABLISHED src=192.168.7.1 dst=172.27.232.12 sport=39094 
dport=234 src=172.27.232.12 dst=192.168.7.1 sport=234 dport=39094 use=1
tcp      6 258704 CLOSE_WAIT src=192.168.7.1 dst=172.27.232.12 sport=45152 
dport=234 src=172.27.232.12 dst=192.168.7.1 sport=234 dport=45152 use=1
tcp      6 258831 CLOSE_WAIT src=192.168.7.1 dst=172.27.232.12 sport=45233 
dport=234 src=172.27.232.12 dst=192.168.7.1 sport=234 dport=45233 use=1
tcp      6 258620 CLOSE_WAIT src=192.168.7.1 dst=172.27.232.12 sport=45052 
dport=234 src=172.27.232.12 dst=192.168.7.1 sport=234 dport=45052 use=1
tcp      6 292 ESTABLISHED src=192.168.7.1 dst=172.27.232.12 sport=45835 
dport=234 src=172.27.232.12 dst=192.168.7.1 sport=234 dport=45835 use=1
milk-net_tfxdev:~#

ACCEPT INPUT: IN=eth0 OUT= MAC=00:01:02:96:f9:05:00:50:04:ac:5e:33:08:00 
SRC=192.168.7.1 DST=172.27.232.12 LEN=44 TOS=0x10 PREC=0x00 TTL=253 ID=23543 DF 
PROTO=TCP SPT=45835 DPT=234 WINDOW=8760 RES=0x00 SYN URGP=0
DENY INPUT: IN=eth0 OUT= MAC=00:01:02:96:f9:05:00:50:04:ac:5e:33:08:00 
SRC=172.27.0.1 DST=172.27.232.12 LEN=576 TOS=0x10 PREC=0xC0 TTL=255 ID=44216 
PROTO=ICMP TYPE=3 CODE=4 [SRC=172.27.232.12 DST=192.168.7.1 LEN=1500 TOS=0x10 
PREC=0x00 TTL=63 ID=42584 DF PROTO=TCP SPT=234 DPT=45835 WINDOW=9480 RES=0x00 
ACK URGP=0 ] MTU=1200
DENY INPUT: IN=eth0 OUT= MAC=00:01:02:96:f9:05:00:50:04:ac:5e:33:08:00 
SRC=172.27.0.1 DST=172.27.232.12 LEN=576 TOS=0x10 PREC=0xC0 TTL=255 ID=44219 
PROTO=ICMP TYPE=3 CODE=4 [SRC=172.27.232.12 DST=192.168.7.1 LEN=1500 TOS=0x10 
PREC=0x00 TTL=63 ID=42585 DF PROTO=TCP SPT=234 DPT=45835 WINDOW=9480 RES=0x00 
ACK URGP=0 ] MTU=1200
DENY INPUT: IN=eth0 OUT= MAC=00:01:02:96:f9:05:00:50:04:ac:5e:33:08:00 
SRC=172.27.0.1 DST=172.27.232.12 LEN=576 TOS=0x10 PREC=0xC0 TTL=255 ID=44220 
PROTO=ICMP TYPE=3 CODE=4 [SRC=172.27.232.12 DST=192.168.7.1 LEN=1500 TOS=0x10 
PREC=0x00 TTL=63 ID=42586 DF PROTO=TCP SPT=234 DPT=45835 WINDOW=9480 RES=0x00 
ACK URGP=0 ] MTU=1200
DENY INPUT: IN=eth0 OUT= MAC=00:01:02:96:f9:05:00:50:04:ac:5e:33:08:00 
SRC=172.27.0.1 DST=172.27.232.12 LEN=576 TOS=0x10 PREC=0xC0 TTL=255 ID=44221 
PROTO=ICMP TYPE=3 CODE=4 [SRC=172.27.232.12 DST=192.168.7.1 LEN=1500 TOS=0x10 
PREC=0x00 TTL=63 ID=42587 DF PROTO=TCP SPT=234 DPT=45835 WINDOW=9480 RES=0x00 
ACK URGP=0 ] MTU=1200
DENY INPUT: IN=eth0 OUT= MAC=00:01:02:96:f9:05:00:50:04:ac:5e:33:08:00 
SRC=172.27.0.1 DST=172.27.232.12 LEN=576 TOS=0x10 PREC=0xC0 TTL=255 ID=44223 
PROTO=ICMP TYPE=3 CODE=4 [SRC=172.27.232.12 DST=192.168.7.1 LEN=1500 TOS=0x10 
PREC=0x00 TTL=63 ID=42588 DF PROTO=TCP SPT=234 DPT=45835 WINDOW=9480 RES=0x00 
ACK URGP=0 ] MTU=1200
DENY INPUT: IN=eth0 OUT= MAC=00:01:02:96:f9:05:00:50:04:ac:5e:33:08:00 
SRC=172.27.0.1 DST=172.27.232.12 LEN=576 TOS=0x10 PREC=0xC0 TTL=255 ID=44229 
PROTO=ICMP TYPE=3 CODE=4 [SRC=172.27.232.12 DST=192.168.7.1 LEN=1500 TOS=0x10 
PREC=0x00 TTL=63 ID=42589 DF PROTO=TCP SPT=234 DPT=45835 WINDOW=9480 RES=0x00 
ACK URGP=0 ] MTU=1200
DENY INPUT: IN=eth0 OUT= MAC=00:01:02:96:f9:05:00:50:04:ac:5e:33:08:00 
SRC=172.27.0.1 DST=172.27.232.12 LEN=576 TOS=0x10 PREC=0xC0 TTL=255 ID=44237 
PROTO=ICMP TYPE=3 CODE=4 [SRC=172.27.232.12 DST=192.168.7.1 LEN=1500 TOS=0x10 
PREC=0x00 TTL=63 ID=42590 DF PROTO=TCP SPT=234 DPT=45835 WINDOW=9480 RES=0x00 
ACK URGP=0 ] MTU=1200
DENY INPUT: IN=eth0 OUT= MAC=00:01:02:96:f9:05:00:50:04:ac:5e:33:08:00 
SRC=172.27.0.1 DST=172.27.232.12 LEN=576 TOS=0x10 PREC=0xC0 TTL=255 ID=44288 
PROTO=ICMP TYPE=3 CODE=4 [SRC=172.27.232.12 DST=192.168.7.1 LEN=1500 TOS=0x10 
PREC=0x00 TTL=63 ID=42591 DF PROTO=TCP SPT=234 DPT=45835 WINDOW=9480 RES=0x00 
ACK URGP=0 ] MTU=1200
DENY INPUT: IN=eth0 OUT= MAC=00:01:02:96:f9:05:00:50:04:ac:5e:33:08:00 
SRC=172.27.0.1 DST=172.27.232.12 LEN=576 TOS=0x10 PREC=0xC0 TTL=255 ID=44335 
PROTO=ICMP TYPE=3 CODE=4 [SRC=172.27.232.12 DST=192.168.7.1 LEN=1500 TOS=0x10 
PREC=0x00 TTL=63 ID=42592 DF PROTO=TCP SPT=234 DPT=45835 WINDOW=9480 RES=0x00 
ACK URGP=0 ] MTU=1200

One of the problems could be my routing although I don't think it should have an 
effect on netfilter. It seems as if the packets are coming in from 192.168.7.1 
first but after a while we seem to compare against 172.27.0.1. I have multiple 
layers of networks put on the same interface.

Another problem is that I can work on the new session as long as the things I do 
don't generate a certain size of packets. I can't find out right now what size 
this is because I'm working remote over a ton of other networks. I'll improve 
the test case in future.

RULES:
------
milk-net_tfxdev:~# iptables -t filter -nxv -L
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts      bytes target     prot opt in     out     source 
destination
        6      264 LOG        tcp  --  *      *       192.168.7.1 
172.27.232.12      state NEW tcp spts:1024:65535 dpt:234 flags:0x3F/0x02 LOG 
flags 0 level 4 prefix `ACCEPT INPUT: '
        6      264 ACCEPT     tcp  --  *      *       192.168.7.1 
172.27.232.12      state NEW tcp spts:1024:65535 dpt:234 flags:0x3F/0x02
     2201   158696 ACCEPT     tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0          state ESTABLISHED
       65    37440 LOG        all  --  *      *       0.0.0.0/0 
0.0.0.0/0          LOG flags 0 level 4 prefix `DENY INPUT: '
       65    37440 DROP       all  --  *      *       0.0.0.0/0 
0.0.0.0/0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
     pkts      bytes target     prot opt in     out     source 
destination
        0        0 LOG        all  --  *      *       0.0.0.0/0 
0.0.0.0/0          LOG flags 0 level 4 prefix `DENY FORWARD: '
        0        0 DROP       all  --  *      *       0.0.0.0/0 
0.0.0.0/0

Chain OUTPUT (policy ACCEPT 1 packets, 328 bytes)
     pkts      bytes target     prot opt in     out     source 
destination
     2079   462106 ACCEPT     tcp  --  *      *       0.0.0.0/0 
0.0.0.0/0          state ESTABLISHED
        0        0 LOG        all  --  *      *       0.0.0.0/0 
0.0.0.0/0          LOG flags 0 level 4 prefix `DENY OUTPUT: '
        0        0 DROP       all  --  *      *       0.0.0.0/0 
0.0.0.0/0
milk-net_tfxdev:~#


Best regards,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc

Re: TCP window tracking patch status query for further design considerations

[Jozsef Kadlecsik]

Hi Roberto,

On Tue, 8 Oct 2002, Roberto Nibali wrote:

> I kind of have a case here where I can reliably generate a hang. It's quite
> complex to reproduce though. So far you need multiple interfaces, some secondary
> IP addresses and a rule that only allows connections to the sshd on the packet
> filter (I think it has nothing to do with the setup though). Then you log in and
> do some work. After a while, it seems like a buffer is getting too big, it
> stalls and I start getting DENIES in the kernlog. Sorry for not being more
> specific but I will try to work out an easy test case so you can debug it.
[...]
> DENY INPUT: IN=eth0 OUT= MAC=00:01:02:96:f9:05:00:50:04:ac:5e:33:08:00
> SRC=172.27.0.1 DST=172.27.232.12 LEN=576 TOS=0x10 PREC=0xC0 TTL=255 ID=44216
> PROTO=ICMP TYPE=3 CODE=4 [SRC=172.27.232.12 DST=192.168.7.1 LEN=1500 TOS=0x10
> PREC=0x00 TTL=63 ID=42584 DF PROTO=TCP SPT=234 DPT=45835 WINDOW=9480 RES=0x00
> ACK URGP=0 ] MTU=1200

It has nothing to do with the tcp-window-tracking patch. Without the patch
you would get the same results.

You send too big packets with the DF bit set, but you block the
correspondig ICMP error messages (see the kernel log above) as well.

> Another problem is that I can work on the new session as long as the
> things I do don't generate a certain size of packets.

Exactly.

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

Re: TCP window tracking patch status query for further design considerations

[Roberto Nibali]

Hi,

> It has nothing to do with the tcp-window-tracking patch. Without the patch
> you would get the same results.

Yes, you're right, I found it out too just a few hours ago.

> You send too big packets with the DF bit set, but you block the
> correspondig ICMP error messages (see the kernel log above) as well.

D'oh, apologies to the netfilter-devel list for this embarrassing posting.

>>Another problem is that I can work on the new session as long as the
>>things I do don't generate a certain size of packets.
>  
> Exactly.

I will crawl back to my corner and try it again.

Sorry for wasting your time,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc

Re: TCP window tracking patch status query for further design considerations

[Roberto Nibali]

Hi,

>> You send too big packets with the DF bit set, but you block the
>> correspondig ICMP error messages (see the kernel log above) as well.
>  
> D'oh, apologies to the netfilter-devel list for this embarrassing posting.

I've just realized that the tests I did were done over a VPN link with an MTU of 
1200 :(. I've fixed my setup on the packet filter as follows:

ip link set dev eth0 mtu 1200 && ip route flush cache

I will now go back and delve into testing the TCP window tracking patch.

Regards,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc

Re: TCP window tracking patch status query for further design considerations

[Roberto Nibali]

Hello Jozsef,

Sorry to bother you again.

> The problem hasn't still been investigated. :-( I have been totally buried
> with other tasks in the last weeks. :-((

Could you explain or point me to some RFC for the following lines in the TCP 
window tracking patch.?

+/* Fixme: what about big packets? */
+#define MAXACKWINCONST                 66000
+#define MAXACKWINDOW(sender)           ((sender)->td_maxwin > MAXACKWINCONST ? 
(sender)->td_maxwin : MAXACKWINCONST)

Shouldn't it be (or what is the point of having MAXACKWINCONST):

+#define MAXACKWINDOW(sender)           ((sender)->td_maxwin > MAXACKWINCONST ?
  MAXACKWINCONST : (sender)->td_maxwin)

Why do you do the following thing? Isn't it up to the ruleset to take care of 
this? What if I would like to have those flags accepted :)?

+       tcpflags = (((u_int8_t *)tcph)[13] & ~(TH_ECE|TH_CWR));
+       if (tcpflags != TH_SYN
+           && tcpflags != (TH_SYN|TH_ACK)
+           && tcpflags != TH_RST
+           && tcpflags != (TH_RST|TH_ACK)
+           && tcpflags != (TH_RST|TH_ACK|TH_PUSH)
+           && tcpflags != (TH_FIN|TH_ACK)
+           && tcpflags != TH_ACK
+           && tcpflags != (TH_ACK|TH_PUSH)
+           && tcpflags != (TH_ACK|TH_URG)
+           && tcpflags != (TH_ACK|TH_URG|TH_PUSH)
+           && tcpflags != (TH_FIN|TH_ACK|TH_PUSH)
+           && tcpflags != (TH_FIN|TH_ACK|TH_URG)
+           && tcpflags != (TH_FIN|TH_ACK|TH_URG|TH_PUSH)) {
+               if (ip_ct_tcp_log_out_of_window && net_ratelimit())
+                       log_invalid_packet(iph, tcph, "ip_conntrack_tcp: 
INVALID: invalid TCP flag combination.\n");
+               return 1;
+       }

Best regards,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc

Re: TCP window tracking patch status query for further design considerations

[Jozsef Kadlecsik]

Hi,

On Tue, 8 Oct 2002, Roberto Nibali wrote:

> Could you explain or point me to some RFC for the following lines in the TCP
> window tracking patch.?
>
> +/* Fixme: what about big packets? */
> +#define MAXACKWINCONST                 66000
> +#define MAXACKWINDOW(sender)           ((sender)->td_maxwin > MAXACKWINCONST ?
> (sender)->td_maxwin : MAXACKWINCONST)

Read Guido's article on which the patch is based:
http://www.iane.nl/users/guido/papers/tcp_filtering.ps.gz

The constant is a little bit bigger than the maximal possible window size
without window scaling. The macro tries to take window scaling into
account.

> Shouldn't it be (or what is the point of having MAXACKWINCONST):
>
> +#define MAXACKWINDOW(sender)           ((sender)->td_maxwin > MAXACKWINCONST ?
>   MAXACKWINCONST : (sender)->td_maxwin)

No, it'd make the possible ACK window smaller in the case of window
scaling.

> Why do you do the following thing? Isn't it up to the ruleset to take care of
> this? What if I would like to have those flags accepted :)?
[...]

Those packets are either corrupted or invalid ones sent deliberately
and would (wrongly) be reported as out of window ones.

Most of the out of window log entries created by the earlier patch
releases was generated because the code was not protected against such
packets.

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

Re: TCP window tracking patch status query for further design considerations

[Roberto Nibali]

> Read Guido's article on which the patch is based:
> http://www.iane.nl/users/guido/papers/tcp_filtering.ps.gz

I actually did, even twice, but not carefully enough.

> The constant is a little bit bigger than the maximal possible window size
> without window scaling. The macro tries to take window scaling into
> account.

Got it.

>>Shouldn't it be (or what is the point of having MAXACKWINCONST):
>>
>>+#define MAXACKWINDOW(sender)           ((sender)->td_maxwin > MAXACKWINCONST ?
>>  MAXACKWINCONST : (sender)->td_maxwin)
> 
> 
> No, it'd make the possible ACK window smaller in the case of window
> scaling.

Makes sense now, why didn't it before?

> Those packets are either corrupted or invalid ones sent deliberately
> and would (wrongly) be reported as out of window ones.
> Most of the out of window log entries created by the earlier patch
> releases was generated because the code was not protected against such
> packets.

I understand. Thank you.

Regards,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc