perfSONAR User Q&A and Other Discussion

[Jon Clausen <>]

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


--

Attachment: signature.asc
Description: PGP signature