On Wed, Nov 07, 2012 at 03:21:14PM +0100, Holger Hans Peter Freyther wrote: Hi, I added the frame for a unit test to zecke/fr-gre-test. The reasoning is quite simple.. the frame-relay code is seldomly used during development and I really don't want to look stupid to have this error again.. :) cheers holger

Hi Holger! On Wed, Nov 07, 2012 at 03:21:14PM +0100, Holger Hans Peter Freyther wrote: $ strace ./fr [...] socket(PF_NETLINK, SOCK_RAW, 0) = 3 bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 getsockname(3, {sa_family=AF_NETLINK, pid=5936, groups=00000000}, [12]) = 0 sendto(3, "\24\0\0\0\26\0\1\3+\230\256P\0\0\0\0\0\0\0\0", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"0\0\0\0\24\0\2\0+\230\256P0\27\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 108 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"@\0\0\0\24\0\2\0+\230\256P0\27\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 128 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0+\230\256P0\27\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 The interesting thing is that the function calls rtnetlink to obtain address information from the kernel, and it seems it gets it right. Let me decipher that netlink trace: 1) bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 ^^ bind this socket to rtnetlink 2) Send the request message to ask for the address information. sendto(3, "\24\0\0\0\26\0\1\3+\230\256P\0\0\0\0\0\0\0\0", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 3) We get the multipart message with the information that we requested: recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"0\0\0\0\24\0\2\0+\230\256P0\27\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 108 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"@\0\0\0\24\0\2\0+\230\256P0\27\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 128 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, The problem seems to be in glibc, at sysdeps/posix/getaddrinfo.c, line 125: { SOCK_RAW, 0, GAI_PROTO_PROTOANY|GAI_PROTO_NOSERVICE, true, "raw" } The GAI_PROTO_NOSERVICE flag is set, while interating over the list of addresses that it has obtained from the kernel to return the addrinfo object, it seems to skip the raw protocol and it returns EAI_SERVICE. I'd need to investigate further the reason why they are doing like that. The quick thing would be to workaround libosmocore. I'll try to investigate this issue a bit more but it may take me a while. Hope it helps.

On Thu, Nov 22, 2012 at 10:36:34PM +0100, Pablo Neira Ayuso wrote: Hey! one way or another filing a bug report in the glibc bugzilla might be a good idea. we will need a workaround as the LTS of CentOS/RHEL/Debian/Ubuntu are unlikely to receive the patch. I am currently using this[1] patch but I think we can make it less ugly (e.g. try to call getaddrinfo twice, and if ai_socktype is unspecified use the caller provided one). holger [1] https://build.opensuse.org/package/view_file?expand=1&file=raw-socket.p…

On Tue, Jan 08, 2013 at 07:40:46PM +0100, Holger Hans Peter Freyther wrote: Just filed the bug to glibc, you can track it here: http://sourceware.org/bugzilla/show_bug.cgi?id=15015 Sorry for lagging with this.

Holger Hans Peter Freyther wrote: I would fall back to the same solution as for the other things that RHEL, Debian & co don't do the way I prefer: Build a replacement. But at least for Ubuntu I would expect them to be happy to apply a patch onto of their glibc package to fix this, as long as there is a launchpad bug demonstrating some concrete need - ideally backed by some paying canonical customers. :) I believe you can get any change you want into Red Hat as long as you have support and sponsorship from one of their employees. For minimum effort make friends with their glibc package maintainer. I have unsuccessfully been trying to communicate with the debian glibc package maintainer for some 8 months by now and he hasn't replied, so I think you are right that debian will "never" add a patch for fixing this, and even if they do I guess it takes some five years before that arrives to users. //Peter

On Mon, Jan 14, 2013 at 12:25:37AM +0100, Pablo Neira Ayuso wrote: Patch was incomplete, sorry. New version attached.

On Mon, Jan 14, 2013 at 08:37:17AM +0100, Holger Hans Peter Freyther wrote: Indeed. I noticed just after waking up in the morning while having breakfast. Please, check the new patch I sent you. Thanks.