perfSONAR User Q&A and Other Discussion

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

There is something sitting behind the 36334 port and if it is tracepath, then your tracepath access is blocked.

One thing might worth checking is whether tracepath requests indeed set the correct port for the sender (in the case below 36334). But that would be, if you really would like to test the implementation of tracepath.

 

udp        0      0 0.0.0.0:36334

0.0.0.0:*                               6344/tracepath

 

Most likely some router is blocking traceroute on its way to the destination and it could be any direction.

That (direction) can be verified easily on the remote end….with sniffing.

 

 

Best regards,

Ivan

 

 

From: [mailto:] On Behalf Of Garnizov, Ivan (RRZE)
Sent: Dienstag, 16. Februar 2016 15:01
To: Andrew Lake; ; Brian Candler
Subject: RE: [perfsonar-user] Perfsonar ports - tracepath blocked

 

Hi,

 

I believe this will add more clarity: http://www.iptables.info/en/connection-state.html#UDPCONNECTIONS

 

Best regards,

Ivan

 

From: Andrew Lake []
Sent: Dienstag, 16. Februar 2016 14:57
To: ; Garnizov, Ivan (RRZE); Brian Candler
Subject: RE: [perfsonar-user] Perfsonar ports - tracepath blocked

 

Hi,

 

One clarification, we’re talking about a UDP socket so no connection is actually established. I believe tracepath, much like UDP traceroute, is just firing off UDP packets with the hope of generating ICMP error messages it can use to produce it’s results. It doesn’t much care nor expect anything on the other end. Running a few tests the tracepath tests look complete to me even to hosts blocking ephemeral UDP ports. Did you encounter some cases where this was not the case?

 

Thanks,

Andy

 

 

 

On February 16, 2016 at 8:12:35 AM, Garnizov, Ivan (RRZE) () wrote:

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 []
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.