barryc wrote:
>
> >Thank you - that seems to have fixed the problem . Or worked around it,
> >depending on whether it's a feature or a bug that misordered packets are
> >rejected by IP Filter - surely, since they're a legitimate/expected part of
> >normal TCP operation they should be allowed through if associated with an
> >established stateful connection ...?
>
> In this event, the errant packat is called a 'fragment' in ipf terminology
> to allow fragmented packets, add a "keep frags" clause to your rules along with
> the "keep state"
>
> see:
>
> http://www.obfuscation.org/ipf/ipf-howto.html#TOC_23
Hmmm... obfuscation in the hostname seems peculiarly appropriate to these
sort of obscure issues!
However, I just checked and all our "pass" rules for TCP include "keep
frags" (though it was rather unclear from examples I'd seen in documentation
whether that was appropriate - few examples seem to use keep frags at all,
which tends to give the impression it shouldn't normally be used).
Also, for the FTP case, the two systems are in the same computer room with
ethernet linking them (admittedly some routers in the way, but I don't see
that should cause fragmentation).
Examination of detailed traces of some failing FTP connections (taken before
implementing the suggestion to send RST only for unwanted SYN packets, which
has at least avoided connections being dropped randomly) seem to show the
RST happens when the FTP server sends a packet which is one byte larger than
the (temporarily reduced) window size just set by the system running the
mirroring script. A quick look at the TCP RFC suggests that packets are
deemed "in window" as long as they start within the declared window, even if
they "hang over the end", but that seems a strong contender as the cause of
the RSTs from IP Filter in the FTP case. (Sender - FTP server - running
Netware, receiver running the FTP mirror script is Solaris 2.6)
[There was actually one case where the receiver set a small window and
received a one-byte-larger packet without sending a RST, but an ACK
enlarging the window was logged as being sent about a millisecond later
after the incoming packet and I suspect IP Filter may have seen the window
being enlarged before seeing the packet that would have overlapped the end
of the window. Or maye the packet size is a coincidental red herring...]
John Line
--
University of Cambridge WWW manager account (usually John Line)
Send general WWW-related enquiries to [EMAIL PROTECTED]
