OpenBSC June 2009

openbsc@lists.osmocom.org

17 participants
103 discussions

[PATCH 0/3] lchan/location updating request robustnes
by Holger Freyther 05 Jun '09

05 Jun '09

Hey, in patch22 Andreas pointed out that we might have unbalanced ref count in the location updating request path(s) and these patches try to fix some possible reliable issues, handle spoofing to a certain degree and recover from error (abnormal channel close). include/openbsc/signal.h | 10 ++++++++++ src/chan_alloc.c | 4 +++- src/gsm_04_08.c | 32 ++++++++++++++++++++++++-------- 3 files changed, 37 insertions(+), 9 deletions(-)

1 3

AW: WG: patch 12 14, 15, 16
by Andreas.Eversberg 04 Jun '09

04 Jun '09

>> is this correct? as far as i know, the attached subscriber is associated to >> a LAC only. it may silently change the BTS without location update, > >You are right. It is wrong. I assumed that BTS <-> LAC map 1:1 but that is not >the case. Could you prepare a change to gsm_subscriber to store the LAC + CELL >ID and remove the struct gsm_bts pointer or would you be willing to test one? >Maybe even carry out the change in the db.c to store/restore the that >information (e.g. check my "VLR" patches as this is what we are building). i can test this. i will remove bts pointer and only check lac when detaching. when paging, i will loop all bts and add a paging request to all bts with that pointer. if the paging responds, we receive the lchan and then stop paging requests to other bts' (if any). if we receive resonse, we ignore them, if we already received an lchan. (error case when two mobiles share same imsi or other error cases). what about the "VLR" patch? where is it? why do you need a VLR? (HLR??) >For the future we would have something like this: > 1.) Call +123323 > 2.) Find the gsm_subscriber and load it from the db > 3.) Check the VLR where we currently think it is > struct gsm_bts* bts = bts_resolve(subscr->lac, subscr->cell_id); > and then page... > >z. check out the patch 27 (application). there is a loop when start paging. it already loops all bts with the LAC. there is an error in that: the current_bts pointer is changed for every paging request. this would be removed, if the bts pointer is removed. also the stopping of parallel paging requests (same subscriber, different bts) is not realized. if you aggree with that, i will implement it this weekend.

2 2

AW: patch 24: output
by Andreas.Eversberg 04 Jun '09

04 Jun '09

