OpenBSC

openbsc@lists.osmocom.org

13 participants
4278 discussions

nanoBTS Booster for sale
by Konrad Meier 24 Jan '13

24 Jan '13

Hi all, At the University of Freiburg (Germany) we have a nanoBTS booster 1800 for sale. Details for the booster are given here: http://www.proximus.com.ua/Nano_BTS_high_power_GSM_booster.html The package includes everything required: - Booster - Power supply - 2x cable to connect to the nanoBTS (0,5 meter) - 1x cable to the antenna (5 meter) - 1x omnidirectional antenna. 3 dBd gain / 1800 MHz The antenna is a high quality omnidirectional antenna from Procom: http://www.procom.dk/products/base-station-antennas/1.3-2.0-ghz/gain-antenn… Best regards Konrad Meier

1 0

Jan 23, 8pm / Osmocom Berlin User Group meeting
by Harald Welte 21 Jan '13

21 Jan '13

Hi all! This is the announcement for the latest incarnation of our bi-weekly Osmocom Berlin meeting. January 23, 8pm @ CCC Berlin, Marienstr. 11, 10113 Berlin There is no formal presentation scheduled for this meeting. However, we'll have a progress report + demonstration of current osmo-pcu. If you are interested to show up, feel free to do so. The meeting is free as in "free beer", despite no actual free beer being around ;) Regards, 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)

1 0

Review request for osmo-bts changes for my zecke/channel-release branch
by Holger Hans Peter Freyther 18 Jan '13

18 Jan '13

Hi, the branch is not done yet but I am confident about the first couple of commits and would like to have some extra eyes to take a look. The branch is here[1] and the general goal is to improve the reliability of the code. Under heavy use it is possible that the nitb will mark all lchans as broken. While doing the tests I noticed the following issues: 1.) On Call-Control with fast hangups (during channel modify) I can see empty FACCH messages from the DSP gsm queue. 2.) The wlc/prim request handling has the known and documented limitation that for a given confirm we do not know who sent the request. This can lead to call the 'wrong' callback with the wrong data/closure. I addressed this the following way: 1.) Add a u8Size == 0 check. For the SACCH we added a < 2 check. Should we check if a LAPDm header could fit? What would be the best limit? I have only seen u8Size == 0, so this is what I addressed.[2] 2.) I address it by passing the gsm_bts_trx as the data pointer and saving the lchan identifier in the hLayer3 pointer and then resolve the lchan from the TS. In follow up commits I introduced a new function to enter the Gsm primitive into the queue and I plan to change the callback signature for them to always include the TRX anyway. The main change is here[3]. There is still a clash between the Ciphering and the TxPower... 3.) The next commits should fix the reliability issue. I do this by keeping a queue of outstanding SAPI operations. And ACK ABIS requests when the queue becomes empty. This is mostly working right now but I have one issue with the ChannelReleaseMarker. When sending a SACCH DEACTIVATE and before the two SACCHs are deactivated send a RF Channel Release the queue appears to be stuck. cheers holger [1] http://cgit.osmocom.org/cgit/osmo-bts/log/?h=zecke/channel-release [2] http://cgit.osmocom.org/cgit/osmo-bts/commit/?h=zecke/channel-release&id=2e… [3] http://cgit.osmocom.org/cgit/osmo-bts/commit/?h=zecke/channel-release&id=af…

1 0

Documentation for Control interface in wiki?
by Harald Welte 18 Jan '13

18 Jan '13

Hi Daniel, today I was creating http://openbsc.osmocom.org/trac/wiki/PortNumbers and realised that there is no wiki page describing what the control protocol is (which I would ahve linked from PortNumbers). I know at the time you first posted the control interface patches to the list, there was some README/Documentation. Could you please add that to a wiki page, possibly reviewing/updating it to reflect today's control interface? Thanks in advance, 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 6

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 06 Jan '13

06 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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC