OpenBSC January 2013

openbsc@lists.osmocom.org

16 participants
18 discussions

osmo_sock_init/getaddrinfo not working for GRE/SOCKET_RAW
by Holger Hans Peter Freyther 14 Jan '13

14 Jan '13

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

3 13

[PATCH] socket: fix osmo_sock_init with SOCK_RAW and IPPROTO_RAW
by Pablo Neira Ayuso 14 Jan '13

14 Jan '13

getaddrinfo returns EAI_SERVICE (-8) if that combination is used. More information available in here: http://sourceware.org/bugzilla/show_bug.cgi?id=15015 Reported by Holger Hans Peter Freyther. While at it, this patch also removes hints.ai_flags = 0 as memset to zero already happened just a bit before that. --- src/socket.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/src/socket.c b/src/socket.c index 53205cd..a5530d0 100644 --- a/src/socket.c +++ b/src/socket.c @@ -54,9 +54,16 @@ int osmo_sock_init(uint16_t family, uint16_t type, uint8_t proto, sprintf(portbuf, "%u", port); memset(&hints, 0, sizeof(struct addrinfo)); hints.ai_family = family; - 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; + } if (flags & OSMO_SOCK_F_BIND) hints.ai_flags |= AI_PASSIVE; @@ -68,6 +75,12 @@ int osmo_sock_init(uint16_t family, uint16_t type, uint8_t proto, } for (rp = result; rp != NULL; rp = rp->ai_next) { + /* Workaround for glibc again */ + if (type == SOCK_RAW) { + rp->ai_socktype = SOCK_RAW; + rp->ai_protocol = proto; + } + sfd = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol); if (sfd == -1) continue; -- 1.7.10.4 --EeQfGwPcQSOJBaQU--

1 0

[PATCH] socket: fix osmo_sock_init with SOCK_RAW and IPPROTO_RAW
by Pablo Neira Ayuso 14 Jan '13

14 Jan '13

getaddrinfo returns EAI_SERVICE (-8) if that combination is used. More information available in here: http://sourceware.org/bugzilla/show_bug.cgi?id=15015 Reported by Holger Hans Peter Freyther. While at it, this patch also removes hints.ai_flags = 0 as memset to zero already happened just a bit before that. --- src/socket.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/src/socket.c b/src/socket.c index 53205cd..0f41275 100644 --- a/src/socket.c +++ b/src/socket.c @@ -54,9 +54,16 @@ int osmo_sock_init(uint16_t family, uint16_t type, uint8_t proto, sprintf(portbuf, "%u", port); memset(&hints, 0, sizeof(struct addrinfo)); hints.ai_family = family; - 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; + } if (flags & OSMO_SOCK_F_BIND) hints.ai_flags |= AI_PASSIVE; -- 1.7.10.4 --IS0zKkzwUGydFO0o--

1 0

fosdem?
by Hans Witvliet 07 Jan '13

07 Jan '13

hi all, Any chance of giving presentation/demo at fosdem (1+2 feb)? Hans

3 2

[PATCH] core/msgb: Change return value of msgb_pull to the start of pulled header
by Sylvain Munaut 05 Jan '13

05 Jan '13

