March 2014 - OpenBSC - lists.osmocom.org

3 OpenBSC moderator request(s) waiting
by openbsc-bounces＠lists.osmocom.org 21 Mar '14

21 Mar '14

The OpenBSC(a)lists.osmocom.org mailing list has 3 request(s) waiting for your consideration at: https://lists.osmocom.org/mailman/admindb/openbsc Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014 Subject: Unsubscribe Cause: Message may contain administrivia From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014 Subject: unsubscribe Cause: Message may contain administrivia From: holger(a)freyther.de on Thu Mar 20 21:44:00 2014 Subject: DRAFT for a 30C3 report. Care to review? Cause: Message body is too big: 1033152 bytes with a limit of 400 KB

1 0

[PATCH] sms_test: Use C99 initializers.
by Alexander Chemeris 20 Mar '14

20 Mar '14

Hi Holger, On Sun, Mar 16, 2014 at 1:55 PM, Holger Hans Peter Freyther <holger(a)freyther.de> wrote: > E.g. in one > of the testcases I noticed that you don't use C99 initializers but the > old/error prone way of initializing. :) Yes, I think in this particular case the old way is more compact and thus more readable. I added C99 initializers to the test (see the patch attached or achemeris/sms-fixes branch) and to me it looks less readable and thus more error prone. If you see any benefits of this patch - feel free to merge it, though. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. / ООО УмРадио https://fairwaves.co

2 1

[PATCH 1/2 openggsn] gtp: fix wrong binary layout for struct gtp0_header in x86_64
by pablo＠gnumonks.org 20 Mar '14

20 Mar '14

From: Pablo Neira Ayuso <pablo(a)gnumonks.org> struct gtp0_header needs __attribute__((packed)) to make sure that gcc doesn't add a hole of 4 bytes to align the 64-bits teid, resulting in 24 bytes instead of 20 bytes. This was breaking gtpv0 in my gprs testbed with my x86_64 laptop. While at it, add also attribute packed to other headers just to make sure that gcc doesn't pad the structures with holes. --- If no objections, I'll push this to master. gtp/gtp.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gtp/gtp.h b/gtp/gtp.h index 54af96e..39a902f 100644 --- a/gtp/gtp.h +++ b/gtp/gtp.h @@ -161,7 +161,7 @@ struct gtp0_header { /* Descriptions from 3GPP 09.60 */ uint8_t spare2; /* 11 Spare */ uint8_t spare3; /* 12 Spare */ uint64_t tid; /* 13 Tunnel ID */ -}; /* 20 */ +} __attribute__((packed)); /* 20 */ struct gtp1_header_short { /* Descriptions from 3GPP 29060 */ uint8_t flags; /* 01 bitfield, with typical values */ @@ -174,7 +174,7 @@ struct gtp1_header_short { /* Descriptions from 3GPP 29060 */ uint8_t type; /* 02 Message type. T-PDU = 0xff */ uint16_t length; /* 03 Length (of IP packet or signalling) */ uint32_t tei; /* 05 - 08 Tunnel Endpoint ID */ -}; +} __attribute__((packed)); struct gtp1_header_long { /* Descriptions from 3GPP 29060 */ uint8_t flags; /* 01 bitfield, with typical values */ @@ -190,7 +190,7 @@ struct gtp1_header_long { /* Descriptions from 3GPP 29060 */ uint16_t seq; /* 10 Sequence Number */ uint8_t npdu; /* 11 N-PDU Number */ uint8_t next; /* 12 Next extension header type. Empty = 0 */ -}; +} __attribute__((packed)); struct gtp0_packet { struct gtp0_header h; -- 1.7.10.4

3 4

Location Area Updates missed during calls
by Luca Valtulina 20 Mar '14

20 Mar '14

Hi list, when a MS is in a call it misses the network-initiated Location Area Update procedure(s). This inconvenience can lead (if the call ends after the expire_lu time) to having an attached (and active) subscriber marked as expired in the HLR. Furthermore if at this point the MS initiates a new call, the call will be dropped and (as expected) a new Location Area Update procedure will be initiated by the BSC. I find this behavior annoying mostly in scenarios where the T3212 (LAU timer) has been setup to a low value. To tackle this issue I thought of triggering a subscriber update when a call get released (either by the network or by the MS) for each of the MS involved in the call. The code can also be optimized by checking whether the subscriber is expired before performing the update. I can provide a patch if you also consider the above as a misbehavior of OpenBSC. cheers luca

