7 Nov
2012
7 Nov
'12
3:21 p.m.
Dear Pablo,
getaddrinfo does not work for the combination of AF_INET, SOCK_RAW
and IPPROTO_GRE. I have attached an example application that can be
compiled with:
$ gcc -o fr fr.c `pkg-config --cflags --libs libosmocore libosmogb`
this prints:
getaddrinfo returned NULL: Success
FAILED
gettadrinfo returns -8 which should be this:
# define EAI_SERVICE -8 /* SERVICE not supported for `ai_socktype'. */
I am not sure what is the most clever way to resolve this. Make SOCK_RAW
branch out early and do the socket/bind(/listen) manually, use getaddrinfo
twice with some more unspefici options, just deal with SOCK_RAW differently
now? The attached code has the benefit of at least handling INET and INET6
inside the getaddrinfo result.
any ideas?
holger
11 Nov
11 Nov
2:47 p.m.
On Wed, Nov 07, 2012 at 03:21:14PM +0100, Holger Hans Peter Freyther wrote:
Dear Pablo,
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
10:36 p.m.
Hi Holger!
On Wed, Nov 07, 2012 at 03:21:14PM +0100, Holger Hans Peter Freyther wrote:
Dear Pablo,
getaddrinfo does not work for the combination of AF_INET, SOCK_RAW
and IPPROTO_GRE. I have attached an example application that can be
compiled with:
$ gcc -o fr fr.c `pkg-config --cflags --libs libosmocore libosmogb`
this prints:
getaddrinfo returned NULL: Success
FAILED
$ 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.
gettadrinfo returns -8 which should be this:
# define EAI_SERVICE -8 /* SERVICE not supported for `ai_socktype'. */
I am not sure what is the most clever way to resolve this. Make SOCK_RAW
branch out early and do the socket/bind(/listen) manually, use getaddrinfo
twice with some more unspefici options, just deal with SOCK_RAW differently
now? The attached code has the benefit of at least handling INET and INET6
inside the getaddrinfo result.
any ideas?
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.
10:38 p.m.
On Thu, Nov 22, 2012 at 10:36:34PM +0100, Pablo Neira Ayuso wrote:
Hi Holger!
On Wed, Nov 07, 2012 at 03:21:14PM +0100, Holger Hans Peter Freyther wrote:
To be more precise, it returns EAI_SERVICE before even iterating over
the list of address.
This behaviour seems a bit inconsistent to me, ie. requst data from
the kernel, get it all right and discard it :-)
Dear Pablo,
getaddrinfo does not work for the combination of AF_INET, SOCK_RAW
and IPPROTO_GRE. I have attached an example application that can be
compiled with:
$ gcc -o fr fr.c `pkg-config --cflags --libs libosmocore libosmogb`
this prints:
getaddrinfo returned NULL: Success
FAILED
$ 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.
23 Nov
23 Nov
11:06 a.m.
On Thu, Nov 22, 2012 at 10:36:34PM +0100, Pablo Neira Ayuso wrote:
Hi Holger!
Hey!
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.
one way or another filing a bug report in the glibc bugzilla might be
a good idea.
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.
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…
8 Jan
8 Jan
7:40 p.m.
On Fri, Nov 23, 2012 at 11:06:56AM +0100, Holger Hans Peter Freyther wrote:
On Thu, Nov 22, 2012 at 10:36:34PM +0100, Pablo Neira
Ayuso wrote:
> Hi Holger!
Hi Pablo,
this is still an issue for running the SGSN/GBproxy. Do you have an
uptime in regard to the proper fix? I am going to land the workaround
soon but I am interested in getting the real fix into glibc. Can you
help?
holger
13 Jan
13 Jan
12:30 a.m.
On Tue, Jan 08, 2013 at 07:40:46PM +0100, Holger Hans Peter Freyther wrote:
On Fri, Nov 23, 2012 at 11:06:56AM +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.
On Thu, Nov 22, 2012 at 10:36:34PM +0100, Pablo
Neira Ayuso wrote:
> Hi Holger!
Hi Pablo,
this is still an issue for running the SGSN/GBproxy. Do you have an
uptime in regard to the proper fix? I am going to land the workaround
soon but I am interested in getting the real fix into glibc. Can you
help?
1:24 a.m.
On Sun, Jan 13, 2013 at 12:30:33AM +0100, Pablo Neira Ayuso 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.
thanks! any idea of a non ugly work-around. Even if it is glibc bug,
and it will be fixed.. RHEL, Debian 6.0 will unlikely patch it.
holger
9:06 a.m.
Holger Hans Peter Freyther wrote:
thanks! any idea of a non ugly work-around. Even if it is glibc bug,
and it will be fixed.. RHEL, Debian 6.0 will unlikely patch it.
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
14 Jan
14 Jan
12:25 a.m.
On Sun, Jan 13, 2013 at 01:24:13AM +0100, Holger Hans Peter Freyther wrote:
On Sun, Jan 13, 2013 at 12:30:33AM +0100, Pablo Neira
Ayuso wrote:
Attached a workaround patch. It's a bit of cheating, but it allows us
to obtain the address information from the kernel, which is what you
need. As Peter mentioned, let's find a fast path to resolve this until
some fix lands on glibc.
Let me know!
Regards.
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.
thanks! any idea of a non ugly work-around. Even if it is glibc bug,
and it will be fixed.. RHEL, Debian 6.0 will unlikely patch it.
8:12 a.m.
On Mon, Jan 14, 2013 at 12:25:37AM +0100, Pablo Neira Ayuso wrote:
On Sun, Jan 13, 2013 at 01:24:13AM +0100, Holger Hans
Peter Freyther wrote:
Patch was incomplete, sorry. New version attached.
On Sun, Jan 13, 2013 at 12:30:33AM +0100, Pablo
Neira Ayuso wrote:
Attached a workaround patch. It's a bit of cheating, but it allows us
to obtain the address information from the kernel, which is what you
need. As Peter mentioned, let's find a fast path to resolve this until
some fix lands on glibc.
Let me know! 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.
thanks! any idea of a non ugly work-around. Even if it is glibc bug,
and it will be fixed.. RHEL, Debian 6.0 will unlikely patch it.
8:37 a.m.
On Mon, Jan 14, 2013 at 12:25:37AM +0100, Pablo Neira Ayuso wrote:
Hi,
this appears to be only half of the fix.
- hints.ai_socktype = type;
- hints.ai_flags = 0;
- hints.ai_protocol = proto;
+ if (type == SOCK_RAW) {
+ /* Workaround for glibc, that returns EAI_SERVICE (-8) if
+ * SOCK_RAW and IPPROTO_GRE is used.
+ */
+ hints.ai_socktype = SOCK_DGRAM;
+ hints.ai_protocol = IPPROTO_UDP;
+ } else {
+ hints.ai_socktype = type;
+ hints.ai_protocol = proto;
+ }
now rp->ai_socktype will be SOCK_DGRAM and rp->ai_protocol UDP. So the
'raw'
socket for GRE will be a datagram socket for UDP.
E.g. you need the second hunk from my workaround[1]. I just wondered if you
could think about a better way (one that can be easily dumped or ifdefed
without putting the special case in the middle).
holger
[1]
https://build.opensuse.org/package/view_file?expand=1&file=raw-socket.p…
12:05 p.m.
On Mon, Jan 14, 2013 at 08:37:17AM +0100, Holger Hans Peter Freyther wrote:
On Mon, Jan 14, 2013 at 12:25:37AM +0100, Pablo Neira
Ayuso wrote:
Hi,
this appears to be only half of the fix.
Indeed. I noticed just after waking up in the morning while having
breakfast. Please, check the new patch I sent you.
Thanks.
- hints.ai_socktype = type;
- hints.ai_flags = 0;
- hints.ai_protocol = proto;
+ if (type == SOCK_RAW) {
+ /* Workaround for glibc, that returns EAI_SERVICE (-8) if
+ * SOCK_RAW and IPPROTO_GRE is used.
+ */
+ hints.ai_socktype = SOCK_DGRAM;
+ hints.ai_protocol = IPPROTO_UDP;
+ } else {
+ hints.ai_socktype = type;
+ hints.ai_protocol = proto;
+ }
now rp->ai_socktype will be SOCK_DGRAM and rp->ai_protocol UDP. So the
'raw'
socket for GRE will be a datagram socket for UDP.
E.g. you need the second hunk from my workaround[1]. I just wondered if you
could think about a better way (one that can be easily dumped or ifdefed
without putting the special case in the middle).
4122
days inactive
4190
days old
13 comments
3 participants
participants (3)
-
Holger Hans Peter Freyther -
Pablo Neira Ayuso -
Peter Stuge