Problem accessing https://my.procurve.com/profile/index.aspx
(ACK is over the upper bound)
kaber at trash.net
Mon Jul 2 15:26:50 CEST 2007
Krzysztof Oledzki wrote:
> Found this:
> Sounds familiar - it seems that there may be a crappy OpenBSD firewall
> lurking somewhere along the path. :(
Indeed, too bad they apparently don't fix their crap and we're getting
at least one report per month about this.
> What we can do with such packets? Maybe, when a ack is valid but a sack
> is not (as it is in this situation) we are able to remove such insane
> sack option(s) with a hope that this ACK itself may acknowledge something?
I'm not too big a fan of this idea, but I will consider it if someone
sends a patch. It would have to be manually enabled at least.
> This is how this connection looks like when
> net.ipv4.netfilter.ip_conntrack_tcp_be_liberal is enabled:
> 04:34:42.835709 IP (tos 0x0, ttl 241, id 65123, offset 0, flags [DF],
> proto: TCP (6), length: 52) 126.96.36.199.443 > 188.8.131.52.6747: .,
> cksum 0x746e (correct), ack 1809367099 win 7490 <nop,nop,sack 1
> sacked full 2029 octets + acked everyting to 1809367099
> 04:34:42.841979 IP (tos 0x0, ttl 241, id 65127, offset 0, flags [DF],
> proto: TCP (6), length: 565) 184.108.40.206.443 > 220.127.116.11.6747: P
> 3724064785:3724065298(513) ack 1809367099 win 7490 <nop,nop,sack 1
> (redundant) sacked full 2029 octets + acked everyting to 1809367099 +
> sending some data + PUSH
> 04:34:42.853077 IP (tos 0x0, ttl 127, id 10684, offset 0, flags [DF],
> proto: TCP (6), length: 1150) 18.104.22.168.6747 > 22.214.171.124.443: P
> 1809367099:1809368209(1110) ack 3724065298 win 64900
> Bingo... :)
> There is a Windows XP host behind this NAT and is seems it is quite
> happy ignoring this sack crap as the ack itself finnaly acknowledged
> everyting. The transmition continues.
> Additionally, creating TCPOPTSSTRIP target to allow striping specific
> tcp option(s) (for example Sack-Permitted from a SYN packet) may also be
> usable if it is possible to include this extension in a base kernel.
> This may also help with a similar window scaling problem as current
> solution requires to add a route on _all_ hosts inside a network.
> Working around it on a firewall may be much faster.
Feel free to send patches :)
More information about the netfilter-devel