3 2

2 OpenBSC moderator request(s) waiting
by openbsc-bounces＠lists.osmocom.org 20 Mar '14

20 Mar '14

The OpenBSC(a)lists.osmocom.org mailing list has 2 request(s) waiting for your consideration at: https://lists.osmocom.org/mailman/admindb/openbsc Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014 Subject: Unsubscribe Cause: Message may contain administrivia From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014 Subject: unsubscribe Cause: Message may contain administrivia

1 0

2 OpenBSC moderator request(s) waiting
by openbsc-bounces＠lists.osmocom.org 19 Mar '14

19 Mar '14

The OpenBSC(a)lists.osmocom.org mailing list has 2 request(s) waiting for your consideration at: https://lists.osmocom.org/mailman/admindb/openbsc Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014 Subject: Unsubscribe Cause: Message may contain administrivia From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014 Subject: unsubscribe Cause: Message may contain administrivia

1 0

2 OpenBSC moderator request(s) waiting
by openbsc-bounces＠lists.osmocom.org 18 Mar '14

18 Mar '14

The OpenBSC(a)lists.osmocom.org mailing list has 2 request(s) waiting for your consideration at: https://lists.osmocom.org/mailman/admindb/openbsc Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014 Subject: Unsubscribe Cause: Message may contain administrivia From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014 Subject: unsubscribe Cause: Message may contain administrivia

1 0

2 OpenBSC moderator request(s) waiting
by openbsc-bounces＠lists.osmocom.org 17 Mar '14

17 Mar '14

The OpenBSC(a)lists.osmocom.org mailing list has 2 request(s) waiting for your consideration at: https://lists.osmocom.org/mailman/admindb/openbsc Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014 Subject: Unsubscribe Cause: Message may contain administrivia From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014 Subject: unsubscribe Cause: Message may contain administrivia

1 0

[PATCH] sysmobts: Add a magic number to the hLayer2 to differentiate it
by Holger Hans Peter Freyther 16 Mar '14

16 Mar '14

From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com> The DSP/FPGA appears to report bogus PhDataInd with hlayer2 == 0. Currently this would match the TRX==0,TS==0 and SS=0 and then we report bad measurement reports. Add a magic number to the lower eight bit of the hLayer2 to differentiate valid numbers. Addresses: <0004> measurement.c:97 (bts=0,trx=0,ts=0,ss=0) measurement during state: NONE <0004> measurement.c:102 (bts=0,trx=0,ts=0,ss=0) no space for uplink measurement --- src/osmo-bts-sysmo/oml.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/src/osmo-bts-sysmo/oml.c b/src/osmo-bts-sysmo/oml.c index 596680f..7fcd4c6 100644 --- a/src/osmo-bts-sysmo/oml.c +++ b/src/osmo-bts-sysmo/oml.c @@ -704,17 +704,24 @@ err: uint32_t l1if_lchan_to_hLayer(struct gsm_lchan *lchan) { - return (lchan->nr << 8) | (lchan->ts->nr << 16) | (lchan->ts->trx->nr << 24); + return 0xBB + | (lchan->nr << 8) + | (lchan->ts->nr << 16) + | (lchan->ts->trx->nr << 24); } /* obtain a ptr to the lapdm_channel for a given hLayer */ struct gsm_lchan * l1if_hLayer_to_lchan(struct gsm_bts_trx *trx, uint32_t hLayer2) { + uint8_t magic = hLayer2 & 0xff; uint8_t ts_nr = (hLayer2 >> 16) & 0xff; uint8_t lchan_nr = (hLayer2 >> 8)& 0xff; struct gsm_bts_trx_ts *ts; + if (magic != 0xBB) + return NULL; + /* FIXME: if we actually run on the BTS, the 32bit field is large * enough to simply put a pointer inside. */ if (ts_nr >= ARRAY_SIZE(trx->ts)) -- 1.9.0

1 0

[PATCH 4/6] sms: Add missing brackets in the relative validity time calculation.
by Alexander Chemeris 16 Mar '14

16 Mar '14

-- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. / ООО УмРадио https://fairwaves.co

2 3