Problem accessing (ACK is over the upper bound)

Krzysztof Oledzki ole at
Mon Jul 2 20:55:56 CEST 2007

On Mon, 2 Jul 2007, Patrick McHardy wrote:

> 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.

It seems they finally fixed it in a cvs at end of the Jan 2006 (so late - 
10 years after sack had been specified in rfc2018):

AFAIK it first went into 4.0 (released Nov 1, 2006) and also OPENBSD_3_9 
(STABLE "branch" for 3.9) so it is safe to assume that only very new 
installations may be safe. :(

AFAIK (again) this fix hasn't went into FreeBSD and NetBSD at all. :( Oh, 

>> 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.

Fair enough.

>> 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 :)

OK. Will try to cook something. Can I base it on the IPV4OPTSSTRIP 
there is a better example? :)

Best regards,

 				Krzysztof Olędzki

More information about the netfilter-devel mailing list