Victor Duchovni wrote:
> On Wed, Dec 20, 2006 at 10:20:24AM +1100, Darren Reed wrote:
>
>   
>> Pekka Savola wrote:
>>     
>>> Hello,
>>>
>>> On FreeBSD 6.2-PRERELEASE (apparently ipfilter ~4.1.13), I'm having a
>>> problem with NATted, FTP-proxied sessions which use Window Scaling.
>>> Session that don't use the FTP proxy (or if the FTP proxy rule is
>>> disabled) or if WS is disabled work OK.
>>>
>>> Maybe FTP proxy doesn't work with Window Scaling, or is there
>>> something I'm missing ?
>>>
>>> IPmon lists the errors like:
>>>
>>> 19/12/2006 20:56:04.982985 15x fxp0 @0:32 b 193.166.3.2,33416 ->
>>> 192.168.1.1,33828 PR tcp len 20 1500 -A IN OOW NAT
>>> 19/12/2006 20:56:08.235987 fxp0 @0:32 b 193.166.3.2,33416 ->
>>> 192.168.1.1,33828 PR tcp len 20 1500 -A IN OOW NAT
>>> 19/12/2006 20:56:09.155467 fxp0 @0:32 b 193.166.3.2,33416 ->
>>> 192.168.1.1,33828 PR tcp len 20 1500 -A IN OOW NAT
>>> 19/12/2006 20:56:10.996694 fxp0 @0:32 b 193.166.3.2,33416 ->
>>> 192.168.1.1,33828 PR tcp len 20 1500 -A IN OOW NAT
>>>       
>> To see if it has properly picked up window scaling, list out the state table
>> entry with "ipfstat -sl".  To me it is looking like the FTP data connection
>> is the one having trouble, yes?
>>     
>
> Historically (not sure which release may have fixed this), the scaling
> code has been wrong, it applies the client's TCP scaling to packets from
> the server and vice versa. If the scale factors differ, you get a problem.
>
> The previously posted fix for the 3.x code train is:
>
> --- ip_state.c        2003/09/30 23:02:47     1.2
> +++ ip_state.c        2003/10/01 00:04:23     1.3
> @@ -956,8 +956,8 @@
>           (SEQ_GE(seq, fdata->td_end - maxwin)) &&
>  /* XXX what about big packets */
>  #define MAXACKWINDOW 66000
> -         (-ackskew <= (MAXACKWINDOW << tdata->td_wscale)) &&
> -         ( ackskew <= (MAXACKWINDOW << tdata->td_wscale))) {
> +         (-ackskew <= (MAXACKWINDOW)) &&
> +         ( ackskew <= (MAXACKWINDOW << fdata->td_wscale))) {
>  
>               /* if ackskew < 0 then this should be due to fragmented
>                * packets. There is no way to know the length of the
>
> The same issue may still be present in 4.13... Note, this only scales
> inside the window (positive ackskew), I don't believe that it is necessary
> to scale negative ackskew.

The same code in 4.1.13 - 4.1.16 is:
        inseq = 0;
        if ((SEQ_GE(fdata->td_maxend, end)) &&
            (SEQ_GE(seq, fdata->td_end - maxwin)) &&
/* XXX what about big packets */
#define MAXACKWINDOW 66000
            (-ackskew <= (MAXACKWINDOW << fdata->td_winscale)) &&
            ( ackskew <= (MAXACKWINDOW << fdata->td_winscale))) {
                inseq = 1;

Darren

Reply via email to