I'll try to look at this shortly and add link support for
AF_LOCAL sockets to io-pkt.

On Fri, Mar 20, 2015 at 07:13:01PM -0400, David Alessio wrote:
> Hello,
> 
> On a QNX machine, logged in as root ($HOME is /root), suppose I have the following file:
>     /root/.ssh/config
> with the following contents:
>     Host *
>         ControlPath ~/.ssh/master-%l-%r@%h:%p
>         ControlMaster auto
> 
> I should be able to establish an initial connection to a remote host such that subsequent connections are mux'd 
through the existing connection (and don't need to go through the CPU-intensive authentication dance).
> 
> After recompiling and debugging openssh, it seems there are two issues:
> 1) OpenSSH temporally creates (in mux.c) a socket file with a random string that's later hard-linked to a persistent 
fname and the original then unlinked (deleted).  This fails with the error message akin to:
>     ln: xxx and yyy are on different file systems -
>     Can't create hard link. Use ln -s or make a copy.
> 
> I'm guessing, that the socket file is managed by pipe whereas the ln (in C: link()) is attempting to create a hard 
link between pipe's pseudo FS and the underlying QNX4/6/NFS FS which fails for obvious reasons.
> 
> 2) Having hacked OpenSSH/mux.c to "fix" the above issue, it seems that there's some inherent pathname length limit to 
the socket filename of 32.  This is strange since sizeof(address.sun_path) is 104 where address is:
>    struct sockaddr_un address;
> 
> So, my question is two fold:
> 
> 1) why is it that "funky" things happen when socket file pathnames exceed 32 byte?
> and
> 2) what's the best way to "fix" pipe (is it pipe?) so that it handles hard links?  This is IMHO important because 
several open source packages assume they can create hard links to socket files (and use this method to atomically create
 the socket file).
> 
> Cheers,
> -david
> 
>     
>  
> 
> 
> 
> 
> 
> _______________________________________________
> 
> Technology
> http://community.qnx.com/sf/go/post113579
> To cancel your subscription to this discussion, please e-mail technology-networking-unsubscribe@community.qnx.com