Bug 3194 - UDP usage stats port fw issues
: UDP usage stats port fw issues
Status: RESOLVED FIXED
: XIO
Globus XIO
: 4.0.0
: PC Linux
: P3 enhancement
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-04-19 14:37 by
Modified: 2005-09-07 11:45 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-04-19 14:37:50
The UDP usage stats port binds outside the range of ports permitted by a
firewall. The Gridftp server/clients recognize the variable
GLOBUS_UDP_PORT_RANGE (GUPR) to enable an admin to bind the usage stats to a
permitted port range. This variable does not appear to have an effect on the
GRAM client nor service, e.g. here a gridftp server daemon, and a globusrun-ws
client: 

globus-gr 17084 voeckler    0u  IPv4 25226301       TCP xxx:gridftp->yyy:23558
(ESTABLISHED)
globus-gr 17084 voeckler    7u  IPv4 25226305       UDP *:61443 

globusrun 17134 voeckler    7u  IPv4 25226404       UDP *:18989 
globusrun 17134 voeckler    8u  IPv4 25226413       TCP *:61462 (LISTEN)
globusrun 17134 voeckler    9u  IPv4 25226420       TCP xxx:61504->yyy:8443
(ESTABLISHED)

Please note how the UDP listener in the GRAM client does not fall within the
permitted GUPR while the gridftp server does. 

I believe this needs to be fixed in GRAM in at least two ways:

[1] GRAM needs to evaluate GUPR for its own stats service:

GRAM itself needs to recognize and use GUPR in order to permit an administrator
to limit the legal port range, and synchronize with existing firewalls. 

[2] GRAM needs to pass GUPR along:

The GUPR variable is as "special" as GLOBUS_TCP_PORT_RANGE (GTPR) and
GLOBUS_TCP_SOURCE_RANGE (GTSR). While GRAM supports GTPR, support for passing
GTSR is planned for 4.0.1 AFAIK. GUPR should also be supported similarily.
------- Comment #1 From 2005-05-11 14:16:52 -------
I added support for GUSPR for the Java applications. Fixes committed to trunk 
so far. So any Java client using the 'usage' API should automatically bind to a 
local port within a port range if the env. property is set. So this is now a 
problem in the C code, reassigning...
------- Comment #2 From 2005-05-11 14:34:41 -------
What about GLOBUS_TCP_SOURCE_RANGE in the Java portion? The last time I looked, 

[1] it was not supported, and 
[2] not configurable in the gram-service/jndi-config.xml section. 
------- Comment #3 From 2005-08-25 23:05:44 -------
Btw, the support for GLOBUS_TCP_SOURCE_RANGE in Java was committed to trunk 
recently (as part of the connection persistence work).
------- Comment #4 From 2005-08-30 15:08:51 -------
Joe,

not sure if this is a problem in globusrun-ws or in the c-hosting or both.  Either way, I am reassigning.

-Stu
------- Comment #5 From 2005-08-31 19:20:49 -------
GRAM doesn't have anything to do with the usage stats implementation. This is
likely an UDP XIO driver bug.
------- Comment #6 From 2005-09-07 01:50:11 -------
I am a little confussed by this bug.  Are you saying that a globus based gram
client written in C is not obeying the GLOBUS_UDP_PORT_RANGE, yet a globus based
gridftp client is not?
------- Comment #7 From 2005-09-07 02:00:15 -------
Subject: Re:  UDP usage stats port fw issues

> I am a little confussed by this bug.  Are you saying that a globus based gram
> client written in C is not obeying the GLOBUS_UDP_PORT_RANGE, yet a globus based
> gridftp client is not?

i ment to say: "gridftp client is?" not "gridftp client is not?"

------- Comment #8 From 2005-09-07 11:02:34 -------
If your question was directed at me: I only reported what I saw. The gridftp
server appeared to obey GUPR, the GRAM client did not. IMO, GUPR should be
supported by all: C and Java, clients and servers. Please note that that was
four month ago, and much of GT has changed in the meantime. 
------- Comment #9 From 2005-09-07 11:45:18 -------
I am going to mark this as closed.  it seems jarek has taken care of the java
code and the C code was already in order