perfSONAR User Q&A and Other Discussion

["Garnizov, Ivan (RRZE)" <>]

Hi Brian,

Thanks for clarifying how sockets work. It seems like you have come yourself 
to the conclusion, which ports to open on the FW.
" it creates a socket and binds to an ephemeral port in order to send packets 
". 

Probably you should also be looking into a more secure approach with allowing 
ESTABLISHED traffic on UDP.
http://www.iptables.info/en/iptables-contents.html

Still you bring up this statement and it does not become clear, what brings 
you to it:
" Therefore, either this is an oversight, or the perfsonar developers don't 
care about whether tracepath can reach the final hop or not "

I can assure you that it is not up to the perfSONAR developers to decide or 
care about the traceroute/tracepath implementation.

Best regards,
Ivan

-----Original Message-----
From: Brian Candler 
[mailto:]
 
Sent: Dienstag, 16. Februar 2016 13:49
To: Garnizov, Ivan (RRZE); 

Subject: Re: [perfsonar-user] Perfsonar ports - tracepath blocked

On 16/02/2016 12:44, Garnizov, Ivan (RRZE) wrote:
> I believe there is something strange going on there.
> I would not expect to have a tracepath daemon listening on any port.
There is no daemon which is "listening" on this port.

perfsonar is scheduling periodic runs of tracepath. When it runs, it creates 
a socket and binds to an ephemeral port in order to send packets. When it has 
finished, it terminates.

This is just how sockets work.

>   I would not expect to have a tracepath daemon at all!
There is no tracepath daemon, only the perfsonar scheduler which periodically 
runs tracepath.

> Please share how do you come to this conclusion/inquiry: " tracepath only 
> cares about the intermediate hops and not the final destination"
perfsonar's own iptables rules do not permit tracepath packets in the port 
range I observed.

Therefore, either this is an oversight, or the perfsonar developers don't 
care about whether tracepath can reach the final hop or not.

Regards,

Brian.