Difference between revisions of "Tools/Manuals/TS23"
imported>Krakow |
|
(No difference)
|
Revision as of 13:43, 23 November 2012
Main | EGI.eu operations services | Support | Documentation | Tools | Activities | Performance | Technology | Catch-all Services | Resource Allocation | Security |
Documentation menu: | Home • | Manuals • | Procedures • | Training • | Other • | Contact ► | For: | VO managers • | Administrators |
Back to Troubleshooting Guide
gridftp works only once within a minute or so
$ uberftp some-SE.example.org dir # This works. [...] $ sleep 5 $ uberftp some-SE.example.org dir # This hangs. [...] $ sleep 120 $ uberftp some-SE.example.org dir # This works again. [...]
Diagnosis
This would be caused by a bad interaction between the Globus I/O library and a firewall at some sites.
In older versions of Globus the client would bind its end of a socket to the first free port in the GLOBUS_TCP_PORT_RANGE, even when that functionality only made sense for sockets on which incoming connections are received, i.e. normally only on the server side. The library then may reuse a port that was recently used for another connection for which a socket might even still exist in the TIME_WAIT state.
Some firewalls may conclude that the second client is misconfigured or trying to abuse the first connection and therefore block the second client request.
In recent versions of Globus (e.g. distributed with gLite 3.2) the client will let the OS pick a "random" port for the local end of the socket, unless the environment variable GLOBUS_TCP_SOURCE_RANGE (sic) is defined; that variable should never be set.
Solution
- Use a more recent version of Globus on the client (or unset GLOBUS_TCP_PORT_RANGE).
- Do not set GLOBUS_TCP_SOURCE_RANGE (sic) on the client.
- Reconfigure the firewall so that it does not monitor the state of inbound connections for the SE in its Globus port range.
- Take the problem up with your firewall manufacturers, they may be able to provide a solution or suggestion.
- Buy a better-behaved firewall.
OpenBSD Specific Configuration
It has been discovered that for OpenBSD firewalls running "pf" (the default OpenBSD firewall) adding "keep state flags S/SAFR" to the end of the rules fixes the problem.