- OpenBSC - lists.osmocom.org

[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

[PATCH] libmsc: vty: Channel Requests statistics are already printed by openbsc_vty_print_statistics
by Jan Luebbe 28 Dec '12

28 Dec '12

From: Jan Luebbe <jluebbe(a)debian.org> We don't need the same line two times. --- openbsc/src/libmsc/vty_interface_layer3.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/openbsc/src/libmsc/vty_interface_layer3.c b/openbsc/src/libmsc/vty_interface_layer3.c index eeeb51f..2b70cad 100644 --- a/openbsc/src/libmsc/vty_interface_layer3.c +++ b/openbsc/src/libmsc/vty_interface_layer3.c @@ -728,9 +728,6 @@ DEFUN(show_stats, struct gsm_network *net = gsmnet_from_vty(vty); openbsc_vty_print_statistics(vty, net); - vty_out(vty, "Channel Requests : %lu total, %lu no channel%s", - osmo_counter_get(net->stats.chreq.total), - osmo_counter_get(net->stats.chreq.no_channel), VTY_NEWLINE); vty_out(vty, "Location Update : %lu attach, %lu normal, %lu periodic%s", osmo_counter_get(net->stats.loc_upd_type.attach), osmo_counter_get(net->stats.loc_upd_type.normal), -- 1.7.10.4

1 0

[PATCH] libmsc: vty: Channel Requests statistics are already printed by openbsc_vty_print_statistics
by Jan Luebbe 27 Dec '12

27 Dec '12

We don't need the same line two times. --- openbsc/src/libmsc/vty_interface_layer3.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/openbsc/src/libmsc/vty_interface_layer3.c b/openbsc/src/libmsc/vty_interface_layer3.c index eeeb51f..2b70cad 100644 --- a/openbsc/src/libmsc/vty_interface_layer3.c +++ b/openbsc/src/libmsc/vty_interface_layer3.c @@ -728,9 +728,6 @@ DEFUN(show_stats, struct gsm_network *net = gsmnet_from_vty(vty); openbsc_vty_print_statistics(vty, net); - vty_out(vty, "Channel Requests : %lu total, %lu no channel%s", - osmo_counter_get(net->stats.chreq.total), - osmo_counter_get(net->stats.chreq.no_channel), VTY_NEWLINE); vty_out(vty, "Location Update : %lu attach, %lu normal, %lu periodic%s", osmo_counter_get(net->stats.loc_upd_type.attach), osmo_counter_get(net->stats.loc_upd_type.normal), -- 1.7.10.4

1 0

[PATCH] gsm_subscriber: change subscr_bsc_active_subscriber to plural
by Jan Luebbe 25 Dec '12

25 Dec '12

This was requested by Holger Freyther <zecke(a)selfish.org>. --- openbsc/src/libbsc/gsm_subscriber_base.c | 10 +++++----- openbsc/src/libmsc/gsm_subscriber.c | 10 +++++----- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/openbsc/src/libbsc/gsm_subscriber_base.c b/openbsc/src/libbsc/gsm_subscriber_base.c index 11afb35..747a699 100644 --- a/openbsc/src/libbsc/gsm_subscriber_base.c +++ b/openbsc/src/libbsc/gsm_subscriber_base.c @@ -35,7 +35,7 @@ LLIST_HEAD(active_subscribers); void *tall_subscr_ctx; /* for the gsm_subscriber.c */ -struct llist_head *subscr_bsc_active_subscriber(void) +struct llist_head *subscr_bsc_active_subscribers(void) { return &active_subscribers; } @@ -95,7 +95,7 @@ struct gsm_subscriber *subscr_get_or_create(struct gsm_network *net, { struct gsm_subscriber *subscr; - llist_for_each_entry(subscr, subscr_bsc_active_subscriber(), entry) { + llist_for_each_entry(subscr, subscr_bsc_active_subscribers(), entry) { if (strcmp(subscr->imsi, imsi) == 0 && subscr->net == net) return subscr_get(subscr); } @@ -113,7 +113,7 @@ struct gsm_subscriber *subscr_active_by_tmsi(struct gsm_network *net, uint32_t t { struct gsm_subscriber *subscr; - llist_for_each_entry(subscr, subscr_bsc_active_subscriber(), entry) { + llist_for_each_entry(subscr, subscr_bsc_active_subscribers(), entry) { if (subscr->tmsi == tmsi && subscr->net == net) return subscr_get(subscr); } @@ -125,7 +125,7 @@ struct gsm_subscriber *subscr_active_by_imsi(struct gsm_network *net, const char { struct gsm_subscriber *subscr; - llist_for_each_entry(subscr, subscr_bsc_active_subscriber(), entry) { + llist_for_each_entry(subscr, subscr_bsc_active_subscribers(), entry) { if (strcmp(subscr->imsi, imsi) == 0 && subscr->net == net) return subscr_get(subscr); } @@ -138,7 +138,7 @@ int subscr_purge_inactive(struct gsm_network *net) struct gsm_subscriber *subscr, *tmp; int purged = 0; - llist_for_each_entry_safe(subscr, tmp, subscr_bsc_active_subscriber(), entry) { + llist_for_each_entry_safe(subscr, tmp, subscr_bsc_active_subscribers(), entry) { if (subscr->net == net && subscr->use_count <= 0) { subscr_free(subscr); purged += 1; diff --git a/openbsc/src/libmsc/gsm_subscriber.c b/openbsc/src/libmsc/gsm_subscriber.c index f9eebc8..0889400 100644 --- a/openbsc/src/libmsc/gsm_subscriber.c +++ b/openbsc/src/libmsc/gsm_subscriber.c @@ -39,7 +39,7 @@ void *tall_sub_req_ctx; -extern struct llist_head *subscr_bsc_active_subscriber(void); +extern struct llist_head *subscr_bsc_active_subscribers(void); int gsm48_secure_channel(struct gsm_subscriber_connection *conn, int key_seq, gsm_cbfn *cb, void *cb_data); @@ -272,7 +272,7 @@ struct gsm_subscriber *subscr_get_by_tmsi(struct gsm_network *net, struct gsm_subscriber *subscr; /* we might have a record in memory already */ - llist_for_each_entry(subscr, subscr_bsc_active_subscriber(), entry) { + llist_for_each_entry(subscr, subscr_bsc_active_subscribers(), entry) { if (tmsi == subscr->tmsi) return subscr_get(subscr); } @@ -286,7 +286,7 @@ struct gsm_subscriber *subscr_get_by_imsi(struct gsm_network *net, { struct gsm_subscriber *subscr; - llist_for_each_entry(subscr, subscr_bsc_active_subscriber(), entry) { + llist_for_each_entry(subscr, subscr_bsc_active_subscribers(), entry) { if (strcmp(subscr->imsi, imsi) == 0) return subscr_get(subscr); } @@ -299,7 +299,7 @@ struct gsm_subscriber *subscr_get_by_extension(struct gsm_network *net, { struct gsm_subscriber *subscr; - llist_for_each_entry(subscr, subscr_bsc_active_subscriber(), entry) { + llist_for_each_entry(subscr, subscr_bsc_active_subscribers(), entry) { if (strcmp(subscr->extension, ext) == 0) return subscr_get(subscr); } @@ -314,7 +314,7 @@ struct gsm_subscriber *subscr_get_by_id(struct gsm_network *net, char buf[32]; sprintf(buf, "%llu", id); - llist_for_each_entry(subscr, subscr_bsc_active_subscriber(), entry) { + llist_for_each_entry(subscr, subscr_bsc_active_subscribers(), entry) { if (subscr->id == id) return subscr_get(subscr); } -- 1.7.10.4

1 0

Please review and test zecke/channel-release
by Holger Hans Peter Freyther 16 Dec '12

16 Dec '12

Hi, I have rebased, extended and fixed the channel assignment and release. It brings us closer to the GSM 04.08 specification but there are still sime minor violations for the abnormal handling. I have tested (using the FakeBTS) a phone not acting on the SACCH deactivate/RF Channel Release and the signalling link will be released (T3109). I have a manual SMS submit test and I can make the nanoBTS crash easily. I have rebased through each individual change and couldn't reproduce the crash. I think it is either something in the RF setup (the modem bank being too close to the BTS), the older modem firmware, etc. Anyway, please review and test the branch. I plan to merge it by Wednesday. thanks holger

1 0