OpenBSC

openbsc@lists.osmocom.org

20 participants
4286 discussions

CDR-like logs
by Suraev 05 Nov '15

05 Nov '15

Hi. If I enable detailed-enough logs of OpenBSC I can get data regarding call and sms transactions: new state INITIATED -> MO_CALL_PROC, 1 active transactions new state MO_CALL_PROC -> CONNECT_IND, 1 active transactions new state CONNECT_IND -> ACTIVE, 1 active transactions new state ACTIVE -> DISCONNECT_IND, 1 active transactions new state DISCONNECT_IND -> RELEASE_REQ, 1 active transactions new state RELEASE_REQ -> NULL, 0 active transactions However there's no information regarding which mobile is participating in the transaction. Is there some way to get CDR-like data from OpenBSC? Smth like imsi=123 call_to 35345345 duration 12 imsi=53 sms_from 234234 ... cheers, Max.

4 6

PySIM: SW match failed
by Sipos Csaba 05 Nov '15

05 Nov '15

Dear Holger, Alexander, list In the last couple of weeks we experiencing an issue programmin the SJS1 USIm cards with PySIM. We can read them, but during programming, a lot of us got the following error: root@D6420:~/pysim# root@D6420:~/pysim# ./pySim-read.py -p 0 Reading ... ICCID: 8988211000000073729 IMSI: 901700000007372 SMSP: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ACC: 0004 MSISDN: Not available Done ! root@D6420:~/pysim# ./pySim-prog.py -p 0 -t sysmoUSIM-SJS1 -i 208920000000001 -s 8988211000000073729 -x 208 -y 92 --op=11111111111111111111111111111111 -k 8BAF473F2F8FD09487CCCBD7097C6862 -a 55127679 Insert card now (or CTRL-C to cancel) Generated card parameters : > Name : Magic > SMSP : e1ffffffffffffffffffffffff0581005155f5ffffffffffff000000 > ICCID : 8988211000000073729 > MCC/MNC : 208/92 > IMSI : 208920000000001 > Ki : 8BAF473F2F8FD09487CCCBD7097C6862 > OPC : 8e27b6af0e692e750f32667a3b14605d > ACC : None Programming ... Traceback (most recent call last): File "./pySim-prog.py", line 626, in <module> card.program(cp) File "/root/pysim/pySim/cards.py", line 438, in program r = self._scc.select_file(['3f00']) File "/root/pysim/pySim/commands.py", line 44, in select_file data, sw = self._tp.send_apdu_checksw(self.cla_byte + "a4000002" + i) File "/root/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1])) RuntimeError: SW match failed ! Expected 9000 and got 6a86. root@D6420:~/pysim# Please note that in this particular case I was trying to reprogram an SJS1 card with a card reader (and the exact command) that was worked in the past, and yet its not working now. I don't think this is a PySIM error, but more likely a Pyscard or PCSC-lite problem. I tried several Pyscard versions (1.6.10, 1.6.12, 1.6.16. 1.7.0 and 1.9.0) and the it was all the same. At this point I don't have any more ideas what to try, if anyone would have any suggestions I would apreciate it. I am certainly not alone with this issue, several folks from OpenAIR and OpenLTE are also having the very same problem. Regards, Csaba

2 1

GTP peers
by Neels Hofmeyr 05 Nov '15

05 Nov '15

I've just noticed that my code cannot handle the same GSN's Ctrl address handing out differing User plane addresses to various other GSNs. That's the point of load balancing, after all. So far I've paired up a Ctrl and a User peer 1:1, that won't do. That and the reply-to-same-port will make the structures a bit more complex still: - Each User address has its one managing Ctrl address, but the same Ctrl address may be used for several User addresses. - One address can have several ports, and a sequence number that came from a given port should get its reply with the same sequence number back to that port (discussion pending?). ~Neels

1 0

OAP patch set fixes
by Neels Hofmeyr 05 Nov '15

05 Nov '15

Here is the fixed OAP patch set of those changes not merged yet. For decode_big_endian(), see the new API comment and my mail from thursday night/friday morning. Thanks for the review! ~Neels

2 11

[PATCH] fix some 'else' indenting styles
by Neels Hofmeyr 05 Nov '15

05 Nov '15

