perfSONAR User Q&A and Other Discussion

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

Hello Jon,

Your point for the error message is good:
""no route to host" *is* pretty specific, and does suggest a routing issue."

The problem with this is, that the message is labeled as it is by the kernel. 
I guess you will agree it will not be a good idea to substitute the kernel 
messages on our side.
IMHO the only improvement pS Dev could consider is to state the source of the 
message. Thus it would be easier to differentiate between events from kernel, 
external application and the service itself.

Regards,
Ivan Garnizov

GEANT SA1T2: pS deployments GN Operations
GEANT SA2T3: pS development team
GEANT SA3T5: eduPERT team



-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Jon Clausen
Sent: Freitag, 4. August 2017 15:33
To: Mark Feit
Cc: 

Subject: Re: [perfsonar-user] powstream, misleading log entries

On 2017-08-04 12:52:46 (+0000), Mark Feit wrote:
> Jon Clausen writes:
> 

>     Now, I *think* this classifies as a bug, because the logged info is 
> actively
>     misleading. But it's going to be a while before I'd be able to identify
>     which component to report the bug against.
> 
> Connections rejected for administrative reasons get lumped in with the “no 
> route to host” error returned by the kernel.  All that comes back is a 
> number that gets mapped to that string, and there aren’t separate errors 
> for anything more specific than that. 

right

> I agree that the message is a bit misleading in this situation, but it does 
> fit in a “no way to get there” sort of way even if it’s not the routing.  
> If you’d tried connecting to fi-csc-pstp01-mi1.nordu.net:861 with anything 
> else (telnet, nc, etc.) while that port was blocked, you’d have got the 
> same error.

fair enough, I hadn't actually tried (or considered) that, but you're right:
I just tested with nc towards another firewalled port, and it does indeed 
claim 'no route to host', so...

> Any changes to make the message more accurate and informative would 
> have to take place in the kernel and the C library.  As you might have 
> guessed, we don’t maintain either and are bound by their behavior.  
> :-)

heh, yeah :)

It's pretty far from optimal, but there are so many ways things can fail, 
that it's probably not easy to return accurate information in many situations 
- but I would personally have preferred a more generic message.

"no route to host" *is* pretty specific, and does suggest a routing issue.
But at least now I know.

> 
>     Maybe, actually, a couple of pointers on how to submit bug reports?
>     
> Asking on the perfsonar-users is a good start.  If you’re positive you’ve 
> found a bug, you can also drop us a line directly on the 
> perfsonar-developers list.  The perfSONAR project on GitHub 
> (https://github.com/perfsonar) is divided up into many sub-projects, each 
> with its own issue tracker, so I don’t recommend submitting bugs directly 
> there unless you know which component is the problem.

Thanks for this :)

br
/jon


--