OpenBSC October 2009

openbsc@lists.osmocom.org

25 participants
64 discussions

AW: [RFC] Subscriber Reference Counting
by Andreas.Eversberg 28 Oct '09

28 Oct '09

hi holger, i would like to test it. but before i can do that, i need to know what ressource are actually counted. for example: a transaction holds one ressource, paging holds one ressource, as well as a channel that is associated to that subscriber's transaction. what about sms? shold an object of "struct gsm_sms" be counted as one ressource, or each sender/receiver within this structure, or all together (one for the sms, one for the sender and one for the receiver)? i need a list of all subscriber ressources for gsm_04_11.c regards, andreas

2 1

OpenBSC system_information branch
by Harald Welte 27 Oct '09

27 Oct '09

Hi! I've updated the system_information branch. The purpose of this branch is to move away from static u_int8_t arrays that are used as templates for the SYSTEM INFORMATION messages. Thise arrays are reminiscent of the old days of bs11_init, where everything had been done this way. The current head of system_information is now managing to actually do that. The full SI1-SI4 on the BCCH as well as the SI5/SI6 on the SACCH are now created from scratch (see code in system_information.c) The content of the SI is "phase 1" content, i.e. before rest octets were introduced I've also written some code to generate the rest octets, as well as a some "rest octet encoding aware" bit vector routines that understand the meaning of 0/1/L/H. However, those rest octet routines are not yet used. They need some careful testing before use. Testing is actually quite hard, as not even wireshark has dissector for the system information messages (anyone interested in contributing on this? It's needed for airprobe, too) One interesting bit that stalled development for quite some time: If you send a SACCH FILLing with length > 18 bytes, then the nanoBTS will actually crash somewhere in the layer 2, sending you long error strings with addresses (stack?) as error reports before rebooting :) Feel free to start testing the system_information branch if you're interested. I'd be happy to hear any "master works for my phone, but system_information branch confuses my phone" kind of reports. 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)

3 3

Status of wireshark patches
by Harald Welte 27 Oct '09

27 Oct '09

Hi! Holger has asked me to send an update on the status of the wireshark patches that we have in git: gsm_a_rr-rrlp.patch and abisip.patch are mainline wireshark, they can be removed from our git tree. abis_oml.patch: * does not yet dissect all the different 12.21 IEs, especially not all of the standard IEs * does not yet differentiate between BTS types. We need a preference where we can select the BTS model in order to really pars all the messages, plus vendor dependent IE tables * might possibly use non-standard C language syntax and thus not be portable to micrsofot compilers on windows. not sure what the wireshark requirements are in that regard rsli-ipaccess.patch: * does not support all of the ip.access RSL extensions yet * no major reason why it should nt be merged to wireshark * additional ip.access RSL extensions can be sent as incremental patches lucent-hmb.patch * this is just a minimal stub, should be completed more before submitting anywhere -- - Harald Welte <laforge(a)gpl-violations.org> http://gpl-violations.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Errors reports by clang --analyze in abis_nm.c
by Holger Freyther 27 Oct '09

27 Oct '09

Hey, the clang C frontend has found some issues in our OpenBSC code. I think we will need to have a table for BS11 and one for ipaccess with the shared/speced elements being in both tables. Here is the list of things I can resolve myself right now: [NM_ATT_IPACC_FREQ_CTRL] = { TLV_TYPE_FIXED, 2 } [NM_ATT_IPACC_FREQ_CTRL] = { TLV_TYPE_TV, }, these vendor specific commands have the same value: [NM_ATT_IPACC_NS_CFG] = { TLV_TYPE_TL16V }, [NM_ATT_BS11_BIT_ERR_THESH] = { TLV_TYPE_FIXED, 2 }, [NM_ATT_IPACC_BSSGP_CFG] = { TLV_TYPE_TL16V }, [NM_ATT_BS11_BOOT_SW_VERS] = { TLV_TYPE_TLV }, ^~~~~~~~~~~~ [NM_ATT_IPACC_RLC_CFG] = { TLV_TYPE_TL16V }, [NM_ATT_BS11_CCLK_ACCURACY] = { TLV_TYPE_TV }, ^~~~~~~~~~~ [NM_ATT_IPACC_ALM_THRESH_LIST]= { TLV_TYPE_TL16V }, [NM_ATT_BS11_CCLK_TYPE] = { TLV_TYPE_TV }, ^~~~~~~~~~~ [NM_ATT_IPACC_CODING_SCHEMES] = { TLV_TYPE_TL16V }, [0xa8] = { TLV_TYPE_TLV }, [NM_ATT_IPACC_UPTIME] = { TLV_TYPE_TL16V }, [NM_ATT_BS11_L1_PROT_TYPE] = { TLV_TYPE_TV }, [NM_ATT_IPACC_RLC_CFG_3] = { TLV_TYPE_TL16V }, [NM_ATT_BS11_LINE_CFG] = { TLV_TYPE_TV }, [0x85] = { TLV_TYPE_TV }, [NM_ATT_IPACC_STREAM_ID] = { TLV_TYPE_TV, },

2 1

[RFC] Subscriber Reference Counting
by Holger Freyther 27 Oct '09

27 Oct '09

Hi, IIRC Harald et all. were seeing GSM subscriber leakage at HAR2009 and we have not yet explored the cause of this problem. I would like to have no subscriber leaks for the congress and propose the following changes. I have pushed the "holger/subscr-ref-handling" branch to our repository and would be happy if people could give it a spin. My testing here is pretty limited. Currently I have two commits. The second is removing a leak in the vty console for SMS sending and subscriber usage and the other patch is trying to stop borrowing someone else's gsm_subscriber reference. More details below. Currently we do lchan->subscr = new_subscr and then we have two flavors of checking if the channel is already used. I have changed this to use a new assignment function that will do the check consistently and updated call sites. I would establish the following guideline for gsm_subscriber handling: In every method where subscr_get* is called the subscriber must be released at the exit with subscr_put unless the referenced provider is assigned to a struct that is created in the same method, then the subscriber must be released next to the talloc_free. More details: - paging.c seems fine - gsm_subscriber_chan seems fine - gsm_04_08_utils.c seems fine - gsm_04_08.c seems fine now as well. subscr_get/_put should be balanced - gsm_04_11.c if we leak a subscriber we also leak a sms I have not checked all SMS paths to be sure we don't leak there. I would be very happy if people could test this. z,

1 0

[PATCH 1/4] ip.access: Fix bad call to patch_nm_tables when configuring channel
by Sylvain Munaut 26 Oct '09

26 Oct '09

From: Sylvain Munaut <tnt(a)246tNt.com> The bts variable isn't even defined at that point causing crashes. The patch_nm_tables is called for BTS object class. Signed-off-by: Sylvain Munaut <tnt(a)246tNt.com> --- openbsc/src/bsc_init.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/openbsc/src/bsc_init.c b/openbsc/src/bsc_init.c index 1394dd8..0adc656 100644 --- a/openbsc/src/bsc_init.c +++ b/openbsc/src/bsc_init.c @@ -378,7 +378,6 @@ int nm_state_event(enum nm_evt evt, u_int8_t obj_class, void *obj, trx = ts->trx; if (new_state->operational == 1 && new_state->availability == NM_AVSTATE_DEPENDENCY) { - patch_nm_tables(bts); enum abis_nm_chan_comb ccomb = abis_nm_chcomb4pchan(ts->pchan); abis_nm_set_channel_attr(ts, ccomb); -- 1.6.4

2 8

Re: RRLP
by Dieter Spaar 26 Oct '09

26 Oct '09

Hello Sylvain, On Mon, 26 Oct 2009 10:19:55 +0100, "Sylvain Munaut" <246tnt(a)gmail.com> wrote: > > So a lot of phones seem to support this and with assistance data could > maybe provide a location. > Did you try to correlate IMEI manufacturer part with the messages ? No, not yet. > Do you have any log of a successful response ? Maybe I screw up the > encoding of the position somehow. Yes, here is an example. This is the response from the phone 42 11 00 00 6A 57 9F B6 41 29 B1 B0 10 8D 84 00 6C 9C 9C 01 B1 0C This is decoded PDU (asn1c was used): PDU ::= { referenceNumber: 2 component: MsrPosition-Rsp ::= { locationInfo: LocationInfo ::= { refFrame: 0 gpsTOW: 6969247 fixType: 1 posEstimate: 90 4A 6C 6C 04 23 61 00 1B 27 27 00 6C 43 } } } And those are the coordinates from "posEstimate" (I did not care about the height): 52.329040 - 52 19'44" N 5.819342 - 5 49' 9" E Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Re: RRLP
by Dieter Spaar 26 Oct '09

26 Oct '09

Hello, here is a summary of the RRLP requests from HAR2009. It is the summary from a time periode of about 10 hours near the end of the event. Total number of RRLP responses: 2179 "methodNotSupported" response: 122 "notEnoughSats" response: 667 "gpsAssDataMissing" response: 1368 Successful positions returned: 22 Number of different phones: 86 Phones which returned "methodNotSupported": 5 Phones which returned a position: 7 Requested assitance data for the "gpsAssDataMissing" response: 530 Navigation Model, Reference Location, Reference Time 468 Navigation Model, Reference Location 141 Navigation Model 123 Almanac, Navigation Model, Reference Location, Reference Time 58 Almanac, Navigation Model, Reference Location, Reference Time, Real-Time Integrity 27 Almanac, Navigation Model, Reference Location 13 Almanac, UTC Model, Ionospheric Model, Navigation Model, Reference Location, Reference Time, Real-Time Integrity 5 Reference Location 3 Navigation Model, Reference Time And this was the request sent to the phones: PDU: 40 01 78 A8 referenceNumber 2 msrPositionReq methodType msBased Accuracy 60 positionMethod gps measureResponseTime 2 useMultipleSets oneSet Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

Re: RRLP
by Dieter Spaar 25 Oct '09

25 Oct '09

Hello Sylvain, On Sun, 25 Oct 2009 19:50:53 +0100, "Sylvain Munaut" <246tnt(a)gmail.com> wrote: > Does anyone have a clue ? You already had a look at TS 44.031 ? It describes the RRLP procedures in detail. It also mentiones that the RRLP maximum PDU size is 242 bytes and that you have to use RRLP pseudo-segmentation to deliver larger PDUs, however it also mentiones that "legacy" MS and SMLC may exceed this PDU size. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

RRLP
by Sylvain Munaut 25 Oct '09

25 Oct '09

Hi, I've been working on improving RRLP support lately. Most precisely, providing real assistance data sourced directly from a GPS receiver attached to the control PC. My problem right now is that the generated APDU is about 1500 bytes and obviously there is no way that fits in a single L3 frame. GSM 04.08 9.1.53 describes the format of the APDU and there is a 4 bits flag fields, which from what I understand occupies the 4 upper fields of the first octet and that allows fragmentation. From reading the IE description in 10.5.2.49 I should set : 0x10 for the first segment 0x30 for the intermediate segments 0x20 for the last segment Which is what I tried, by modifying the gsm48_send_rr_app_info function like this : http://yourpaste.net/3558/ Unfortunately, I couldn't make it work. When I set the segment size to try and have L3 frame of 251 bytes, I get some RSL error back and when I use a smaller size, the MS seems to interpret each segment separately and not reconstituting them ... Does anyone have a clue ? Sylvain Here's a log, where you see the MS answering independently to the 3 segments (with errors since you can't just decode partial data ...): <0002> gsm_04_08.c:280 lchan (bts=0,trx=0,ts=0,ch=0) decreases usage to: 0 <0004> gsm_04_08.c:901 -> LOCATION UPDATE ACCEPT <0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x02 to MS. l3_len = 14 <0004> gsm_04_08.c:1222 -> MM INFO <0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x32 to MS. l3_len = 22 <0008> gsm_04_08.c:1651 TX APPLICATION INFO id=0x00, len=688 <0008> gsm_04_08.c:1669 TX APPLICATION INFO Segment ofs=0 len=230 id=10 <0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 06) Sending 0x38 to MS. l3_len = 234 <0008> gsm_04_08.c:1669 TX APPLICATION INFO Segment ofs=230 len=230 id=30 <0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 06) Sending 0x38 to MS. l3_len = 234 <0008> gsm_04_08.c:1669 TX APPLICATION INFO Segment ofs=460 len=228 id=20 <0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 06) Sending 0x38 to MS. l3_len = 232 <0001> abis_rsl.c:1282 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0 DATA INDICATION <0004> gsm_04_08.c:1438 TMSI Reallocation Completed. Subscriber: 206205003327508 <0001> abis_rsl.c:1282 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0 DATA INDICATION <0020> gsm_04_08.c:1594 RX APPLICATION INFO id/flags=0x00 apdu_len=2 apdu=48 20 <0010> abis_rsl.c:997 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 CONNECTION FAIL: CAUSE=0x01(Radio Link Failure) RELEASING. <0010> abis_rsl.c:720 RF Channel Release CMD channel=(bts=0,trx=0,ts=0) chan_nr=0x28 <0010> abis_rsl.c:997 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 RF CHANNEL RELEASE ACK <0001> abis_rsl.c:1282 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0 DATA INDICATION <0020> gsm_04_08.c:1594 RX APPLICATION INFO id/flags=0x00 apdu_len=2 apdu=88 10 <0010> abis_rsl.c:720 RF Channel Release CMD channel=(bts=0,trx=0,ts=0) chan_nr=0x28 <0010> abis_rsl.c:997 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 RF CHANNEL RELEASE ACK <0001> abis_rsl.c:1282 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0 DATA INDICATION <0020> gsm_04_08.c:1594 RX APPLICATION INFO id/flags=0x00 apdu_len=2 apdu=c8 00 <0001> abis_rsl.c:1282 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0 RELEASE INDICATION <0010> abis_rsl.c:720 RF Channel Release CMD channel=(bts=0,trx=0,ts=0) chan_nr=0x20 <0010> abis_rsl.c:997 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 RF CHANNEL RELEASE ACK <0002> gsm_subscriber_base.c:150 subscr 201 usage decreased usage to: 0

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC October 2009