--- openbsc/src/gprs/gprs_sgsn.c | 2 +- openbsc/src/libbsc/bsc_vty.c | 3 +-- openbsc/src/libmsc/gsm_04_08.c | 9 +++------ 3 files changed, 5 insertions(+), 9 deletions(-) diff --git a/openbsc/src/gprs/gprs_sgsn.c b/openbsc/src/gprs/gprs_sgsn.c index c4dc9d7..982fb92 100644 --- a/openbsc/src/gprs/gprs_sgsn.c +++ b/openbsc/src/gprs/gprs_sgsn.c @@ -576,7 +576,7 @@ static void drop_one_pdp(struct sgsn_pdp_ctx *pdp) { if (pdp->mm->mm_state == GMM_REGISTERED_NORMAL) gsm48_tx_gsm_deact_pdp_req(pdp, GSM_CAUSE_NET_FAIL); - else { + else { /* FIXME: GPRS paging in case MS is SUSPENDED */ LOGPDPCTXP(LOGL_NOTICE, pdp, "Hard-dropping PDP ctx due to GGSN " "recovery\n"); diff --git a/openbsc/src/libbsc/bsc_vty.c b/openbsc/src/libbsc/bsc_vty.c index 24bae97..8141b21 100644 --- a/openbsc/src/libbsc/bsc_vty.c +++ b/openbsc/src/libbsc/bsc_vty.c @@ -2174,8 +2174,7 @@ DEFUN(cfg_bts_rach_ac_class, cfg_bts_rach_ac_class_cmd, bts->si_common.rach_control.t3 &= ~(0x1 << control_class); else bts->si_common.rach_control.t3 |= (0x1 << control_class); - else - if (allowed) + else if (allowed) bts->si_common.rach_control.t2 &= ~(0x1 << (control_class - 8)); else bts->si_common.rach_control.t2 |= (0x1 << (control_class - 8)); diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c index 7db7586..c8aea06 100644 --- a/openbsc/src/libmsc/gsm_04_08.c +++ b/openbsc/src/libmsc/gsm_04_08.c @@ -806,8 +806,7 @@ int gsm48_tx_mm_info(struct gsm_subscriber_connection *conn) ptr8[7] = bcdify(tzunits); /* Set negative time */ ptr8[7] |= 0x08; - } - else { + } else { tzunits = bts->tz.hr*4; tzunits = tzunits + (bts->tz.mn/15); ptr8[7] = bcdify(tzunits); @@ -815,8 +814,7 @@ int gsm48_tx_mm_info(struct gsm_subscriber_connection *conn) /* Convert DST value */ if (bts->tz.dst >= 0 && bts->tz.dst <= 2) dst = bts->tz.dst; - } - else { + } else { /* Need to get GSM offset and convert into 15 min units */ /* This probably breaks if gmtoff returns a value not evenly divisible by 15? */ local_time = localtime(&cur_t); @@ -831,8 +829,7 @@ int gsm48_tx_mm_info(struct gsm_subscriber_connection *conn) ptr8[7] = bcdify(tzunits); /* Flip it to negative */ ptr8[7] |= 0x08; - } - else + } else ptr8[7] = bcdify(tzunits); /* Does not support DST +2 */ -- 2.1.4

1 0

openbsc_configuration
by Rehab Khan 03 Nov '15

03 Nov '15

I have configured osmocom openbsc.Everything runs fine.But the configurations do not change in real time,everytime the system needs to be restarted as changing lac or cellid in openbsc.cfg file after running the entire setup halts the osmo-nitb log.I want to change cellid,lac and some other configuration parameters in runtime as such in openbts so, can you provide some assistance in this regard? Any help will be greatly appreciated.

1 0

(no subject)
by Rehab Khan 03 Nov '15

03 Nov '15

Hey All, I have configured osmocom openbsc.Everything runs fine.But the configurations do not change in real time,everytime the system needs to be restarted as changing lac or cellid in openbsc.cfg file after running the entire setup halts the osmo-nitb log.I want to change cellid,lac and some other configuration parameters in runtime as such in openbts so, can you provide some assistance in this regard? Any help will be greatly appreciated.

1 0

Improved patches: openggsn cosmetics
by Neels Hofmeyr 02 Nov '15

02 Nov '15

Here is another set of cosmetic improvements for openggsn (branch: neels/refactor). This prints the host address in human readable form and covers two more similar occurences. A new error log fix has been added (see 4/4). A nonstandard curly brace change from the previous patch has been dropped, and replaced by a blank line to increase readability. ~Neels

2 5

[RFC] GTP-U v0/v1 kernel module
by Andreas Schultz 29 Oct '15

29 Oct '15

Hi, Some time ago, Pablo Neira Ayuso wrote a GTP-U kernel module and OpenGGSN support for it. The OpenGGSN side is easily available in the osmocom git [1]. The kernel part is somewhat harder to find, but it's at [2]. It seems that both sides are at 70% completion and only somewhat working. I have played with the kernel module, changed a couple things and would like to get some feedback on my changes. It can be found at: https://github.com/RoadRunnr/osmo-ggsn Things I've changed: * requires kernel from net-next (or 4.3) * convert to use the existing kernel iptunnel infrastructure * fix GTP-u v1 TEI usage (we need one TEI for RX and another one for TX) * use UDP sockets passed from userland for sending (instead of direct push to network interface) * fix resource release on GTP-U socket shutdown * release all resource on module removal The module currently works with a proof-of-concept GGSN/PGW implemented in Erlang (will post once the licensing is sorted). OpenGGSN will need some small changes (will post soon). Andreas [1]: http://git.osmocom.org/openggsn/ [2]: http://git.sysmocom.de/osmo-ggsn

4 5

GTP ports and IP addresses
by Neels Hofmeyr 29 Oct '15

29 Oct '15

Hi all, a remark / question about GTP, in the context of writing code for gtphub... So far I've tried to keep the GTP IP addresses and ports config general -- you never know what weird things one might want to do some day (different IP addresses for User and Control? Nonstandard port numbers?). But now I'm at the point where I've got a Control plane message from a "control peer", and need to figure out the matching peer on the User plane. How do I do that? By IP address, of course. Thus it struck me that GTP *depends* on a setup where the User IP address is identical to the IP of the sender of the Ctrl plane packet. (view with a monospaced font) SGSN GGSN (or gtphub) 1.2.3.4 5.6.7.8 Ctrl: 2123 <-------> 2123 User: 2152 <-------> 2152 So trying to stay general with IP addresses is an exercise in futility, because it plainly doesn't work for GTP: I can't match up a peer's two message planes unless the above standard is given. Thinking of a nonstandard situation: GGSN (or gtphub) SGSN 5.6.7.8 Ctrl: 1.2.3.4:111 <-------> 2123 User: 4.3.2.1:222 X-------> 2152 The GGSN can record that there's a Ctrl peer at 1.2.3.4:111, from the incoming GTP packet's sender address. Say it receives a Create PDP Context Request, in which the nonstandard SGSN sends two TEIs it wants to use, on the Ctrl *and* User plane. Now, the GGSN cannot possibly know that 4.3.2.1 is the User plane peer for which the TEI from the Create PDP Ctx Req should be valid. One may think that the SGSN can just contact the GGSN from 4.3.2.1:222 and send the TEI from the Create PDP, so the GGSN could know that it's the same peer. But in fact a TEI is scoped *within* a comm plane with a peer, meaning that any other peer could choose the exact same TEI at any point, and the means to disambiguate is the peer's IP address. So my wishful thinking to stay general there is thwarted by design. The Ctrl and User IP addresses must be identical. Still, the SGSN's port numbers could theoretically be chosen freely. The GGSN knows the sender of the Ctrl packet(s), and as soon as a User packet comes in from the same IP address, it also knows the User plane port. As long as the IP address is the same and there are no other SGSNs using different ports on the same IP address, the GGSN could figure out both nonstandard Ctrl and User ports like this. BTW, we've also thought about securing the GTP wire towards gtphub with some kind of authentication (future). With identification sent on both planes, the limitations discussed here would be void... So I'll actually keep gtphub's config as general as it is, but will not invest time, neither in implications of choosing nonstandard setups, nor in prohibiting them (yet). The nonstandard ports config capability actually comes in handy for unit testing, where I can place some netcats and a gtphub on arbitrary port numbers on the same IP address. (Since implicit creation of 127.0.0.N interfaces is linux specific, using several local addresses without root privilege is not portable). If you spot any thinkos there, please let me know :) ~Neels

3 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC