Problem accessing https://my.procurve.com/profile/index.aspx (ACK is over the upper bound)

Krzysztof Oledzki ole at ans.pl
Sun Jul 1 02:42:15 CEST 2007


Hello,

My colleague have just reported that he is unable to access "REGISTER 
HERE" page from the https://my.procurve.com/profile/index.aspx. Short 
debuging shows that his connection was dropped by the netfilter code 
running on fw/nat host:

02:06:29.573031 IP (tos 0x0, ttl 127, id 43914, offset 0, flags [DF], proto: TCP (6), length: 48) 195.177.210.11.6347 > 216.34.143.7.443: S, cksum 0xbb9c (correct), 3455050277:3455050277(0) win 65535 <mss 1460,nop,nop,sackOK>
02:06:29.756857 IP (tos 0x0, ttl 241, id 41244, offset 0, flags [DF], proto: TCP (6), length: 48) 216.34.143.7.443 > 195.177.210.11.6347: S, cksum 0x0655 (correct), 1733443080:1733443080(0) ack 3455050278 win 4140 <mss 1380,nop,nop,sackOK>
02:06:29.757021 IP (tos 0x0, ttl 127, id 43920, offset 0, flags [DF], proto: TCP (6), length: 40) 195.177.210.11.6347 > 216.34.143.7.443: ., cksum 0x42f5 (correct), ack 1733443081 win 65535
02:06:29.757871 IP (tos 0x0, ttl 127, id 43923, offset 0, flags [DF], proto: TCP (6), length: 142) 195.177.210.11.6347 > 216.34.143.7.443: P 3455050278:3455050380(102) ack 1733443081 win 65535
02:06:29.941610 IP (tos 0x0, ttl 241, id 41252, offset 0, flags [DF], proto: TCP (6), length: 162) 216.34.143.7.443 > 195.177.210.11.6347: P 1733443081:1733443203(122) ack 3455050380 win 4242
02:06:29.944767 IP (tos 0x0, ttl 127, id 43930, offset 0, flags [DF], proto: TCP (6), length: 83) 195.177.210.11.6347 > 216.34.143.7.443: P 3455050380:3455050423(43) ack 1733443203 win 65413
02:06:29.946115 IP (tos 0x0, ttl 127, id 43932, offset 0, flags [DF], proto: TCP (6), length: 1216) 195.177.210.11.6347 > 216.34.143.7.443: P 3455050423:3455051599(1176) ack 1733443203 win 65413
02:06:29.946221 IP (tos 0x0, ttl 127, id 43933, offset 0, flags [DF], proto: TCP (6), length: 1420) 195.177.210.11.6347 > 216.34.143.7.443: . 3455051599:3455052979(1380) ack 1733443203 win 65413
02:06:29.946241 IP (tos 0x0, ttl 127, id 43934, offset 0, flags [DF], proto: TCP (6), length: 689) 195.177.210.11.6347 > 216.34.143.7.443: P 3455052979:3455053628(649) ack 1733443203 win 65413
02:06:30.130106 IP (tos 0x0, ttl 241, id 41259, offset 0, flags [DF], proto: TCP (6), length: 40) 216.34.143.7.443 > 195.177.210.11.6347: ., cksum 0x27fd (correct), ack 3455051599 win 5461
02:06:30.130125 IP (tos 0x0, ttl 241, id 41261, offset 0, flags [DF], proto: TCP (6), length: 52) 216.34.143.7.443 > 195.177.210.11.6347: ., cksum 0x6cd9 (correct), ack 3455051599 win 5461 <nop,nop,sack 1 {236696358:236697007}>
02:06:30.134620 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 195.177.210.11.6347 > 216.34.143.7.443: R, cksum 0xe333 (correct), 3455051599:3455051599(0) win 0
02:06:30.134629 IP (tos 0x0, ttl 241, id 41265, offset 0, flags [DF], proto: TCP (6), length: 52) 216.34.143.7.443 > 195.177.210.11.6347: ., cksum 0x6263 (correct), ack 3455053628 win 7490 <nop,nop,sack 1 {236694978:236697007}>
02:06:30.140908 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 195.177.210.11.6347 > 216.34.143.7.443: R, cksum 0xdb46 (correct), 3455053628:3455053628(0) win 0
02:06:30.140929 IP (tos 0x0, ttl 241, id 41269, offset 0, flags [DF], proto: TCP (6), length: 565) 216.34.143.7.443 > 195.177.210.11.6347: P 1733443203:1733443716(513) ack 3455053628 win 7490 <nop,nop,sack 1 {236694978:236697007}>
02:06:30.147216 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 195.177.210.11.6347 > 216.34.143.7.443: R, cksum 0xdb46 (correct), 3455053628:3455053628(0) win 0
02:06:32.523268 IP (tos 0x0, ttl 127, id 43966, offset 0, flags [DF], proto: TCP (6), length: 1420) 195.177.210.11.6347 > 216.34.143.7.443: . 3455051599:3455052979(1380) ack 1733443203 win 65413
02:06:32.707202 IP (tos 0x0, ttl 240, id 40250, offset 0, flags [none], proto: TCP (6), length: 40) 216.34.143.7.443 > 195.177.210.11.6347: R, cksum 0x3dc8 (correct), 1733443203:1733443203(0) ack 3455051599 win 65413

Jul  1 02:06:30 fw1 kernel: nf_ct_tcp: ACK is over the upper bound (ACKed data not seen yet) IN= OUT= SRC=216.34.143.7 DST=195.177.210.11 LEN=52 TOS=0x00 PREC=0x00 TTL=241 ID=41261 DF PROTO=TCP SPT=443 DPT=6347 SEQ=1733443203 ACK=3455051599 WINDOW=5461 RES=0x00 ACK URGP=0 OPT (0101050A0E1BB3260E1BB5AF)
Jul  1 02:06:30 fw1 kernel: nf_ct_tcp: ACK is over the upper bound (ACKed data not seen yet) IN= OUT= SRC=216.34.143.7 DST=195.177.210.11 LEN=52 TOS=0x00 PREC=0x00 TTL=241 ID=41265 DF PROTO=TCP SPT=443 DPT=6347 SEQ=1733443203 ACK=3455053628 WINDOW=7490 RES=0x00 ACK URGP=0 OPT (0101050A0E1BADC20E1BB5AF)
Jul  1 02:06:30 fw1 kernel: nf_ct_tcp: ACK is over the upper bound (ACKed data not seen yet) IN= OUT= SRC=216.34.143.7 DST=195.177.210.11 LEN=565 TOS=0x00 PREC=0x00 TTL=241 ID=41269 DF PROTO=TCP SPT=443 DPT=6347 SEQ=1733443203 ACK=3455053628 WINDOW=7490 RES=0x00 ACK PSH URGP=0 OPT (0101050A0E1BADC20E1BB5AF)

AFAIK netfilter is supposed to drop such packet (without sending a RST), 
isn't it? So why the RST packet was sent?

Setting net.ipv4.netfilter.ip_conntrack_tcp_be_liberal solves the problem, 
but this is not a right fix and now the main question is: was this ACK 
really over the upper bound since when 
net.ipv4.netfilter.ip_conntrack_tcp_be_liberal is enabled it is possible 
to access this page (of course with many netfilter warnings that "ACK is 
over the upper bound").

root at fw1:~# uname -r
2.6.20.11

Best regards,

 			Krzysztof Olędzki


More information about the netfilter-devel mailing list