Yes, this is a regression bug.. tested on my ubuntu vm with 4.13 kernel It seems that it's still in net-next,
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tree/net/tipc/socket.c#n1334 syn is always false for RDM, leading to this check to fail with EDESTADDRREQ In older kernels there was another bug where m->msg_namelen was checked (even if we used a cached sockaddr), but that seems to have been fixed Den lör 2 mars 2019 kl 19:57 skrev Erik Hugne <[email protected]>: > It was added in this one, sorry > > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/net/tipc/socket.c?id=f2f8036e391eb82ee78764483f869f2feafb5da8 > > Den lör 2 mars 2019 kl 19:21 skrev Erik Hugne <[email protected]>: > >> Hi, i dont seem to be able to post to the list for some reason.. :/ >> >> >> I'm doing some TIPC related work on the GNU bash project, and got stuck >> when i tried to set up a RDM socket and associate a sockaddr with it (as >> was introduced with this commit) >> >> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/net/tipc/socket.c?id=66bc1e8d5d1d156b1e85d8c6925225ad8cbdf523 >> >> >> sendmsg() return -EDESTADDRREQ.. >> >> I dont have any bash code to share yet, but you can reproduce the with >> the TLS demo: >> https://github.com/Hugne/tls_tipc >> > _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
