OpenBSC

openbsc@lists.osmocom.org

14 participants
4246 discussions

[PATCH] ip.access: Header has a 16bit length in network byte order
by Sylvain Munaut 29 Oct '09

29 Oct '09

From: Sylvain Munaut <tnt(a)246tNt.com> This is confirmed by looking at the source of their dissector. The length can go up to 273 bytes apparently (again, according to the source of their dissector). Signed-off-by: Sylvain Munaut <tnt(a)246tNt.com> --- openbsc/include/openbsc/ipaccess.h | 3 +-- openbsc/src/input/ipaccess.c | 10 +++++----- 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/openbsc/include/openbsc/ipaccess.h b/openbsc/include/openbsc/ipaccess.h index eb17167..3956877 100644 --- a/openbsc/include/openbsc/ipaccess.h +++ b/openbsc/include/openbsc/ipaccess.h @@ -4,8 +4,7 @@ #include "e1_input.h" struct ipaccess_head { - u_int8_t zero; - u_int8_t len; + u_int16_t len; /* network byte order */ u_int8_t proto; u_int8_t data[0]; } __attribute__ ((packed)); diff --git a/openbsc/src/input/ipaccess.c b/openbsc/src/input/ipaccess.c index 1265982..ea44f1e 100644 --- a/openbsc/src/input/ipaccess.c +++ b/openbsc/src/input/ipaccess.c @@ -259,7 +259,7 @@ struct msgb *ipaccess_read_msg(struct bsc_fd *bfd, int *error) { struct msgb *msg = msgb_alloc(TS1_ALLOC_SIZE, "Abis/IP"); struct ipaccess_head *hh; - int ret = 0; + int len, ret = 0; if (!msg) { *error = -ENOMEM; @@ -284,8 +284,9 @@ struct msgb *ipaccess_read_msg(struct bsc_fd *bfd, int *error) /* then read te length as specified in header */ msg->l2h = msg->data + sizeof(*hh); - ret = recv(bfd->fd, msg->l2h, hh->len, 0); - if (ret < hh->len) { + len = ntohs(hh->len); + ret = recv(bfd->fd, msg->l2h, len, 0); + if (ret < len) { fprintf(stderr, "short read!\n"); msgb_free(msg); *error = -EIO; @@ -374,8 +375,7 @@ void ipaccess_prepend_header(struct msgb *msg, int proto) /* prepend the ip.access header */ hh = (struct ipaccess_head *) msgb_push(msg, sizeof(*hh)); - hh->zero = 0; - hh->len = msg->len - sizeof(*hh); + hh->len = htons(msg->len - sizeof(*hh)); hh->proto = proto; } -- 1.6.5.1

2 1

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

28 Oct '09

> Currently the branch is doing: > - Stops borrowing the gsm_subscriber to the lchan > - Fixes leaks in the vty_interface_layer3.c code for subscriber action > - Fixes a subscriber leak (actually two) in mncc_send. > > if wanted I can attach the patches to this mail to ease reviewing. what branch is it? do i need additional patches? i use the master with the RTP patch applied.

2 1

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC