On Tue, 18 Apr 2006, Victor Duchovni wrote:
On Tue, Apr 18, 2006 at 11:17:30AM +0100, John Line wrote:
We've been using IP Filter V3.4.31 on Solaris 9 (SPARC, 64-bit; compiled
with Sun's C compiler) for a year or two on some of our servers, and it was
working fine except for an obscure problem [1] that came to light fairly
recently, which prompted me to try a current version to see if that would
cure the problem.
3.4.3x gets TCP window scaling wrong, FTP servers and clients tend
to set large socket buffers, when these exceed 64k, window scaling is
typically negotiated. The patch below is for 3.4.35. If you are
willing to try 3.4.3x, it may as well be the most up-to-date version
(3.4.35 + this patch).
...
I apologise for the long silence since my original message and the above
reply. Thank you very much for explaining the original (v3) problem, that
prompted me to try upgrading. That certainly sounds very much like the
explanation for my hanging uploads.
However, I've already upgraded one system to V4 - which also cured the
problem - it presumably includes the patch or equivalent changes - so
that unless there are good reasons for sticking with V3 rather than
upgrading to V4 (4.1.13 is what I used) on Solaris 9 (SPARC), I'd prefer
to upgrade the others to V4 as well.
But that then brings us back to the new/different problem which I
encountered with FTP and V4, and I've not seen any comments on that.
Passive FTP connections (from the Sun server running IP Filter) to a Mac
running the NetPresenz FTP server worked fine with the old V3 IP Filter,
but after I upgraded to V4 failed consistently (when using a mirroring
script to synchronise an existing local mirror with the FTP server's
content).
The initial phase of the script's operation (collecting directory listings
for comparison with the existing local files) failed when it reached a
particular directory, although a manual FTP connection looking only at
that directory worked as expected.
The failure appeared to be at or near the 32nd directory listing, which
(being a power of 2, hence potentially "special") made me wonder whether
there was a limit at one end or the other on the number of ports that
could be used for FTP data connections, with the FTP server being the
likely candidate.
However, it had worked just fine with IP Filter V3 and the FTP server was
unchanged (and it still works with V3 using a different system as FTP
client), so I can't see why the script should suddenly start hitting such
a limit (if, in reality, there is a limit) in the FTP server, unless it
was marginal before (e.g. due to the mandatory timeouts before ports can
be reused) and V4's allowing it to run consistently faster by enough to
trigger the problem. Maybe possible, but my "gut feeling" is that it seems
unlikely to be the explanation. The FTP server log file only records that
the connection was aborted, not why.
That leaves me wondering why the FTP problem has arisen - it can be worked
around by using active FTP, but it ought to "just work" with passive - and
without any clues to which end is at fault, it leaves me unsure whether to
upgrade the remaining Sun servers to IP V4 or if I should stick with V3
(at which point the patch suggested above might become relevant), or if
it's safe to upgrade to V4 on the other Sun servers.
I'd be very grateful for any suggested plausible/likely explanations of
the observed oddity (especially if they'd point to it being an FTP server
issue, rather than IP Filter!). Alternatively, if V4's being used widely
on Solaris 9 systems without any apparent problems, it would be reassuring
to know that.
John Line
--
John Line - web & news development, University of Cambridge Computing Service
