- OpenBSC - lists.osmocom.org

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

22 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

Re: Location Area Updates missed during calls
by Luca Valtulina 21 Mar '14

21 Mar '14

Indeed the problem has been already solved in the master branch by adding the "expire_timer_stopped" attributes to a gsm_subscriber_connection and then checking it upon expiration of the expire_lu timer for an active subscriber. Sorry to have re-raised the issue. luca

1 0

Fwd: Location Area Updates missed during calls
by Luca Valtulina 21 Mar '14

21 Mar '14

Hi holger, What is a network-initiated Location Area Update? Do you talk about > the NITB/BSC advertizing periodic updating? With Location Area Update I refer to the Location Update procedure (I made confusion with the UMTS protocol where "Area" has been added in-between). I also have to apologies about that "network-initiated" which is clearly wrong since is the MS which triggers the procedure by sending a location update request signal (what I meant is that the T3212 timer is provided to the MS by the network). > > I find this behavior annoying mostly in scenarios where the T3212 (LAU > > timer) has been setup to a low value. > > About which software and which versions do you talk? mmm, I didn't quite get your question here. After performing further testing I can wrap up the issue as following: when a MS ends a call after the expire_lu time, it will be considered expired in the HLR (because two LUs were missed by the network). When the (now expired) MS initiates a call, the CM service will be rejected by the network with cause 4 (GSM48_REJECT_IMSI_UNKNOWN_IN_VLR). Needless to say that when a different MS tries to establish a call towards the (now expired) MS, this call will also be dropped because the destination MS is (seen as) detached from the BTS. Now I think that if we want to have a more precise location management, a lower expiration interval is a possibilities: this can be achieved by either lowering down the t3212 value and keeping the same expire_lu calculation (2 times t3212 + 1 minute) or by modifying the expire_lu calculation. In this scenarios the issue described above is more likely to happen (higher probability of having ~10 minutes calls than > 60 minutes). So indeed, is this behavior expected by the GSM protocol? I think that update the HLR whenever an MS exits a call will be a costless procedure which can avoid the annoyance of having the first next call dropped if this happens prior to the triggering of the LU by the interested MS. luca

1 0

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