OpenBSC

openbsc@lists.osmocom.org

4315 discussions

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

24 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 openggsn v2] gtp: fix endianness in teid field of GTPv0 header
by pablo＠gnumonks.org 23 Mar '14

23 Mar '14

From: Pablo Neira Ayuso <pablo(a)gnumonks.org> This field needs to be in network byte order as well. This problem may manifest if you use ggsn and sgsn with different endianness. It also show up when using the gtp kernel mode since the downlink packets are using network byte order in the 64-bits teid field, which osmo-sgsn / libgtp doesn't expect. --- v2: Add function to encapsulate the code to access and to build the teid as Holger suggested. Tested with and without gtp kernel support. If no objections, I'll push this to master. gtp/gtp.c | 34 +++++++++++++--------------------- gtp/pdp.c | 6 ++++++ gtp/pdp.h | 2 ++ 3 files changed, 21 insertions(+), 21 deletions(-) diff --git a/gtp/gtp.c b/gtp/gtp.c index 3cc0c0b..6185634 100644 --- a/gtp/gtp.c +++ b/gtp/gtp.c @@ -250,7 +250,7 @@ static uint64_t get_tid(void *pack) union gtp_packet *packet = (union gtp_packet *)pack; if ((packet->flags & 0xe0) == 0x00) { /* Version 0 */ - return packet->gtp0.h.tid; + return be64toh(packet->gtp0.h.tid); } return 0; } @@ -425,10 +425,10 @@ int gtp_req(struct gsn_t *gsn, int version, struct pdp_t *pdp, addr.sin_port = htons(GTP0_PORT); packet->gtp0.h.length = hton16(len - GTP0_HEADER_SIZE); packet->gtp0.h.seq = hton16(gsn->seq_next); - if (pdp) + if (pdp) { packet->gtp0.h.tid = - (pdp->imsi & 0x0fffffffffffffffull) + - ((uint64_t) pdp->nsapi << 60); + htobe64(pdp_gettid(pdp->imsi, pdp->nsapi)); + } if (pdp && ((packet->gtp0.h.type == GTP_GPDU) || (packet->gtp0.h.type == GTP_ERROR))) packet->gtp0.h.flow = hton16(pdp->flru); @@ -581,7 +581,7 @@ int gtp_resp(int version, struct gsn_t *gsn, struct pdp_t *pdp, if ((packet->flags & 0xe0) == 0x00) { /* Version 0 */ packet->gtp0.h.length = hton16(len - GTP0_HEADER_SIZE); packet->gtp0.h.seq = hton16(seq); - packet->gtp0.h.tid = tid; + packet->gtp0.h.tid = htobe64(tid); if (pdp && ((packet->gtp0.h.type == GTP_GPDU) || (packet->gtp0.h.type == GTP_ERROR))) packet->gtp0.h.flow = hton16(pdp->flru); @@ -1329,12 +1329,9 @@ int gtp_create_pdp_ind(struct gsn_t *gsn, int version, memset(pdp, 0, sizeof(struct pdp_t)); if (version == 0) { - pdp->imsi = - ((union gtp_packet *)pack)->gtp0. - h.tid & 0x0fffffffffffffffull; - pdp->nsapi = - (((union gtp_packet *)pack)->gtp0. - h.tid & 0xf000000000000000ull) >> 60; + uint64_t tid = be64toh(((union gtp_packet *)pack)->gtp0.h.tid); + + pdp_set_imsi_nsapi(pdp, tid); } pdp->seq = seq; @@ -2051,12 +2048,9 @@ int gtp_update_pdp_ind(struct gsn_t *gsn, int version, /* For GTP1 we must use imsi and nsapi if imsi is present. Otherwise */ /* we have to use the tunnel endpoint identifier */ if (version == 0) { - imsi = - ((union gtp_packet *)pack)->gtp0. - h.tid & 0x0fffffffffffffffull; - nsapi = - (((union gtp_packet *)pack)->gtp0. - h.tid & 0xf000000000000000ull) >> 60; + uint64_t tid = be64toh(((union gtp_packet *)pack)->gtp0.h.tid); + + pdp_set_imsi_nsapi(pdp, tid); /* Find the context in question */ if (pdp_getimsi(&pdp, imsi, nsapi)) { @@ -2645,7 +2639,7 @@ int gtp_error_ind_conf(struct gsn_t *gsn, int version, struct pdp_t *pdp; /* Find the context in question */ - if (pdp_tidget(&pdp, ((union gtp_packet *)pack)->gtp0.h.tid)) { + if (pdp_tidget(&pdp, be64toh(((union gtp_packet *)pack)->gtp0.h.tid))) { gsn->err_unknownpdp++; gtp_errpack(LOG_ERR, __FILE__, __LINE__, peer, pack, len, "Unknown PDP context"); @@ -3196,9 +3190,7 @@ int gtp_data_req(struct gsn_t *gsn, struct pdp_t *pdp, void *pack, unsigned len) packet.gtp0.h.length = hton16(len); packet.gtp0.h.seq = hton16(pdp->gtpsntx++); packet.gtp0.h.flow = hton16(pdp->flru); - packet.gtp0.h.tid = - (pdp->imsi & 0x0fffffffffffffffull) + - ((uint64_t) pdp->nsapi << 60); + packet.gtp0.h.tid = htobe64(pdp_gettid(pdp->imsi, pdp->nsapi)); if (len > sizeof(union gtp_packet) - sizeof(struct gtp0_header)) { gsn->err_memcpy++; diff --git a/gtp/pdp.c b/gtp/pdp.c index dfb91ea..dc21bf8 100644 --- a/gtp/pdp.c +++ b/gtp/pdp.c @@ -370,6 +370,12 @@ uint64_t pdp_gettid(uint64_t imsi, uint8_t nsapi) return (imsi & 0x0fffffffffffffffull) + ((uint64_t) nsapi << 60); } +void pdp_set_imsi_nsapi(struct pdp_t *pdp, uint64_t teid) +{ + pdp->imsi = teid & 0x0fffffffffffffffull; + pdp->nsapi = (teid & 0xf000000000000000ull) >> 60; +} + int ulcpy(void *dst, void *src, size_t size) { if (((struct ul255_t *)src)->l <= size) { diff --git a/gtp/pdp.h b/gtp/pdp.h index b069a6f..6e30467 100644 --- a/gtp/pdp.h +++ b/gtp/pdp.h @@ -242,6 +242,8 @@ int pdp_tidset(struct pdp_t *pdp, uint64_t tid); int pdp_tiddel(struct pdp_t *pdp); int pdp_tidget(struct pdp_t **pdp, uint64_t tid); +void pdp_set_imsi_nsapi(struct pdp_t *pdp, uint64_t teid); + /* int pdp_iphash(void* ipif, struct ul66_t *eua); int pdp_ipset(struct pdp_t *pdp, void* ipif, struct ul66_t *eua); -- 1.7.10.4

2 1

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

23 Mar '14

1 0

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

22 Mar '14

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

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC