On Tue, 14 Nov 2006, Camiel Dobbelaar wrote:
> On Tue, 14 Nov 2006, Marc Peters wrote:
> > > What I wanted to say: notice how failinghost shrinks the TCP window to
> > > just
> > > 46 bytes ("win 46"). That's not enough to fit the long path of the
> > > directory change, so that stays in the network buffers of the firewall
> > > waiting for failinghost to send an ACK with a bigger window size ("opening
> > > up the window").
> > >
> > > Looks like failinghost is responsible for the stalled TCP connection.
> >
> > but i wonder, why it is working from the firewall-host (without proxy),
> > from a
> > host in the dmz or if i bypass ftp-proxy from the internal lan.
>
> Yes, I wonder about that as well.
>
> Can you tcpdump those working connections to failinghost?
For the archives.
It turns out that failinghost negotiated window scaling (wscale 7) during
the threeway handshake. So the windowsize of 46 was actually (46 << 7)
=> 5888 bytes.
However, state on this connection was not created on the initial SYN
packet so pf missed the windowscaling option as well.
So the fix was to add a proper keep state rule to pf.conf that created
state on the SYN packet.
Changes went into -current lately to prevent exactly this type of
problem. From OpenBSD 4.1 on, "keep state flags S/SA" will be the
default:
[EMAIL PROTECTED] $ echo "pass all" | pfctl -nvf -
pass all flags S/SA keep state
