June 2009 - OpenBSC - lists.osmocom.org

WG: fixes for mncc-harald branch

by Andreas.Eversberg

> yes, can you please provide a patch that adds it to gsm_mncc, rather than gsm_mncc_number? here it is...

15 years

1
0
0 0

Re: Possible to control the radio strength of a nanoBTS?

by Dieter Spaar

Hello Nordin, On Mon, 15 Jun 2009 12:49:48 +0200, "Nordin" <bouchtaoui(a)gmail.com> wrote: > > I don't know if that kind of information is provided in the Broadcast > channel (BCCH). I'll check it out. GPRS is indicated through the SYSTEM INFORMATION on the BCCH. bsc_hack doese not (yet) indicate it. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

15 years

1
0
0 0

Possible to control the radio strength of a nanoBTS?

by Nordin

Hello guys, While I'm still busy with understanding the OpenBSC sourcecodes and GSM protocols, I wonder if it's possible to control the nanoBTS's transmissionpower. If some additional code is needed, I'd like to give a try with some hints or directions to look at. Thank you.

15 years

6
16
0 0

fixes for mncc-harald branch

by Andreas.Eversberg

hi, finally i ported linux-call-router to new mncc api. this is quite easy, because only data types changed. i don't care about change of mncc api from time to time, because openbsc does not have that much applications yet. i think that trau frames don't have anything todo with mncc api and should be use own interface in the future (hopefully with ipaccess). i tested openbsc with linux-call-router. everything worked fine after adding some fixes. now, the mncc-harald includes every work i made, except the installation of library and include files. fix 1: i use this workarround to allow my mobile to get a traffic channel. the mobile reqests a sdcch channel, but currently openbsc is not able to switch channel. (this should be possible in the future for handover.) also it checks if there is actually a traffic channel currently in use, when making a call. fix 2: not actually a fix: adding imsi to gsm_mncc_number allows to notify application about calling/connected imsi. also it is possible to dial a subscriber with no extension assigned, just by using imsi. maybe it is wiser to put imsi string into gsm_mncc, because it is only used only once in a message. fix 3: while detaching, we don't hold a ressource (we don't call lchan_use), so we don't need to "lchan_put". fix 4: the given cause value and location parameters are used in mncc_release_ind function, rather than hardcoded. the plain cause numbers are replaced by the definitions from header file. additionally i uploaded a new inofficial version of openbsc and linux-call-router at www.linux-call-router.de. andreas

15 years

2
1
0 0

AW: Open bsc + trixbox

by Andreas.Eversberg

hi fabian, trixbox uses asterisk. asterisk is supported by linux-call-router (integrated channel driver). linux-call-router is supports a modified version of openbsc. (see last post) so you can use trixbox with openbsc. regards, andreas ________________________________ Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von FABIAN SMITH Gesendet: Samstag, 13. Juni 2009 19:24 An: openbsc(a)lists.gnumonks.org Betreff: Open bsc + trixbox Will openbsc work with trixbox or other pbx's ?

15 years

1
0
0 0

Open bsc + trixbox

by FABIAN SMITH

Will openbsc work with trixbox or other pbx's ?

15 years

2
1
0 0

Ideas regarding BSC/MSC split up

by Holger Freyther

Hey Guys, some of us started to look into the various 08.0x specs and even SCCP (not me yet) and I think our common goal is to go towards a more "normal" BSS/MSC and in the same way keeping the spirit of bsc_hack to allow to run a whole network with one executable. A rough split up of BSC vs. MSC would be: BSC has the secret of: - init hardware, bcch, oml/rsl setup - paging - channel allocation/management MSC has most of the policies: - HLR/VLR and who to allow into the network - call handling etc... To keep this short ('m quite tired at the moment) my goal/approach is to create a libmsc.a and move the db.c, gsm_subscriber.c and on the way to move policy out of gsm_04_08.c to the libmsc.a. bsc and msc would communicate with an API that resembles the DTAP, BSSMAP interface. The MNCC use case Andreas and Harald are working on should remain supported, same as the bsc_hack.c. The goal of having an interface like DTAP and BSSMAP is to allow implementing the A-Interface. I will start this work in a branch called holger/msc and will seek for feedback once I have something that is worthwhile to share. good night z.

15 years

2
2
0 0

patch 36: application interface

by Andreas.Eversberg

<<36_application.patch>> again the application patch based on the current OpenBSC source and the other patches i posted. i cannot split this patch, because all the parts depend on each other. the only thing i can do, i can splitt them into their functional parts. the libbsc will not work without applying all parts then.

15 years

2
1
0 0

Question: Allow Mobile Attach

by Eric Cathelinaud

Hi! I am trying to understand the code to make several tests. If I understand, the default setting is to refuse any phone trying to connect the network? I would like to change this in the code to accept everyone. I saw in bsc_hack the Control Channel Description which seems to deal with this. Am I wrong? static u_int8_t si3[] = { /* header */0x49, 0x06, 0x1B, /* cell */0x00, 0x01, /* lai */0x00, 0xF1, 0x10, 0x00, 0x01, /* desc */0x01, 0x03, 0x00, //Control Channel Description /* option*/0x28, /* selection*/0x62, 0x00, /* rach */0xD5, 0x00, 0x00, /* reset*/0x80, 0x00, 0x00, 0x2B }; Which value shall I put to accept everyone? Thanks! Best regards Eric Cathelinaud

15 years

3
3
0 0

patch 34: paging lac

by Andreas.Eversberg

this patch will use the gsm_bts_by_lac() function to start paging of all bts' with the same lac. when paging is successfull, the paging_request_stop() function is called with the current lchan, so the callback function will be called. for all other bts', the paging_request_stop() function is called without lchan, so the paging is stopped, but the callback function is not called. this ensures that only one paging result is received when paging multiple BTS.

15 years

4
6
0 0

patch 28: wrieshark pcap logging

by Andreas.Eversberg

This patch fixes the PCAP logging. If frames are received from E1 interface, an 8 byte mISDN header (MISDN_HEADER_LEN) is in front of the RSL packet. When frames are transmitted to the E1 interface, the pcap_write_packet function will get a message buffer without the mISDN header in front of the RSL packet. The pcap file was tested and the output is correct.

15 years

2
2
0 0

AW: layer 1 debugging

by Andreas.Eversberg

BN1E1 seems to have different layouts over the time. i always jumper the cards to TE, so i use a crosslink cable for NT to TE. ________________________________ Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Eric Cathelinaud Gesendet: Mittwoch, 10. Juni 2009 10:41 An: Harald Welte Cc: openbsc(a)lists.gnumonks.org Betreff: Re: layer 1 debugging I tried to short the left and to invert the twinax plug (thus pluging them as in the wiki) and it works too. Then it could be a mistake in the jumper plan of BN1E1 cause they say that the left is "TE" and not "NT". Anyone else dealing with a BN1E1 card to confirm? Eric Cathelinaud 2009/6/9, Eric Cathelinaud <e.cathelinaud(a)googlemail.com>: 2009/6/9 Harald Welte <laforge(a)gnumonks.org> Hi Eric, On Tue, Jun 09, 2009 at 12:56:25PM +0200, Eric Cathelinaud wrote: > Thanks a lot for this layer 1 debugging tutorial. It helped me a lot since i > was thinking I did something wrong with mISDN. I checked the step 3 and find > out that my ISDN card was working fine. > Then I tried to invert my twinax plugs and it worked. I think there is a > mistake in the wiki. > It's written in http://bs11-abis.gnumonks.org/trac/wiki/BS11_Configuration : > - left Y01 PCM in (from BSC): RJ45 pin 4,5 > - Y02 PCM out (to BSC): RJ45 pin 1,2 > > but for me it works with : > Y01 PCM : RJ45 pin 1,2 (orange / white orange for a straight cable) > Y02 PCM : RJ45 pin 4,5 (blue / white blue for a straight cable) I think that depends on the jumper configuration of your E1 card. Did you really put the jumpers in "NT Mode" configuration? Yes I put NT Mode following the jumper plan (short pins on the right). My card is a Beronet BN1E1. I will try to short pins on the left and let you know if working as in wiki. > I can now see the network on my mobile phone thanks a lot. great! -- - 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)

15 years

1
0
0 0

layer 1 debugging

by Andreas.Eversberg

hi, i added layer 1 state change (and initial state) reporting to mISDN kernel driver. this is usefull to resolve E1 connection problem. 1. download the latest mISDN driver from www.mISDN.org using git: git-clone git://git.misdn.org/git/mISDN.git/ change to socket branch: cd mISDN ./checkout-branch.sh socket compile and install as usual make force # remove kernel mISDN includes make make install load mISDN as usual. 2. run bsc_hack using debug option: --debug=DMI Allowing everyone? DB: Database initialized. DB: Database prepared. 1 devices found id: 0 Dprotocols: 00000018 Bprotocols: 0000006e protocol: 4 nrbchan: 30 name: hfc-e1.1 activate bchan activate bchan Mon Jun 1 18:51:43 2009 <1000> input/misdn.c:124 alen =6, dev(9) channel(0) sapi(63) tei(127) Mon Jun 1 18:51:43 2009 <1000> input/misdn.c:127 <= len = 12, prim(0x8) id(0x7f3f): DL_INFORMATION_IND Mon Jun 1 18:51:43 2009 <1000> input/misdn.c:134 DL_INFORMATION_IND: use channel(0) sapi(63) tei(127) for now mISDN message for unknown sign_link Mon Jun 1 18:51:43 2009 <1000> input/misdn.c:124 alen =6, dev(9) channel(0) sapi(63) tei(127) Mon Jun 1 18:51:43 2009 <1000> input/misdn.c:127 <= len = 8, prim(0x102) id(0x7f3f): PH_ACTIVATE_IND Mon Jun 1 18:51:43 2009 <1000> input/misdn.c:161 PH_ACTIVATE_IND: channel(0) sapi(63) tei(127) in this case we see "PH_ACTIVATE_IND", because BS11 is connected and sending a signal. 3. check your card: (most common type) close to the plug there are two jumpers. the are used to select between 1,2,4,5 and 1,2,3,6 pin selection. be sure they are to the left for standard 1,2,4,5 pinning. take an rj45 plug and connect pin 1 with 4 and 2 with 5. start bsc_hack and plug it into your card. you should see "PH_ACTIVATE_IND" when you plug it. your card is working. if nothing works, check your termination switches. refer to the card's manual. the must be set to 120 ohms, if the termination jumpers on your BS11 are pulled out. without termination, the card might not work. 4. check your BS11 remove the plug and connect the cable to the BS11: one pair (pin 1 and 2) to Y01 and one pair (pin 4 and 5) to Y02. after bootup ob BS11 you will see "PH_ACTIVATE_IND" if you connect both paris in the correct order. you must connect both pairs because BS11 will only send a signal, if it receives a signal. pin 1 can be wapped with pin 2, pin 4 with pin 5 also. the E1 interface does not care about that. 5. check data link connection: you have already received the management process via "DL_INFORMATION_IND" on sapi 63 tei 127. if BS11 software load is running, you will receive additional data links from BS11: - sapi 62 tei 25 - sapi 0 tei 25 - sapi 0 tei 1 these are three datalinks. each one is created and sends us "DL_INFORMATION_IND" on creation, "DL_ESTABLISH_IND" on activation and "DL_DATA_IND" when receiving data on that link. hope that helps. andreas

15 years

3
5
0 0

patch 35: information element transcoding

by Andreas.Eversberg

this patch will do the transcoding of information elements. this patch adds new functions to be used for the application interface patch, and is basis for the application patch (currently patch 36). when applying the patch, the compiler gives warnings, because the "static" functions will not be used. (yet)

15 years

2
1
0 0

patch 33: db fix

by Andreas.Eversberg

during attachment, the "tmsi" field of the subscriber may be an empty string, so the string must be quoted in the sql request, or the sql request fails due to incorrect syntax. also i added "extension" field to debug output.

15 years

1
0
0 0

inofficioal test

by Andreas.Eversberg

hi, i uploaded an inofficial test version of openbsc with all my patches applied. (not the latest, but working well). you will find it here: http://www.linux-call-router.de/download/lcr-1.5/ <http://www.linux-call-router.de/download/lcr-1.5/> all ressources get freed, no hanging logical channels or subscriber instances in any test case i found. also linux-call-router, an alternative application to bsc_hack, the gsm speech codec and mISDN kernel drivers are available there. a howto is in progress. regards, andreas

15 years

2
1
0 0

patch 31: fixed option for db selection

by Andreas.Eversberg

the database select option "-l" did not work: - c = getopt_long(argc, argv, "hc:n:d:sar:p:f:t:C:RL:", + c = getopt_long(argc, argv, "hc:n:d:sar:p:f:t:C:RL:l:",

15 years

1
0
0 0

patch 37: assigning traffic channel

by Andreas.Eversberg

hi, i have a phone that requests a SDCCH channel after it is paged. (even if paging request required a TCH Full channel.) in this case, i assign a GSM_LCHAN_TCF_F channel except for location update. (see patch) in the second part of this patch, i check if the current channel is a traffic channel. if not, we can't use it on calls BSS->MS. this happens if a call is received after location update, but before the channel is released. this second part depends on the application patch (36). andreas

15 years

2
1
0 0

patch: 30

by Andreas.Eversberg

my subsequent patches are dependant on the patches by holger from may 5th. for personal testing and for information, i packed them together. i tested them and they work well. Mit freundlichen Grüßen, .-. /'v'\ (/ \) ------------------------------------------------------------------"-"- |_| i.A. Andreas Eversberg Administrator Betrieb und Entstörung Versatel Nord GmbH Nordstr. 2 D-24937 Flensburg Fon: +49-461-9099749 | Fax: +49-461-909960749 andreas.eversberg@versatel.de@versatel.de | www.versatel.de Sitz der Gesellschaft: Flensburg, Registergericht: Flensburg, HRB 3395 FL Geschäftsführer: Soeren Wendler, Dr. Hai Cheng, Dr. Max Padberg, Peter Schindler, Joachim Bellinghoven

15 years

2
1
0 0

patch 32: subscr_update() missing.

by Andreas.Eversberg

If location update is requested, but subscriber is not yet authorised within mm_rx_loc_upd_req() function, the subscr_update() is not called, because subscriber information is not complete. During mm_rx_id_resp() the subscriber informations is may be complete, so authorize subscriber succeeds and database must be updated.

15 years

2
1
0 0

Re: Some notes about BS-11 clock calibration

by Dieter Spaar

Hello Harald, On Mon, 8 Jun 2009 16:28:54 +0800, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > The various clock related issues that people have been describing already gave > me a lot of headache. With the method you described in your mail we now have a > documented way how to make sure the BS-11 runs on the 'right' frequency. Thank you, I hope that together with the description and tool from Andreas it will help to solve any issues related to the BS-11 clock. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

15 years

1
0
0 0

AW: isdnsync

by Andreas.Eversberg

the "g" is missing. maybe i lost the "g" while copying. i prefer OpenBSC svn because the tool is currently usefull for OpenBSC only. -----Ursprüngliche Nachricht----- Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther Gesendet: Montag, 8. Juni 2009 11:56 An: openbsc(a)lists.gnumonks.org Betreff: Re: isdnsync Cool, two small questions. Do you mind if I add a "g" to your name in the isdnsync.c, or did I always misspell your name? The second one is if the OpenBSC svn is to be preferred over misdn-utils? z.

15 years

2
1
0 0

Re: Trying to understanding the source

by Nordin

Hi guys, I'm a bit ashamed to ask, but I'll ask anyway, could someone help me explaining the OpenBSC source? make_sock(): I didn't know it's possible to call select() on a read signal to finally call the accept() for the socket_fd. Logically seen, socket_fd receives something (in this case a new connection), so it works. I just thought select() is only used for reading/writing data (or an except) on file descriptors. Why is OpenBSC written to work synchronously and not multihtreaded? If somewhere in the chain hangs (by a bug), telnet for example won't respond, right? What is the idea behind this concept? Is it a popular concept in the Linux world (so I can be familiar with)? Which other functions does timer.c has besides returning a timevalue for the select() call (nearest_timer) time-out. I mean what more other purposes has timer.c Cause I don't really understand why timer_values also be put in a doubly linked list... That's all for now, I might ask some more questions, but after some studying :s Thank you. P.S: I do have experience in C/C++ programming....in Bill Gates environment. I know.....I'm sorry.

15 years

3
3
0 0

(no subject)

by Andreas.Eversberg

hi, this small tool is used to enable layer 1 and 2 on a given isdn card. the card can be used to retrieve clock signal from a network. layer 2 (PTP) is required to keep layer 1 without interruption. this tool works on e1 and s0 cards. to use the clock signal with other cards, interconnection with a clock-slave-card is required. this tool is GPL v2. the import to the subversion server on bs11-abis.gnumonks.org is welcome. a documentation with card interconnection howto does not exist, but if someone really successfully connects two cards (HFC-S PCI and HFC-E1), we can write one from these experiences. regards, andreas

15 years

2
1
0 0

Some notes about BS-11 clock calibration

by Dieter Spaar

Hello, I did a few tests with the BS-11 clock. I wanted to find out how accurate the clock of the BS-11 is and how the calibration value influences the clock. This is only about one BS-11, but I guess the others are similar. To control the BS-11 clock I used a slightly modified HFC-E1 card, instead of the 32.768 MHz oscillator of the card an external signal from an accurate and stable clock source is used. The BS-11 "PLL Mode" is set to "Locked" so that it locks to the E1 clock. I am observing the PLL "Work Value" which is the actual value used by the PLL. I also measured the RF frequency of the BS-11. HFC-E1 clock is 32.768 MHz: PLL Work Value is 1024 HFC-E1 clock is 32.768 MHz + 0.1 ppm: PLL Work Value is 941 HFC-E1 clock is 32.768 MHz - 0.1 ppm: PLL Work Value is 1116 So a lower PLL calibration value means a higher frequency. Another observation is that the actual RF frequency is following the E1 clock slowly. For example if the E1 clock is changed by 0.1 ppm, the RF frequency is slowly changing until after several minutes it has also changed by 0.1 ppm. The PLL "Working Value" is following even slower, it takes nearly an hour until is has settled to a stable value. The clock of the BS-11 is very stable, if set to "Stand Alone" the RF frequency is not changing very much, its much less than the required 0.05 ppm from the GSM specification for a BTS. Another interesting thing is that the factory PLL calibration of this BS-11 is 1016, very close to 1024 of the measured value. What does that all mean ? If you want to calibrate the clock of your BS-11 by using a HFC-E1 card which is synchronized from a stable and accurate clock (Andreas explained how this can be done with a second ISDN card) I would recommend to do the following: - let the BS-11 warm up for at least one hour - set the "PLL Mode" to "Locked" with bs11_config - start bsc_hack and let it run for an hour so that the PLL can adjust to the E1 clock and the PLL "Work Value" settles (you can use bs11_config to watch the value). - set the "PLL Mode" to "Stand Alone" with bs11_config, this makes sure that the PLL "Work Value" will no longer change and is used next time, even if the HFC-E1 clock is no longer synchronized. The BS-11 oscillator should be stable enough so that there is no need for continuous synchronisation with an external reference. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

15 years

2
1
0 0

[PATCH 0/3] Updated Channel Allocation Code

by Holger Freyther

Hey, I posted some of these patches some time ago and started to rebase them now. The main idea is to make the "paging" layer more internal and only request to open a channel (of a specific type) to a certain subscriber. The internal handling would find the right bts in the lac ("new" requirement and not yet implemented), will make sure that we assign as many as possible channels to the subscriber but will not lose any request (act as a queue). I would like to merge the first two patches as I think they are moving in the right direction and are unlikely to break anything and plan to test the third patch later this week (if I get access to a BTS). So if you will see a regression in call handling, shout at me.. z. include/openbsc/gsm_data.h | 2 include/openbsc/gsm_subscriber.h | 9 ++ src/bsc_hack.c | 1 src/gsm_04_08.c | 6 - src/gsm_subscriber.c | 139 ++++++++++++++++++++++++++++++++++++++- 5 files changed, 153 insertions(+), 4 deletions(-)

15 years

1
3
0 0

Re: WG: patch 12 14, 15, 16

by Dieter Spaar

Hello Harald, On Sat, 6 Jun 2009 10:03:38 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > In other words: IMSI ATTACH/DETACH is only used in addition to regular Location > Update, and it is used in situations where a MS on a network with ATT=0 would > not perform any signalling with the network at all. I have read at some places that the idea of IMSI ATTACH/DETACH is to save resources of the network, if its is know that an MS is off (IMSI DETACH was sent) there is no need to allocate resources for paging the MS. IMSI ATTACH is the reverse, it tells the network that the phone is back again. Its up to the operator to use this feature. I am not sure if this is the real motivation, but it makes sense for me. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

15 years

2
1
0 0

WG: patch 12 14, 15, 16

by Andreas.Eversberg

-----Ursprüngliche Nachricht----- Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther >I'm not sure what happens to IMSI ATTACHED/DETACHED when doing handover, so >far the detach path was written in a way that even a sequence like: > new BTS ATTACHED > old BTS DETACHED hi holger, here is what happens: BTS(new LAC) ATTACH -> DB = new LAC BTS(old LAC) DETACH -> DB = 0 the mobile attaches to the new LAC, so the database stores the new LAC number. next, the mobile detaches from the old LAC and the database stores 0 for 'not attached'. the database now holds a wrong value. to solve this, we may only allow detach, if the mobile is not already attached to a different location area: if (DB == old LAC) then DB = 0 else ignore! so the mobile can only detach from a BTS with the location it is currently attached. i checked the code yesterday. i saw that the subscriber is associated to a LAC and a bts when attaching. when detaching, the association to the bts is removed, if not already attached to a different one. 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, if the MCC/MNC/LAC is equal on this BTS. when we page a mobile, we must do it on all BTS of that location area, as far as i know. (see patch 27) if the mobile requests a channel, it chooses one of the BTS. i think we must remove the "current_bts" pointer from the subscriber structure. andreas

15 years

3
5
0 0

AW: [PATCH 3/3] lchan: Handle the abnormal case of channel getting closed

by Andreas.Eversberg

ok, i understand now. the location update is a subinstance of lchan, so you "signal" an error to gsm_04_08.c to release all instances related to lchan. i will test that and modify the patch 27 (application) this weekend, so the signal handler also releases the transactions of that lchan ("transactions" will replace the "call" process). i must upgrade patch 27, because it depends on earlier patches. -----Ursprüngliche Nachricht----- Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther Gesendet: Freitag, 5. Juni 2009 04:19 An: openbsc(a)lists.gnumonks.org Betreff: [PATCH 3/3] lchan: Handle the abnormal case of channel getting closed The abnormal case is that lchan_free ist getting called due a RSL_MT_CHAN_REL_ACK in the RSL but the refcount of this channel is not zero. This means that some "logical operation" is still going on that needs to be cancelled. Instead of always queuing up all operations in the struct lchan use the signal framework to inform higher layers about this abnormal case. In gsm_04_08.c a signal handler is installed and in the abnormal case the location updating request operation is freed. --- include/openbsc/signal.h | 10 ++++++++++ src/chan_alloc.c | 4 +++- src/gsm_04_08.c | 18 ++++++++++++++++++ 3 files changed, 31 insertions(+), 1 deletions(-) diff --git a/include/openbsc/signal.h b/include/openbsc/signal.h index c2cf46a..ca16296 100644 --- a/include/openbsc/signal.h +++ b/include/openbsc/signal.h @@ -37,6 +37,7 @@ enum signal_subsystems { SS_SMS, SS_ABISIP, SS_NM, + SS_LCHAN, }; /* SS_PAGING signals */ @@ -55,6 +56,15 @@ enum signal_nm { S_NM_FAIL_REP, /* GSM 12.21 failure event report */ }; +/* SS_LCHAN signals */ +enum signal_lchan { + /* + * The lchan got freed with refcount != 0 and error + * recovery needs to happen right now. + */ + S_LCHAN_UNEXPECTED_RELEASE, +}; + typedef int signal_cbfn(unsigned int subsys, unsigned int signal, void *handler_data, void *signal_data); diff --git a/src/chan_alloc.c b/src/chan_alloc.c index fa07273..77a4f57 100644 --- a/src/chan_alloc.c +++ b/src/chan_alloc.c @@ -31,6 +31,7 @@ #include <openbsc/abis_nm.h> #include <openbsc/abis_rsl.h> #include <openbsc/debug.h> +#include <openbsc/signal.h> static void auto_release_channel(void *_lchan); @@ -193,8 +194,9 @@ void lchan_free(struct gsm_lchan *lchan) lchan->subscr = 0; } - /* We might kill an active channel... FIXME: call cancellations */ + /* We might kill an active channel... */ if (lchan->use_count != 0) { + dispatch_signal(SS_LCHAN, S_LCHAN_UNEXPECTED_RELEASE, lchan); lchan->use_count = 0; } diff --git a/src/gsm_04_08.c b/src/gsm_04_08.c index 18371b5..3dfa780 100644 --- a/src/gsm_04_08.c +++ b/src/gsm_04_08.c @@ -182,6 +182,24 @@ static void allocate_loc_updating_req(struct gsm_lchan *lchan) memset(lchan->loc_operation, 0, sizeof(*lchan->loc_operation)); } +static int gsm0408_handle_lchan_signal(unsigned int subsys, unsigned int signal, + void *handler_data, void *signal_data) +{ + if (subsys != SS_LCHAN || signal != S_LCHAN_UNEXPECTED_RELEASE) + return 0; + + /* give up on the loc_operation in case of error */ + struct gsm_lchan *lchan = (struct gsm_lchan *)handler_data; + release_loc_updating_req(lchan); + + return 0; +} + +static __attribute__((constructor)) void on_load_0408(void) +{ + register_signal_handler(SS_LCHAN, gsm0408_handle_lchan_signal, NULL); +} + static void to_bcd(u_int8_t *bcd, u_int16_t val) { bcd[2] = val % 10; -- 1.6.3.1

15 years

1
0
0 0

AW: patch 24: output

by Andreas.Eversberg

the two "empty" DEBUGPC do terminate the line ("\n"). never mind, if i find some more distorted debug output during test in the future, i will post them here. -----Ursprüngliche Nachricht----- Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther Gesendet: Donnerstag, 4. Juni 2009 16:00 An: openbsc(a)lists.gnumonks.org Betreff: Re: patch 24: output On Wednesday 03 June 2009 09:41:13 Andreas.Eversberg wrote: > 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. Applied, I assume you agree that omitting the other two "empty" DEBUGPC is good enough as well?

15 years

1
0
0 0

[PATCH 0/3] lchan/location updating request robustnes

by Holger Freyther

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(-)

15 years

1
3
0 0

AW: WG: patch 12 14, 15, 16

by Andreas.Eversberg

>> 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.

15 years

2
2
0 0

AW: patch 24: output

by Andreas.Eversberg

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:

15 years

2
1
0 0

Some very handy telecom call flow pdfs

by Nordin

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 :)

15 years

1
0
0 0

Re: Possible to control the radio strength of a nanoBTS?

by Dieter Spaar

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

15 years

1
0
0 0

AW: How to sync to HFC-S s0 clock?

by Andreas.Eversberg

>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

15 years

1
0
0 0

AW: patch 12 14, 15, 16

by Andreas.Eversberg

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.

15 years

1
0
0 0

AW: patch 22: lchan_use

by Andreas.Eversberg

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.

15 years

2
1
0 0

How to sync to HFC-S s0 clock?

by Bjoern Heller

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

15 years

1
0
0 0

AW: patch: 8_paging

by Andreas.Eversberg

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)

15 years

2
1
0 0

AW: patch 20: autogen

by Andreas.Eversberg

i don't know what autoreconf is. root@fuckup:~/gsm/openbsc.orig# autoreconf configure.in: required file `./install-sh' not found configure.in: required file `./mkinstalldirs' not found configure.in: required file `./missing' not found src/Makefile.am: required file `./depcomp' not found autoreconf: automake failed with exit status: 1 root@fuckup:~/gsm/openbsc.orig# maybe i need to update autoconf... >> Adding "autogen.sh". It generates files like "configure". >> >> Question: Do we need this? Without it, I cannot compile OpenBSC. > >Why is invoking autoreconf not enough? > >z.

15 years

2
1
0 0

AW: patch 12 14, 15, 16

by Andreas.Eversberg

-----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.

15 years

1
0
0 0

patches for openbsc

by Andreas.Eversberg

hi, finally my patch is documented (almost). you will find the documentation of the patch: http://home.eversberg.eu/stage1.html the patch in plain text fromat: http://home.eversberg.eu/stage1.patch it also includes the changes i posted here before. if you have questions, ask. regards, andreas

15 years

5
8
0 0

patch 27: application

by Andreas.Eversberg

This patch replaces the application patch 12. Because the application was not checked in yet, I will not document the bugs I fixed in it.

15 years

2
1
0 0

patch 26: releasel2

by Andreas.Eversberg

Tells mISDN not to release layer 2 on closing socket, when not requested. If mISDN was told to release layer 2 once, it will continue to release layer 2 on every shutdown of OpenBSC.

15 years

2
1
0 0

patch 25: e1link

by Andreas.Eversberg

During bootstrap of BS11, the e1links are initialized. This must also be done when BS11 is already bootstrapped (when restarting OpenBSC). It is required to correctly multiplex the audio traffic between channels. Without it, all time slots refer to card 0, slot 0, subslot 0, which causes crashes when handling TRAU frames..

15 years

2
1
0 0

patch 24: output

by Andreas.Eversberg

Some debug outputs now correctly use end-of-line characters.

15 years

2
1
0 0

patch 22: lchan_use

by Andreas.Eversberg

This patch will fix usage counting of logical channel. Also it adds usage counter debugging. The use counter is increased on loaction update request. The counter is not decreased when location update responds (mm_rx_id_resp()), but if subscriber is authorized, it will be decreased on release_loc_update_req(). If lchan closes, the location update is also released (release_loc_update_req()), also if the location update times out. In case of a channel connection failure with cause 0x18, the logical channel is not released if usage counter of lchan is not 0.

15 years

2
1
0 0

patch 17: subscr usage

by Andreas.Eversberg

This patch will fix subscriber usage counting and adds debugging whenever usage is increased or decreased. It may happen, that the subscriber count will not be 0 after releasing of a call. (This problem is solved with the application patch (27), which will replace static call transaction by a dynamic transaction list, and use subscriber for each transaction created.)

15 years

2
1
0 0

patch 12 14, 15, 16

by Andreas.Eversberg

The patch 14 and 16 have been updated. They are not applied yet. Patches 12 and 15 are obsolete. Patch 14 will fix DMM debugging. now MM debugging is shown, if given by debug option, not only by default debugging. the color of DNM debugging changes to cyan as it is supposed to be. Patch 16 will store the current LAC in the HLC when the subscriber successfully attaches. If the subscriber detaches, the LAC will be set to 0.

15 years

2
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC June 2009