From: Sylvain Munaut <tnt(a)246tNt.com> Currently msgb_pull returns a pointer to the new start of msgb, which is pretty counter intuitive and when using msgb_pull is often annoying. For eg, the msgb_pull_u{8,16,32} were previously "fixed" for this quirk in a previous commit. The msgb_pull_l2h in lapdm is also wrong because of this, same for code in osmocom-bb loader. AFAICT, the current users of msgb_pull either don't care about the return value, or expect it to be a pointer to the pulled header and not the new start of msgb (and so are currently buggy). Without this patch, you have things like: struct foo *bar = msgb_pull(msg, sizeof(struct foo)) - sizeof(struct foo) With the patch, you have: struct foo *bar = msgb_pull(msg, sizeof(struct foo)); which is IMHO a much better style. Signed-off-by: Sylvain Munaut <tnt(a)246tNt.com> --- include/osmocom/core/msgb.h | 14 ++++++++------ 1 files changed, 8 insertions(+), 6 deletions(-) diff --git a/include/osmocom/core/msgb.h b/include/osmocom/core/msgb.h index a1939ab..4a72f2d 100644 --- a/include/osmocom/core/msgb.h +++ b/include/osmocom/core/msgb.h @@ -287,16 +287,18 @@ static inline unsigned char *msgb_push(struct msgb *msgb, unsigned int len) /*! \brief remove (pull) a header from the front of the message buffer * \param[in] msgb message buffer * \param[in] len number of octets to be pulled - * \returns pointer to new start of msgb + * \returns pointer to header that's been pulled (i.e. previous start of msgb) * * This function moves the \a data pointer of the \ref msgb further back * in the message, thereby shrinking the size of the message by \a len * bytes. */ static inline unsigned char *msgb_pull(struct msgb *msgb, unsigned int len) -{ +{ + unsigned char *tmp = msgb->data; msgb->len -= len; - return msgb->data += len; + msgb->data += len; + return tmp; } /*! \brief remove uint8 from front of message @@ -305,7 +307,7 @@ static inline unsigned char *msgb_pull(struct msgb *msgb, unsigned int len) */ static inline uint8_t msgb_pull_u8(struct msgb *msgb) { - uint8_t *space = msgb_pull(msgb, 1) - 1; + uint8_t *space = msgb_pull(msgb, 1); return space[0]; } /*! \brief remove uint16 from front of message @@ -314,7 +316,7 @@ static inline uint8_t msgb_pull_u8(struct msgb *msgb) */ static inline uint16_t msgb_pull_u16(struct msgb *msgb) { - uint8_t *space = msgb_pull(msgb, 2) - 2; + uint8_t *space = msgb_pull(msgb, 2); return space[0] << 8 | space[1]; } /*! \brief remove uint32 from front of message @@ -323,7 +325,7 @@ static inline uint16_t msgb_pull_u16(struct msgb *msgb) */ static inline uint32_t msgb_pull_u32(struct msgb *msgb) { - uint8_t *space = msgb_pull(msgb, 4) - 4; + uint8_t *space = msgb_pull(msgb, 4); return space[0] << 24 | space[1] << 16 | space[2] << 8 | space[3]; } -- 1.7.8.6

1 0

triplets calculation
by Yann R. Moupinda 04 Jan '13

04 Jan '13

Hi guys, i'm still testing the eap-sim authentication and lately i got acceptable results using a simple flat file containing the triplets of specific SIM cards. Next step will be to enable the external radius server to use the sysmoBTS database hlr.sqlite3, so the OpenBSC users (Users using the OpenBSC-GSM Network) can automatically access to the internet. i just want to ask if there are any limitations with the sysmocom SIM cards? In fact, i noticed that by using the sysmocom sim cards, the eap-sim authentication failed when the RAND values strong randomly chosen were, e.g 046DBA898016454aB3920C58180DA2F5 or e177842fe16c47de84784be1b4141c27. But when i chose a RAND like this 10101010101010101010101010101010, 0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F or 00000000000000000000000000000000, the authentication succeeded. By using an other sim (not from sysmocom) with the same strong and weak RAND values the authentication always succeeded. Why does the authentication succeed buy using sysmocom sim card with weak RAND (10101010101010101010101010101010) and fail by using strong RAND values (e177842fe16c47de84784be1b4141c27) ? best regards Yann

3 5

OsmoDevCon 2013 brainstorming
by Harald Welte 04 Jan '13

04 Jan '13

Hi all, as the year 2012 has already ended or will soon end depending on your timezone, it might be a good occasion to start thinking of an OsmoDevCon 2013. I personally percevied OsmoDevCon 2012 as a big success, and it was fun to bring everyone together. Generally, I prefer to keep the spirit of an invitation-only developer+contributor-only event of those involved in Osmocom. At the same time, I would consider it a good idea to add a one day user-conference to the schedule, where we try to get interested users up to speed with the various projects, possibly including some workshops and the like. So schedule-wise, I would suggest something like: * one day user conference * two day developer/contributor event * optionally: 1-2 "hacking days". The concept of "hacking days" has proven to be quite useful for the netfilter project in the past (Pablo and I can acknowledge to that fact). I'm not sure how many people would be able to spend even more days of their schedule, but even if it's a much smaller group it would still be useful, IMHO. I'd like you to 1) provide feedback on the ideas about the one-day user event and the hacking days 2) consider whether late march (like 2012) would be a good schedule again 3) what we can improve from the last event In terms of improvements, I so far have noted down: * larger venue needs to be found * complaints about the venue not having sufficient heating Venue-wise, I would again suggest to hold it in Berlin, as it's reasonbly well connected, has lots of low-cost flights to it, accomodation is not too expensive and holger/me/sysmocom can take care of local organization related activities. Hoewver, if somebody has a strong opinion against berlin _and_ is willing to organize it, I'm not completely against another venue. Regards and happy new year, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 7

[PATCH] libosmocore osmo_revbytebits_buf stack trashing
by noselasd＠fiane.dyndns.org 03 Jan '13

03 Jan '13

Hi, The second loop in osmo_revbytebits_buf() in src/bits.c grabs 4 bytes each iteration, which can easily go past the supplied input in some cases. Compiled with -fstack-protector , I get a "stack smashing detected" in the bits test. Attached patch should deal with that.

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC January 2013