the reason for moving "subscr_get_by_tmsi" behind the "DEBUGPC" function is to finish the debug line (using end-of-line) before calling the "subscr_get_by_tmsi" function. the "subscr_get_by_tmsi" function may also do debug output (currently uses printf). without changing it, the debug gets distorted. -----Ursprüngliche Nachricht----- Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther diff --git a/src/gsm_04_08.c b/src/gsm_04_08.c index d585aae..9a2a00a 100644 --- a/src/gsm_04_08.c +++ b/src/gsm_04_08.c @@ -797,9 +797,9 @@ static int gsm48_rx_mm_serv_req(struct msgb *msg) } mi_to_string(mi_string, sizeof(mi_string), mi, mi_len); - subscr = subscr_get_by_tmsi(mi_string); DEBUGPC(DMM, "serv_type=0x%02x mi_type=0x%02x M(%s)\n", req->cm_service_type, mi_type, mi_string); + subscr = subscr_get_by_tmsi(mi_string); /* FIXME: if we don't know the TMSI, inquire abit IMSI and allocate new TMSI */ if (!subscr) @@ -831,9 +831,11 @@ static int gsm48_rx_mm_imsi_detach_ind(struct msgb *msg) switch (mi_type) { case GSM_MI_TYPE_TMSI: + DEBUGPC(DMM, "\n"); subscr = subscr_get_by_tmsi(mi_string); break; case GSM_MI_TYPE_IMSI: + DEBUGPC(DMM, "\n"); subscr = subscr_get_by_imsi(mi_string); break; case GSM_MI_TYPE_IMEI:

2 1

Some very handy telecom call flow pdfs
by Nordin 04 Jun '09

04 Jun '09

I found some good call-flow schematics according to GSM protocol with some explanation included. Check out this link: http://www.eventhelix.com/RealtimeMantra/Telecom/ It has some valuable and clear information how parts of GSM work. I hope you like it, at least I do :)

1 0

Re: Possible to control the radio strength of a nanoBTS?
by Dieter Spaar 04 Jun '09

04 Jun '09

Hello Harald, On Wed, 3 Jun 2009 23:24:50 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > The BS-11 has 3W max output. I think we have 2 Watt maximum, 3 Watt is the maximum for the 1800/1900 variant of the BS-11. > That's quite obvious if you understand the details of the cell selection > algorithm. If you've been registered to an actual cell of the operator > before, then that ARFCN/LAC is stored on the SIM card even when you shut > off the phone. Let me add a few more detail (I sent this to the list a while ago). There are two EFs (Elementary Files) on the SIM which contain this information: - EF_BCCH contains the cell allocation information from "SYSTEM INFORMATION 2". - EF_LOCI contains the TMSI, Location Update Timer, LAI and the status of the location update. If those EFs are set to the correct values used by the test cell, the phone will immediately look for the test cell when powered on and also consider to be "registered" if no "IMSI Attach" is required. > So yes, typically the translation of mcc/mnc happens in a table on the SIM > card, and if that fails in a table that is included at compile time into the > GSM firmware of the handset. It seems that the mapping of MCC/MNC to names on the SIM was introduced with GSM 31.102 (USIM for UMTS), GSM 11.11 did not have it. So it depends on the SIM if it has this mapping. I looked at some phone firmware, in this special case the mapping is done by looking at the SIM first (if it is an USIM), than at an optional table in the phone filesystem and finally at the table in the firmware. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

AW: How to sync to HFC-S s0 clock?
by Andreas.Eversberg 03 Jun '09

03 Jun '09

>Hello, > > I want to sync the e1 card with a HFC-s card, which is attached to my > ISDN line. > How do I have to interconnect the two cards? > > Best regards > Björn hi, you need to find pin 118 of the E1 controller on the pcm bus (connector). this signal provides or receives the clock (4096khz) also find pin 119. it provides or receives frame sync (8khz). connect them to the clock pin 54 and frame sync pin 55 of the HFC-S PCI ISDN controller. maybe choose a resistor of 1kohm to protect cards, if both card send output signals. load mISDN driver module as "clock slave": modprobe hfcmulti port=0x200 debug=0x40000 watch the kernel messages for clock selection process. without clock connected, the hfcmulti module will fail. test that to see if the card trys to receive external clock. before you can use the clock from HFC-S, you must load hfcpci module. note that your E1 card is now card number 1 and not 0. then you need to connect the HFC-S card to you isdn line. your card must activate interface. therefor a telephony application is required. but before, you need to see if your E1 card syncs to your HFC-S card. if your clock sync works, i will write a small application to set your isdn card into PTP mode (for durable link activation). regards, andreas

1 0

AW: patch 12 14, 15, 16
by Andreas.Eversberg 03 Jun '09

03 Jun '09

this call makes no sense. maybe i forgot it during testing and debugging. -----Ursprüngliche Nachricht----- Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther >And I was too fast. I have one more question. Could you please explain the >extra call to: > subscr_update(lchan->subscr, bts, GSM_SUBSCRIBER_UPDATE_ATTACHED); i don't know why, but i will check that tonight too.

1 0

AW: patch 22: lchan_use
by Andreas.Eversberg 03 Jun '09

03 Jun '09

lchan_free() is called when RSL released the logical channel. all ressources that 'uses' the channel, must be released. i aggree with you, that it makes no sense to consider everything that 'uses' the logical channel. to fix this, i have an idea and need some response before implementing. problems: - what instance uses the logical channel? - how do we release them, if the channel is closed? - how do we change the channel (handover/SDCCH->TCH ...)? (is this required?) one possible solution: every logical channel gets a list of 'users'. these users have nodes in this list. users can be i.e.: an active call, a call on hold, an SMS transaction, a location update.... each node has a pointer to the lchan. the 'user' can access the logical channel via node. each node has a destructor function pointer. during lchan_free(), the destructor of each node is called. the 'user' will remove the node. with that, the chan_alloc does not need to know how to free 'users' if we want to change the logical channel, we just unlink the nodes from the old channel and attach them to the new channel. each node has: - "struct llist_head" to link to previous and next node - pointer to the logical channel (lchan) - pointer to the destructor for the node owner. (the 'user') - void pointer to the owner's private structure. user 'uses' a channel: - it calls the lchan_use() function with the logical channel, the destructor, and private structure pointer - the node is created and linked to the logical channel - the pointers within that node are set user 'drops' a channel: - it calls the lchan_put() function with the pointer to the node. - the node is unlinked from lchan and destroyed lchan closes: - for each node of a logical channel, the destructor is created. - within this destructor, the 'user' must remove all relations to that channel, remove the node, and set the node pointer to NULL. user can refers to it's channel: struct gsm_lchan *lchan = private->lchan_node->lchan; what do you think? -----Ursprüngliche Nachricht----- Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther Gesendet: Dienstag, 2. Juni 2009 03:02 An: openbsc(a)lists.gnumonks.org Betreff: Re: patch 22: lchan_use I don't like this part. First of all when making release_loc_update_req "public" it should be properly prefixed, but I don't think chan_alloc.c should know/care about gsm_04_08.c at all. Also tying the timeout of the Location Update with the autorelease of the channel does not seem appropriate. I would very much prefer if this logic can stay within gsm_04_08.c and we fix the usage count issue there. For me it looks like: - We get a reference when creating the loc_update_request - We start a timer - We put the reference when destroying the loc update request... - So we might just remove the extra put/use for the waiting for IMSI/IMEI and fix the "leak" like this? what do you think? z.

2 1

How to sync to HFC-S s0 clock?
by Bjoern Heller 02 Jun '09

02 Jun '09

Hello, I want to sync the e1 card with a HFC-s card, which is attached to my ISDN line. How do I have to interconnect the two cards? Best regards Björn - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Björn Heller Jabber: tec(a)jabber.hellercom.de

1 0

AW: patch: 8_paging
by Andreas.Eversberg 02 Jun '09

02 Jun '09

correction: patch 12 (not 13) uses dynamic transactions. -----Ursprüngliche Nachricht----- Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Andreas.Eversberg Gesendet: Samstag, 23. Mai 2009 10:21 An: Harald Welte Cc: openbsc(a)lists.gnumonks.org Betreff: AW: patch: 8_paging here is the problem: we don't know about the called bts, if - the subscriber detaches after paging was started and the current_bts pointer inside subscriber is NULL. - the lchan is not set because paging expires. we can use the network pointer instead of the bts pointer for paging callback function. the gsm_network is required when paging result is received. all transactions (call instances) are linked in a list in gsm_network. (see patch 13) even if paging expires, the transactions in this list with the same subscriber must be released. (MO out of order) but it is more complex: the subscriber will not be NULL, because it is "used" by the transactions. the use-counter of subscriber is increased for every transaction created and decreased on release of that transaction. if there is a call process for the paged subscriber, the subscr is set when paging response is received. we need at least a pointer to the network to access the transactions. we can keep paging callback function without bts (or network) pointer, but then we need a network pointer in gsm_subscriber to process the network's paging result. -----Ursprüngliche Nachricht----- Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Andreas.Eversberg Gesendet: Samstag, 23. Mai 2009 09:47 An: Harald Welte Cc: openbsc(a)lists.gnumonks.org Betreff: AW: patch: 8_paging i use the calling party's BTS, because the subscriber database does not contain the current BTS number of the subscriber last seen. (or detached) i agree that the subscriber gives us information about the paged bts and we can resolve the gsm_network from that also. -----Ursprüngliche Nachricht----- Von: Harald Welte [mailto:laforge@gnumonks.org] Gesendet: Samstag, 23. Mai 2009 08:30 An: Andreas.Eversberg Cc: openbsc(a)lists.gnumonks.org Betreff: Re: patch: 8_paging Hi again, On Sat, May 23, 2009 at 02:23:11PM +0800, Harald Welte wrote: > On Thu, May 21, 2009 at 02:27:36PM +0200, Andreas.Eversberg wrote: > > Paging refers to a BTS. To page a mobile phone, the current location > > is required. If paging succeeds or expires, the BTS structure is > > also given to the callback function (cbfn). > > > > Because paging refers to a BTS, the cbfn (callback function) must > > include a pointer to bts. > > The paging response includes a lchan pointer, which can be resolved to > the physical channel / timeslot and to the trx and finally to the BTS. > Is this not sufficient? Ah, ok, in the case we do not successfully allocate a lchan, then that's obviously NULL. Still, when you call paging_request() you actually pass on a number of parameters, including: 1) the BTS on which you want to page (whcih, indeed, is currently the BTS of the calling party rather than the called party). So this parameter is likely to get removed soon. 2) The subscriber that was called. This should be used by paging_request() to resolve the BTS that this subscriber was last seen/registered to. 3) a reference to the call, which is treated as an opaque pointer that is passed back as a reference when calling the call-back function. So if the bts of the calling or called party needs to be known, it should probably be referenced from that data structure. Or am I missing something? -- - 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)

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC June 2009