June 2014 - OpenBSC - lists.osmocom.org

[PATCH 0/4] core/conv: Fast Viterbi decoding

by Thomas Tsou

Hi all, This patch set adds to libosmocore an optimized Viterbi decodeer for architecture specific (Intel SSE) and non-specific cases. The implementation covers codes with constraint lengths of K=5 and K=7 and rates 1/4 to 3/4, which make up the majority of GSM use cases. Speedup from the current implementation is in the range of 5 to 20 depending on the processor and code type. API is unchanged. Tested on Haswell (i7-4770K) and Atom (D2550). Additional test codes from osmo-bts are included. Further tests for AWGN bit-error-rate and benchmarks can be found in the following repository. https://github.com/ttsou/osmo-conv-test Here are some examples. Bit error test for GPRS CS2 with SNR of 5 dB and 100000 bursts. $ ./conv_test -c 2 -e -r 5 -i 100000 ================================================= [+] Testing: GPRS CS2 [.] Specs: (N=2, K=5, non-recursive, flushed, not punctured) [.] Input length : ret = 290 exp = 290 -> OK [.] Output length : ret = 588 exp = 588 -> OK [.] BER tests: [..] Testing base: [..] Input BER.......................... 0.042443 [..] Output BER......................... 0.000006 [..] Output FER......................... 0.001350 (135) [..] Testing SIMD: [..] Input BER.......................... 0.042460 [..] Output BER......................... 0.000005 [..] Output FER......................... 0.001240 (124) Timed AFS benchmark with 8 threads and 100000 bursts per thread. $ ./conv_test -b -c 10 -j 8 -i 100000 ================================================= [+] Testing: GSM TCH/AFS 6.7 [.] Specs: (N=4, K=5, recursive, flushed, punctured) [.] Input length : ret = 140 exp = 140 -> OK [.] Output length : ret = 448 exp = 448 -> OK [.] Performance benchmark: [..] Encoding / Decoding 800000 bursts on 8 thread(s): [..] Testing base: [..] Elapsed time....................... 4.320001 secs [..] Rate............................... 25.925920 Mbps [..] Testing SIMD: [..] Elapsed time....................... 0.458272 secs [..] Rate............................... 244.396341 Mbps [..] Speedup............................ 9.426718 -TT

7 years, 12 months

5
13
0 0

OsmoSGSN [PATCH], Network Service

by Michal Grznár

Hi, I am using OsmoSGSN in topology with OpenGGSN and proprietary simulator of BSS. There was a problem with an implementation of Network service, cause Network Service implementation in the simulator of BSS is based on different release of 3GPP standard (3GPP TS 48. 016 v7. 4. 0 (2008-04)/Network service (Release 7))...and the problem is that in IP-subnetwork, which I am using there is no use for RESET or UNBLOCK procedure, so I had to do a PATCH in gprs_ns.c, which was needed to complete succesful connection between sim-bss and OsmoSGSN: switch (nsh->pdu_type) { case NS_PDUT_ALIVE: +++ LOGP(DNS, LOGL_INFO, "Rx NS ALIVE\n"); +++ /*mark NS-VC as alive*/ +++ (*nsvc)->state = NSE_S_ALIVE; +++ (*nsvc)->remote_state = NSE_S_ALIVE; +++ /*initiate TEST procedure: Send ALIVE_ACK and start timer*/ +++ rc = gprs_ns_tx_simple((*nsvc), NS_PDUT_ALIVE_ACK); +++ nsvc_start_timer((*nsvc), NSVC_TIMER_TNS_TEST); +++ break; . . . } another PATCH I needed to do was to change a little bit procedure for allocation of P-TMSI in procedure uint32_t sgsn_alloc_ptmsi(void) in gprs_sgsn.c uint32_t sgsn_alloc_ptmsi(void) { struct sgsn_mm_ctx *mm; uint32_t ptmsi; restart: +++ ptmsi = rand() | 0xc0000000; /*because of GPRS IMSI ATTACH*/ llist_for_each_entry(mm, &sgsn_mm_ctxts, list) { if (mm->p_tmsi == ptmsi) goto restart; } return ptmsi; } because in GPRS IMSI ATTACH in message ATTACH COMPLETE (3GPP 24.008, 23.003, 48.018) there is new TLLI==new allocated P-TMSI and I need local TLLI, so I had to do it this way regards Michal

9 years, 8 months

3
6
0 0

[PATCH] use osmocom auth API instead of direct calls

by Max Suraev

--- openbsc/src/libmsc/auth.c | 68 +++++++++++++++++++---------------------------- 1 file changed, 28 insertions(+), 40 deletions(-) diff --git a/openbsc/src/libmsc/auth.c b/openbsc/src/libmsc/auth.c index 10d8edf..ab84975 100644 --- a/openbsc/src/libmsc/auth.c +++ b/openbsc/src/libmsc/auth.c @@ -25,46 +25,11 @@ #include <openbsc/auth.h> #include <openbsc/gsm_data.h> -#include <osmocom/gsm/comp128.h> +#include <osmocom/crypt/auth.h> #include <stdlib.h> -static int -_use_xor(struct gsm_auth_info *ainfo, struct gsm_auth_tuple *atuple) -{ - int i, l = ainfo->a3a8_ki_len; - - if ((l > A38_XOR_MAX_KEY_LEN) || (l < A38_XOR_MIN_KEY_LEN)) { - LOGP(DMM, LOGL_ERROR, "Invalid XOR key (len=%d) %s\n", - ainfo->a3a8_ki_len, - osmo_hexdump(ainfo->a3a8_ki, ainfo->a3a8_ki_len)); - return -1; - } - - for (i=0; i<4; i++) - atuple->sres[i] = atuple->rand[i] ^ ainfo->a3a8_ki[i]; - for (i=4; i<12; i++) - atuple->kc[i-4] = atuple->rand[i] ^ ainfo->a3a8_ki[i]; - - return 0; -} - -static int -_use_comp128_v1(struct gsm_auth_info *ainfo, struct gsm_auth_tuple *atuple) -{ - if (ainfo->a3a8_ki_len != A38_COMP128_KEY_LEN) { - LOGP(DMM, LOGL_ERROR, "Invalid COMP128v1 key (len=%d) %s\n", - ainfo->a3a8_ki_len, - osmo_hexdump(ainfo->a3a8_ki, ainfo->a3a8_ki_len)); - return -1; - } - - comp128(ainfo->a3a8_ki, atuple->rand, atuple->sres, atuple->kc); - - return 0; -} - /* Return values * -1 -> Internal error * 0 -> Not available @@ -76,6 +41,11 @@ int auth_get_tuple_for_subscr(struct gsm_auth_tuple *atuple, { struct gsm_auth_info ainfo; int i, rc; + static struct osmo_sub_auth_data auth = { + .type = OSMO_AUTH_TYPE_GSM + }; + struct osmo_auth_vector _vec; + struct osmo_auth_vector *vec = &_vec; /* Get subscriber info (if any) */ rc = db_get_authinfo_for_subscr(&ainfo, subscr); @@ -109,13 +79,23 @@ int auth_get_tuple_for_subscr(struct gsm_auth_tuple *atuple, return 0; case AUTH_ALGO_XOR: - if (_use_xor(&ainfo, atuple)) - return 0; + auth.algo = OSMO_AUTH_ALG_XOR; + if ((ainfo.a3a8_ki_len > A38_XOR_MAX_KEY_LEN) || (ainfo.a3a8_ki_len < A38_XOR_MIN_KEY_LEN)) { + LOGP(DMM, LOGL_ERROR, "Invalid XOR key (len=%d) %s\n", + ainfo.a3a8_ki_len, + osmo_hexdump(ainfo.a3a8_ki, ainfo.a3a8_ki_len)); + return -1; + } break; case AUTH_ALGO_COMP128v1: - if (_use_comp128_v1(&ainfo, atuple)) - return 0; + auth.algo = OSMO_AUTH_ALG_COMP128v1; + if (ainfo.a3a8_ki_len != A38_COMP128_KEY_LEN) { + LOGP(DMM, LOGL_ERROR, "Invalid COMP128v1 key (len=%d) %s\n", + ainfo.a3a8_ki_len, + osmo_hexdump(ainfo.a3a8_ki, ainfo.a3a8_ki_len)); + return -1; + } break; default: @@ -124,6 +104,14 @@ int auth_get_tuple_for_subscr(struct gsm_auth_tuple *atuple, return 0; } + memcpy(auth.u.gsm.ki, ainfo.a3a8_ki, sizeof(auth.u.gsm.ki)); + + if (osmo_auth_gen_vec(vec, &auth, atuple->rand) < 0) + return -1; + + memcpy(atuple->sres, vec->sres, 4); + memcpy(atuple->kc, vec->kc, 8); + db_sync_lastauthtuple_for_subscr(atuple, subscr); DEBUGP(DMM, "Need to do authentication and ciphering\n"); -- 1.9.1

9 years, 9 months

3
3
0 0

Nokia UltraSite

by Sipos Csaba

Hi, I wonder if anybody was ever able to start a Nokia UltraSite with OpenBSC? In a nut shell: OML link is up and running, TRX1 is successfully loaded software, configured, and now it is stuck in "Waiting for LAPD..." state. The problem is that OpenBSC initiates the RSLSIG link for this TRX, but it seems the BTS is never answering to that: Sat Jun 28 14:33:27 2014 <0018> input/lapd.c:159 LAPD state change on TEI 1: NONE -> ASSIGNED Sat Jun 28 14:33:27 2014 <0018> input/lapd.c:212 LAPD Allocating SAP for SAPI=0 / TEI=1 Sat Jun 28 14:33:27 2014 <0018> input/lapd.c:223 k=2 N200=3 N201=260 T200=1.0 T203=10.0 Sat Jun 28 14:33:27 2014 <0018> lapd_core.c:288 Init DL layer: sequence range = 128, k = 2, history range = 4 Sat Jun 28 14:33:27 2014 <0018> lapd_core.c:227 new state LAPD_STATE_NULL -> LAPD_STATE_IDLE Sat Jun 28 14:33:27 2014 <0018> input/lapd.c:485 LAPD DL-ESTABLISH request TEI=1 SAPI=0 Sat Jun 28 14:33:27 2014 <0018> lapd_core.c:2180 Message DL-ESTABLISH-REQUEST received in state LAPD_STATE_IDLE Sat Jun 28 14:33:27 2014 <0018> lapd_core.c:1694 perform normal establishm. (SABM) Sat Jun 28 14:33:27 2014 <0018> lapd_core.c:227 new state LAPD_STATE_IDLE -> LAPD_STATE_SABM_SENT Sat Jun 28 14:33:27 2014 <0018> input/lapd.c:600 TX: 02 03 7f Sat Jun 28 14:33:27 2014 <0018> lapd_core.c:196 start T200 Sat Jun 28 14:33:27 2014 <0018> lapd_core.c:1779 lapd_send_i() called from line 1609 Sat Jun 28 14:33:27 2014 <0018> lapd_core.c:1618 we are not busy and have no pending data, send RR Sat Jun 28 14:33:27 2014 <0018> input/lapd.c:600 TX: f8 03 01 08 Sat Jun 28 14:33:28 2014 <0018> lapd_core.c:545 Timeout T200 (0x993ad40) state=5 Sat Jun 28 14:33:28 2014 <0018> input/lapd.c:600 TX: 02 03 7f Sat Jun 28 14:33:28 2014 <0018> lapd_core.c:196 start T200 Sat Jun 28 14:33:29 2014 <0018> lapd_core.c:545 Timeout T200 (0x993ad40) state=5 Sat Jun 28 14:33:29 2014 <0018> input/lapd.c:600 TX: 02 03 7f Sat Jun 28 14:33:29 2014 <0018> lapd_core.c:196 start T200 Sat Jun 28 14:33:30 2014 <0018> lapd_core.c:545 Timeout T200 (0x993ad40) state=5 Sat Jun 28 14:33:30 2014 <0018> input/lapd.c:600 TX: 02 03 7f Sat Jun 28 14:33:30 2014 <0018> lapd_core.c:196 start T200 Sat Jun 28 14:33:31 2014 <0018> lapd_core.c:545 Timeout T200 (0x993ad40) state=5 Sat Jun 28 14:33:31 2014 <0018> input/lapd.c:628 LAPD DL-RELEASE indication TEI=1 SAPI=0 Sat Jun 28 14:33:31 2014 <0018> lapd_core.c:303 Resetting LAPDm instance Sat Jun 28 14:33:31 2014 <0018> lapd_core.c:227 new state LAPD_STATE_SABM_SENT -> LAPD_STATE_IDLE Sat Jun 28 14:33:31 2014 <001b> bsc_init.c:318 Lost some E1 TEI link: 2 0x991b8f0 Sat Jun 28 14:33:31 2014 <0018> lapd_core.c:378 sending MDL-ERROR-IND cause 1 Sat Jun 28 14:33:31 2014 <0018> lapd_core.c:227 new state LAPD_STATE_IDLE -> LAPD_STATE_IDLE I set the correct E1 TS for TRX1 RSLSIG in Traffic manager, and double checked the RSLSIG config parameters on both end (OpenBSC config file and the BTS manager). Nokia Insite and MetroSite uses RSL TEI = 1 for the first TRX. Maybe Ultra uses other TEI number for the first TRX, this is something I will try, but otherwise I don't know how it is possible that not even the LAPD connection is being established... Any help is appreciated. Thanks, Csaba

9 years, 9 months

1
0
0 0

Bounce action notification

by mailman＠lists.osmocom.org

This is a Mailman mailing list bounce action notice: List: OpenBSC Member: devinechristophe(a)gmail.com Action: Subscription disabled. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman(a)lists.osmocom.org.

9 years, 10 months

1
0
0 0

[openbsc 1/3] libbsc, osmo-bsc{, _nat}: Prevent unaligned access when casting TLVP_VAL

by Daniel Willmann

foo = *((uintXX_t *) TLVP_VAL(...) can lead to unaligned access. To prevent that use tlvp_valXX_unal() to get the values. --- openbsc/src/libbsc/abis_rsl.c | 10 +++++----- openbsc/src/osmo-bsc/osmo_bsc_bssap.c | 2 +- openbsc/src/osmo-bsc_nat/bsc_mgcp_utils.c | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/openbsc/src/libbsc/abis_rsl.c b/openbsc/src/libbsc/abis_rsl.c index 748ab7e..d193078 100644 --- a/openbsc/src/libbsc/abis_rsl.c +++ b/openbsc/src/libbsc/abis_rsl.c @@ -1804,20 +1804,20 @@ static void ipac_parse_rtp(struct gsm_lchan *lchan, struct tlv_parsed *tv) uint16_t port, conn_id; if (TLVP_PRESENT(tv, RSL_IE_IPAC_LOCAL_IP)) { - ip.s_addr = *((uint32_t *) TLVP_VAL(tv, RSL_IE_IPAC_LOCAL_IP)); + ip.s_addr = tlvp_val32_unal(tv, RSL_IE_IPAC_LOCAL_IP); DEBUGPC(DRSL, "LOCAL_IP=%s ", inet_ntoa(ip)); lchan->abis_ip.bound_ip = ntohl(ip.s_addr); } if (TLVP_PRESENT(tv, RSL_IE_IPAC_LOCAL_PORT)) { - port = *((uint16_t *) TLVP_VAL(tv, RSL_IE_IPAC_LOCAL_PORT)); + port = tlvp_val16_unal(tv, RSL_IE_IPAC_LOCAL_PORT); port = ntohs(port); DEBUGPC(DRSL, "LOCAL_PORT=%u ", port); lchan->abis_ip.bound_port = port; } if (TLVP_PRESENT(tv, RSL_IE_IPAC_CONN_ID)) { - conn_id = *((uint16_t *) TLVP_VAL(tv, RSL_IE_IPAC_CONN_ID)); + conn_id = tlvp_val16_unal(tv, RSL_IE_IPAC_CONN_ID); conn_id = ntohs(conn_id); DEBUGPC(DRSL, "CON_ID=%u ", conn_id); lchan->abis_ip.conn_id = conn_id; @@ -1838,13 +1838,13 @@ static void ipac_parse_rtp(struct gsm_lchan *lchan, struct tlv_parsed *tv) } if (TLVP_PRESENT(tv, RSL_IE_IPAC_REMOTE_IP)) { - ip.s_addr = *((uint32_t *) TLVP_VAL(tv, RSL_IE_IPAC_REMOTE_IP)); + ip.s_addr = tlvp_val32_unal(tv, RSL_IE_IPAC_REMOTE_IP); DEBUGPC(DRSL, "REMOTE_IP=%s ", inet_ntoa(ip)); lchan->abis_ip.connect_ip = ntohl(ip.s_addr); } if (TLVP_PRESENT(tv, RSL_IE_IPAC_REMOTE_PORT)) { - port = *((uint16_t *) TLVP_VAL(tv, RSL_IE_IPAC_REMOTE_PORT)); + port = tlvp_val16_unal(tv, RSL_IE_IPAC_REMOTE_PORT); port = ntohs(port); DEBUGPC(DRSL, "REMOTE_PORT=%u ", port); lchan->abis_ip.connect_port = port; diff --git a/openbsc/src/osmo-bsc/osmo_bsc_bssap.c b/openbsc/src/osmo-bsc/osmo_bsc_bssap.c index c2c2417..f58d96f 100644 --- a/openbsc/src/osmo-bsc/osmo_bsc_bssap.c +++ b/openbsc/src/osmo-bsc/osmo_bsc_bssap.c @@ -135,7 +135,7 @@ static int bssmap_handle_paging(struct osmo_msc_data *msc, if (TLVP_PRESENT(&tp, GSM0808_IE_TMSI) && TLVP_LEN(&tp, GSM0808_IE_TMSI) == 4) { - tmsi = ntohl(*(uint32_t *) TLVP_VAL(&tp, GSM0808_IE_TMSI)); + tmsi = ntohl(tlvp_val32_unal(&tp, GSM0808_IE_TMSI)); } /* diff --git a/openbsc/src/osmo-bsc_nat/bsc_mgcp_utils.c b/openbsc/src/osmo-bsc_nat/bsc_mgcp_utils.c index 22b8a35..e13827b 100644 --- a/openbsc/src/osmo-bsc_nat/bsc_mgcp_utils.c +++ b/openbsc/src/osmo-bsc_nat/bsc_mgcp_utils.c @@ -191,7 +191,7 @@ int bsc_mgcp_assign_patch(struct nat_sccp_connection *con, struct msgb *msg) return -1; } - cic = ntohs(*(uint16_t *)TLVP_VAL(&tp, GSM0808_IE_CIRCUIT_IDENTITY_CODE)); + cic = ntohs(tlvp_val16_unal(&tp, GSM0808_IE_CIRCUIT_IDENTITY_CODE)); timeslot = cic & 0x1f; multiplex = (cic & ~0x1f) >> 5; -- 1.8.4.2

9 years, 10 months

1
2
0 0

new buzzword for HLR

by ☎

Hi all. I recall talks about sqlite-backed HLR being bottleneck and that it should be replaced with something more decent. As far as I recall that idea is not materialized yet so I'd like to bring new db buzz-word I've stumbled upon recently: http://www.aerospike.com/press-releases/aerospike-open-sources-visionary-da… If you remove all the marketing junk it's essentially greatly revamped AlchemyDB with AGPL license for server (various language bindings for client library under apache license), transactions and claim for very-small latencies (approx 5 ms!) which grabbed my attention. It's unlikely that I'll be able to allocate time to work on that ATM but maybe it'll spark interest in someone else :) -- best regards, Max, http://fairwaves.co

9 years, 10 months

2
1
0 0

OpenBSC unsubscribe notification

by mailman-bounces＠lists.osmocom.org

osmocom(a)ninoc.nl has been removed from OpenBSC.

9 years, 10 months

1
0
0 0

osmo-nitb: %This BTS does not support TSC!=BCC

by Erich Dachleger

Hi all, I have followed the the guide in network_from_scratch and use 1 osmocom phone as transceiver. I use the suggested configs for open-bsc.cfg and osmo-bts.cfg and can register to the network I run. However in the output from osmo--nitb ,in the start I get a message about the training sequence: ________________________________________________ % This BTS does not support a TSC!=BCC, Falling back to BCC and after the DB: Database initialized messages DB: Database prepared ---------------------------------- -------------------------------- <0005>bsc.init.c:265 bootstrapping RSL for BTS/TRX(0/0) on ARFCN 533 using MCC=1 MNC=1 LAC=1 CID=0 BSIC=63 TSC 7 ------------------------------------------ <0002> gsm.subscriber.c: 378 Subscriber <imsi> ATTACHED LAC=1 ----------------------------------------------------------------------------------------------------- I have entered hlr.sqlite and assigned an extension to my imsi but when I enter the VTY and execute enable subscriber imsi <imsi> sms send test123 I get: %Unknown command So it appears smsqueue is not enabled. Does anyone know what to look for to enable it? I have tried the vty commands trigger smsqueue but to no avail.. According to the network from scratch wiki sms (and broadcast) should function with one phone where TS0 is served ------------------------------------------------------------------- osmo-bts-trx outputs lines of <0006> scheduler.c 338 ---- chan=SDCC/4(0) --- chan=SACC/4(0) ----- chan=BCCH(0) ---------------------------------------------------------------------------------------------------------- When the firmware is loaded onto the phone I get time on arrival and signal to noise ratio messages: TOA=4 snr=16384 (Thres 2560) freq_err=40 pm=-70 -------------------------------------------------------- So that is grossly exceeding the threshold value. But is that related to not being able to use smsqueue? Regards Erich

9 years, 10 months

1
0
0 0

trau_decode_fr memory corruption. Fix requested

by Holger Hans Peter Freyther

Dear Andreas, Harald, I don't really know much about the bit order of TRAU frames but the trau_test.c is causing an out of bounds access to the gsm_fr_map. Re-produce (GCC >= 3.8 or clang >= 3.2 required): $ make clean && make CFLAGS+="-ggdb3 -Og -fsanitize=address" $ cd tests/trau $ ./trau_test Issue: Breakpoint 1, 0xb69e7810 in __asan_report_error () from /usr/lib/i386-linux-gnu/libasan.so.0 (gdb) bt #0 0xb69e7810 in __asan_report_error () from /usr/lib/i386-linux-gnu/libasan.so.0 #1 0xb69e08cf in __asan_report_load1 () from /usr/lib/i386-linux-gnu/libasan.so.0 #2 0x0804c4e7 in trau_encode_fr (tf=tf@entry=0xbffff530, data=data@entry=0xbffff700 <incomplete sequence \320>) at trau_mux.c:441 #3 0x08048e06 in test_trau_fr_efr (data=<optimized out>, data@entry=0xbffff700 <incomplete sequence \320>) at trau_test.c:35 #4 0x080494bf in main () at trau_test.c:70 (gdb) frame2 Undefined command: "frame2". Try "help". (gdb) frame 2 #2 0x0804c4e7 in trau_encode_fr (tf=tf@entry=0xbffff530, data=data@entry=0xbffff700 <incomplete sequence \320>) at trau_mux.c:441 441 k = gsm_fr_map[++l]-1; (gdb) p l $1 = 76 (gdb) p l $2 = 76 (gdb) p sizeof(gsm_fr_map) $3 = 76 Please fix as soon as possible as I would like to enable ASAN checking on the jenkins as soon as possible. kind regards holger

9 years, 10 months

2
2
0 0

[PATCH 1/2] trau_mux.c: Prevent out-of-bounds read in trau_encode_fr()

by Harald Welte

found by -fsanitize=address the last iteration of the loop, where i == 259 and o == 260. It is read out-of-bounds but the content is never used. --- openbsc/src/libtrau/trau_mux.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/openbsc/src/libtrau/trau_mux.c b/openbsc/src/libtrau/trau_mux.c index fd1895f..4f159e4 100644 --- a/openbsc/src/libtrau/trau_mux.c +++ b/openbsc/src/libtrau/trau_mux.c @@ -436,6 +436,9 @@ void trau_encode_fr(struct decoded_trau_frame *tf, o = 0; /* offset output bits */ while (i < 260) { tf->d_bits[k+o] = (data[j/8] >> (7-(j%8))) & 1; + /* to avoid out-of-bounds access in gsm_fr_map[++l] */ + if (i == 259) + break; if (--k < 0) { o += gsm_fr_map[l]; k = gsm_fr_map[++l]-1; -- 2.0.0 -- - 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)

9 years, 10 months

1
0
0 0

Questions regarding sysmoBTS2050 power management

by Holger Hans Peter Freyther

hi! I would like to have your opinion on the power management of the sysmoBTS2050 hardware in various conditions: Using only a single TRX with 10: We have to disable the second TRX. Would you want to set a different device id in the EEPROM for the sysmoBTS2050 to indicate a single TRX board? If yes we could have nominal power return 40 and something like the sysmobts-mgr could disable the power of the second trx on start? Another option would be to make it configurable inside the bts configuration file. In this case the bts process would need to tell the sysmobts-mgr to switch off the second trx? Reducing power in a dual-bts setup: The current unfinished idea would be that in case the system heats up too much we reduce the transmit power on the first TRX. Is this enough? Is this enough because in the long run we will manage both TRX from the first one? Or shall we handle the heat inside OpenBSC to temporarily reduce the power? This way we would need to send information in case the system returns to an acceptable temperature? holger

9 years, 10 months

2
1
0 0

Bounce action notification

by mailman＠lists.osmocom.org

This is a Mailman mailing list bounce action notice: List: OpenBSC Member: mki(a)mki-consult.de Action: Subscription disabled. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman(a)lists.osmocom.org.

9 years, 10 months

1
0
0 0

Patch: handover check for E1 based BTS

by Sipos Csaba

The function that checks for HO compatibility is wrong for quite some time. Even for E1 based BTSs the function requires RTP proxy to be enabled. The following patch is fixing this, by changing the condition so RTP proxy is only required, when the BTS is an IP based unit: diff --git a/openbsc/src/libbsc/bsc_vty.c b/openbsc/src/libbsc/bsc_vty.c index 6acf0c6..fbf28ec 100644 --- a/openbsc/src/libbsc/bsc_vty.c +++ b/openbsc/src/libbsc/bsc_vty.c @@ -1427,8 +1427,9 @@ DEFUN(cfg_net_handover, cfg_net_handover_cmd, { int enable = atoi(argv[0]); struct gsm_network *gsmnet = gsmnet_from_vty(vty); + struct gsm_bts *bts = vty->index; - if (enable && ipacc_rtp_direct) { + if (enable && ((is_ipaccess_bts(bts)) && ipacc_rtp_direct)) { vty_out(vty, "%% Cannot enable handover unless RTP Proxy mode " "is enabled by using the -P command line option%s", VTY_NEWLINE); The patch is tested with Nokia Insite. I hope someone can commit this to the master branch. Regards, Csaba

9 years, 10 months

1
0
0 0

Unable to build openbsc due to missing 'libosmo-netif' package

by hulds＠gmx.net

Hi, i try to get openbsc to work. To do that i followed the steps on the page : http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS till the last step everything go's ok, during the last step : cd /root/openbsc/openbsc; autoreconf -fi; export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig; ./configure; make I get the message : checking for LIBOSMONETIF... no configure: error: Package requirements (libosmo-netif >= 0.0.1) were not met: No package 'libosmo-netif' found I tried to find this package but was not able to find it. Do you know where i can find this package so that i can get things working ? Regards Henry

9 years, 10 months

2
1
0 0

[PATCH] mgcp/test: Add test case using the fmtp_extra info

by Jacob Erlbeck

Add tests setting the fmtp_extra field to check the response generation. This triggers a bug found by Coverity. Addresses: Coverity CID 1220873 Sponsored-by: On-Waves ehf --- openbsc/tests/mgcp/mgcp_test.c | 31 +++++++++++++++++++++++++++++++ openbsc/tests/mgcp/mgcp_test.ok | 38 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 69 insertions(+) diff --git a/openbsc/tests/mgcp/mgcp_test.c b/openbsc/tests/mgcp/mgcp_test.c index 19615d9..e185fbc 100644 --- a/openbsc/tests/mgcp/mgcp_test.c +++ b/openbsc/tests/mgcp/mgcp_test.c @@ -20,6 +20,7 @@ #define _GNU_SOURCE #include <openbsc/mgcp.h> +#include <openbsc/vty.h> #include <openbsc/mgcp_internal.h> #include <osmocom/core/application.h> @@ -88,6 +89,17 @@ static void test_strline(void) "m=audio 0 RTP/AVP 126\r\n" \ "a=rtpmap:126 AMR/8000\r\n" \ "a=ptime:20\r\n" +#define MDCX3_FMTP_RET "200 18983215 OK\r\n" \ + "I: 3\n" \ + "\n" \ + "v=0\r\n" \ + "o=- 3 23 IN IP4 0.0.0.0\r\n" \ + "c=IN IP4 0.0.0.0\r\n" \ + "t=0 0\r\n" \ + "m=audio 0 RTP/AVP 126\r\n" \ + "a=rtpmap:126 AMR/8000\r\n" \ + "a=fmtp:126 0/1/2\r\n" \ + "a=ptime:20\r\n" #define MDCX4 "MDCX 18983216 1@mgw MGCP 1.0\r\n" \ "M: sendrecv\r" \ "C: 2\r\n" \ @@ -203,6 +215,18 @@ static void test_strline(void) "a=rtpmap:126 AMR/8000\r\n" \ "a=ptime:20\r\n" +#define CRCX_FMTP_RET "200 2 OK\r\n" \ + "I: 3\n" \ + "\n" \ + "v=0\r\n" \ + "o=- 3 23 IN IP4 0.0.0.0\r\n" \ + "c=IN IP4 0.0.0.0\r\n" \ + "t=0 0\r\n" \ + "m=audio 0 RTP/AVP 126\r\n" \ + "a=rtpmap:126 AMR/8000\r\n" \ + "a=fmtp:126 0/1/2\r\n" \ + "a=ptime:20\r\n" + #define CRCX_ZYN "CRCX 2 1@mgw MGCP 1.0\r" \ "M: recvonly\r" \ "C: 2\r\r" \ @@ -250,6 +274,8 @@ struct mgcp_test { const char *exp_resp; int exp_net_ptype; int exp_bts_ptype; + + char *extra_fmtp; }; static const struct mgcp_test tests[] = { @@ -275,6 +301,9 @@ static const struct mgcp_test tests[] = { { "RQNT1", RQNT, RQNT1_RET }, { "RQNT2", RQNT2, RQNT2_RET }, { "DLCX", DLCX, DLCX_RET, -1, -1 }, + { "CRCX", CRCX, CRCX_FMTP_RET, 97, 126, .extra_fmtp = "a=fmtp:126 0/1/2" }, + { "MDCX3", MDCX3, MDCX3_FMTP_RET, PTYPE_NONE, 126 , .extra_fmtp = "a=fmtp:126 0/1/2" }, + { "DLCX", DLCX, DLCX_RET, -1, -1 , .extra_fmtp = "a=fmtp:126 0/1/2" }, }; static const struct mgcp_test retransmit[] = { @@ -398,6 +427,8 @@ static void test_messages(void) last_endpoint = -1; dummy_packets = 0; + bsc_replace_string(cfg, &cfg->trunk.audio_fmtp_extra, t->extra_fmtp); + inp = create_msg(t->req); msg = mgcp_handle_message(cfg, inp); msgb_free(inp); diff --git a/openbsc/tests/mgcp/mgcp_test.ok b/openbsc/tests/mgcp/mgcp_test.ok index 7301a81..6c5a6bc 100644 --- a/openbsc/tests/mgcp/mgcp_test.ok +++ b/openbsc/tests/mgcp/mgcp_test.ok @@ -75,6 +75,44 @@ Detected packet duration: 20 Requested packetization period not set Connection mode: 0: NONE Testing CRCX +CRCX failed '200 2 OK +I: 3 + +v=0 +o=- 3 23 IN IP4 0.0.0.0 +c=IN IP4 0.0.0.0 +t=0 0 +m=audio 0 RTP/AVP 126 +a=rtpmap:126 AMR/8000 +a=rtpmap:126 AMR/8000 +a=ptime:20 +' +Dummy packets: 1 +Detected packet duration: 40 +Requested packetetization period: 20-20 +Connection mode: 1: RECV +Testing MDCX3 +MDCX3 failed '200 18983215 OK +I: 3 + +v=0 +o=- 3 23 IN IP4 0.0.0.0 +c=IN IP4 0.0.0.0 +t=0 0 +m=audio 0 RTP/AVP 126 +a=rtpmap:126 AMR/8000 +a=rtpmap:126 AMR/8000 +a=ptime:20 +' +Dummy packets: 1 +Packet duration not set +Requested packetization period not set +Connection mode not set +Testing DLCX +Detected packet duration: 20 +Requested packetization period not set +Connection mode: 0: NONE +Testing CRCX Re-transmitting CRCX Testing RQNT1 Re-transmitting RQNT1 -- 1.9.1

9 years, 10 months

2
1
0 0

XID parameters

by Josh toal

Hi All As per the specs after PDP context accept mobile station should exchange XID parameters with SGSN. before it initiate transfer of data. As per the literature mobile station if not happy with the negotiated quality of service it will send the deactivation request and I am getting the same. Is this is the only reason mobile station will send deactivation request or something else, which I am missing. Any suggestion to fix this problem. can anybody comment on this please. regards Josh

9 years, 10 months

2
2
0 0

[PATCH] mgcp: Fix SDP formatting of fmtp_extra (Coverity)

by Jacob Erlbeck

Currently when ftmp_extra is set, a doubled a=rtpmap line is emitted instead of the fmtp_extra info. This patch fixes replaces the formerly copied and pasted but not modified snprintf parameters by the correct ones. Fixes: Coverity CID 1220873 Sponsored-by: On-Waves ehf --- openbsc/src/libmgcp/mgcp_protocol.c | 3 +-- openbsc/tests/mgcp/mgcp_test.ok | 24 ------------------------ 2 files changed, 1 insertion(+), 26 deletions(-) diff --git a/openbsc/src/libmgcp/mgcp_protocol.c b/openbsc/src/libmgcp/mgcp_protocol.c index f0457d1..6e48949 100644 --- a/openbsc/src/libmgcp/mgcp_protocol.c +++ b/openbsc/src/libmgcp/mgcp_protocol.c @@ -287,8 +287,7 @@ static int write_response_sdp(struct mgcp_endpoint *endp, if (fmtp_extra) { nchars = snprintf(sdp_record + len, size - len, - "a=rtpmap:%d %s\r\n", - payload_type, audio_name); + "%s\r\n", fmtp_extra); if (nchars < 0 || nchars >= size - len) goto buffer_too_small; diff --git a/openbsc/tests/mgcp/mgcp_test.ok b/openbsc/tests/mgcp/mgcp_test.ok index 6c5a6bc..033f783 100644 --- a/openbsc/tests/mgcp/mgcp_test.ok +++ b/openbsc/tests/mgcp/mgcp_test.ok @@ -75,35 +75,11 @@ Detected packet duration: 20 Requested packetization period not set Connection mode: 0: NONE Testing CRCX -CRCX failed '200 2 OK -I: 3 - -v=0 -o=- 3 23 IN IP4 0.0.0.0 -c=IN IP4 0.0.0.0 -t=0 0 -m=audio 0 RTP/AVP 126 -a=rtpmap:126 AMR/8000 -a=rtpmap:126 AMR/8000 -a=ptime:20 -' Dummy packets: 1 Detected packet duration: 40 Requested packetetization period: 20-20 Connection mode: 1: RECV Testing MDCX3 -MDCX3 failed '200 18983215 OK -I: 3 - -v=0 -o=- 3 23 IN IP4 0.0.0.0 -c=IN IP4 0.0.0.0 -t=0 0 -m=audio 0 RTP/AVP 126 -a=rtpmap:126 AMR/8000 -a=rtpmap:126 AMR/8000 -a=ptime:20 -' Dummy packets: 1 Packet duration not set Requested packetization period not set -- 1.9.1

9 years, 10 months

1
0
0 0

[PATCH 1/2] write_queue: Avoid possible use-after-free if fd is read-/writable

by Daniel Willmann

If the FD is both readable and writable and the read callback closes the connection (and frees the surrounding structure) we shouldn't call the write callback (or check anything else in the read fd). With this patch callback functions can return -EBADFD if they don't want the FD to be handled any more. --- src/write_queue.c | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git a/src/write_queue.c b/src/write_queue.c index cef40f8..d17493d 100644 --- a/src/write_queue.c +++ b/src/write_queue.c @@ -21,8 +21,15 @@ * */ +#include <errno.h> #include <osmocom/core/write_queue.h> +#define HANDLE_BAD_FD(rc, label) \ + do { \ + if (rc == -EBADFD) \ + goto label; \ + } while (0); + /*! \addtogroup write_queue * @{ */ @@ -39,14 +46,19 @@ int osmo_wqueue_bfd_cb(struct osmo_fd *fd, unsigned int what) { struct osmo_wqueue *queue; + int rc; queue = container_of(fd, struct osmo_wqueue, bfd); - if (what & BSC_FD_READ) - queue->read_cb(fd); + if (what & BSC_FD_READ) { + rc = queue->read_cb(fd); + HANDLE_BAD_FD(rc, err_badfd); + } - if (what & BSC_FD_EXCEPT) - queue->except_cb(fd); + if (what & BSC_FD_EXCEPT) { + rc = queue->except_cb(fd); + HANDLE_BAD_FD(rc, err_badfd); + } if (what & BSC_FD_WRITE) { struct msgb *msg; @@ -58,16 +70,21 @@ int osmo_wqueue_bfd_cb(struct osmo_fd *fd, unsigned int what) --queue->current_length; msg = msgb_dequeue(&queue->msg_queue); - queue->write_cb(fd, msg); + rc = queue->write_cb(fd, msg); msgb_free(msg); + HANDLE_BAD_FD(rc, err_badfd); + if (!llist_empty(&queue->msg_queue)) fd->when |= BSC_FD_WRITE; } } return 0; +err_badfd: + return rc; } +#undef HANDLE_BAD_FD /*! \brief Initialize a \ref osmo_wqueue structure * \param[in] queue Write queue to operate on -- 1.8.4.2

9 years, 10 months

4
6
0 0

[osmo-pcu 1/1] bts: Remove outdated comment

by Daniel Willmann

There is no parameter in the function and the bts has a memeber trx which has a member pdch. Sponsored-by: On-Waves ehf --- src/bts.cpp | 1 - 1 file changed, 1 deletion(-) diff --git a/src/bts.cpp b/src/bts.cpp index 9de6dc3..3dd5705 100644 --- a/src/bts.cpp +++ b/src/bts.cpp @@ -532,7 +532,6 @@ void gprs_rlcmac_pdch::disable() m_is_enabled = 0; } -/* TODO: kill the parameter and make a pdch belong to a trx.. to a bts.. */ void gprs_rlcmac_pdch::free_resources() { struct gprs_rlcmac_paging *pag; -- 1.8.4.2

9 years, 10 months

1
0
0 0

[osmo-pcu 1/1] Always exit and don't try to recover

by Daniel Willmann

From: Daniel Willmann <dwillmann(a)sysmocom.de> The current code tries to recover from dropped connections and resets the pcu state so it can keep running. However, this never worked correctly which is why the -e option is used. This option exits the pcu as soon as the internal state needs to be reset. This patch removes this option and makes this behaviour default. Ticket: SYS#390 Sponsored-by: On-Waves ehf --- src/gprs_bssgp_pcu.cpp | 13 +------------ src/gprs_bssgp_pcu.h | 4 +--- src/openbts_sock.cpp | 4 +++- src/pcu_l1_if.cpp | 4 ++-- src/pcu_main.cpp | 3 +-- src/sysmo_sock.cpp | 8 ++------ 6 files changed, 10 insertions(+), 26 deletions(-) diff --git a/src/gprs_bssgp_pcu.cpp b/src/gprs_bssgp_pcu.cpp index 133eb97..6c5d72c 100644 --- a/src/gprs_bssgp_pcu.cpp +++ b/src/gprs_bssgp_pcu.cpp @@ -533,13 +533,8 @@ struct gprs_bssgp_pcu *gprs_bssgp_create_and_connect(struct gprs_rlcmac_bts *bts return &the_pcu; } -void gprs_bssgp_destroy_or_exit(void) +void gprs_bssgp_destroy(void) { - if (the_pcu.exit_on_destroy) { - LOGP(DBSSGP, LOGL_NOTICE, "Exiting on BSSGP destruction.\n"); - exit(0); - } - if (!bssgp_nsi) return; @@ -564,12 +559,6 @@ void gprs_bssgp_destroy_or_exit(void) bssgp_nsi = NULL; } -void gprs_bssgp_exit_on_destroy(void) -{ - LOGP(DBSSGP, LOGL_NOTICE, "Going to quit on BSSGP destruction\n"); - the_pcu.exit_on_destroy = 1; -} - struct bssgp_bvc_ctx *gprs_bssgp_pcu_current_bctx(void) { return the_pcu.bctx; diff --git a/src/gprs_bssgp_pcu.h b/src/gprs_bssgp_pcu.h index aedcfc0..32b6728 100644 --- a/src/gprs_bssgp_pcu.h +++ b/src/gprs_bssgp_pcu.h @@ -57,7 +57,6 @@ struct gprs_bssgp_pcu { int bvc_sig_reset; int bvc_reset; int bvc_unblocked; - int exit_on_destroy; /** callbacks below */ @@ -75,8 +74,7 @@ struct gprs_bssgp_pcu *gprs_bssgp_create_and_connect(struct gprs_rlcmac_bts *bts uint16_t nsvci, uint16_t bvci, uint16_t mcc, uint16_t mnc, uint16_t lac, uint16_t rac, uint16_t cell_id); -void gprs_bssgp_exit_on_destroy(void); -void gprs_bssgp_destroy_or_exit(void); +void gprs_bssgp_destroy(void); struct bssgp_bvc_ctx *gprs_bssgp_pcu_current_bctx(void); diff --git a/src/openbts_sock.cpp b/src/openbts_sock.cpp index a09f834..2d9cae4 100644 --- a/src/openbts_sock.cpp +++ b/src/openbts_sock.cpp @@ -179,8 +179,10 @@ int pcu_l1if_open() void pcu_l1if_close(void) { - gprs_bssgp_destroy_or_exit(); + gprs_bssgp_destroy(); /* FIXME: cleanup l1if */ talloc_free(l1fh->fl1h); + + exit(0); } diff --git a/src/pcu_l1_if.cpp b/src/pcu_l1_if.cpp index ce13b96..0cb79eb 100644 --- a/src/pcu_l1_if.cpp +++ b/src/pcu_l1_if.cpp @@ -324,8 +324,8 @@ bssgp_failed: for (ts = 0; ts < 8; ts++) bts->trx[trx].pdch[ts].free_resources(); } - gprs_bssgp_destroy_or_exit(); - return 0; + gprs_bssgp_destroy(); + exit(0); } LOGP(DL1IF, LOGL_INFO, "BTS available\n"); LOGP(DL1IF, LOGL_DEBUG, " mcc=%x\n", info_ind->mcc); diff --git a/src/pcu_main.cpp b/src/pcu_main.cpp index c0dac14..8631ad3 100644 --- a/src/pcu_main.cpp +++ b/src/pcu_main.cpp @@ -56,7 +56,6 @@ static void print_help() "provided by BTS\n" " -r --realtime PRIO Use SCHED_RR with the specified " "priority\n" - " -e --exit Exit the application on disconnect\n" ); } @@ -105,7 +104,7 @@ static void handle_options(int argc, char **argv) rt_prio = atoi(optarg); break; case 'e': - gprs_bssgp_exit_on_destroy(); + fprintf(stderr, "Warning: Option '-e' is deprecated!\n"); break; default: fprintf(stderr, "Unknown option '%c'\n", c); diff --git a/src/sysmo_sock.cpp b/src/sysmo_sock.cpp index 2e2d9d3..951653e 100644 --- a/src/sysmo_sock.cpp +++ b/src/sysmo_sock.cpp @@ -112,12 +112,8 @@ static void pcu_sock_close(struct pcu_sock_state *state, int lost) gprs_rlcmac_tbf::free_all(&bts->trx[trx]); } - gprs_bssgp_destroy_or_exit(); - - if (lost) { - state->timer.cb = pcu_sock_timeout; - osmo_timer_schedule(&state->timer, 5, 0); - } + gprs_bssgp_destroy(); + exit(0); } static int pcu_sock_read(struct osmo_fd *bfd) -- 1.8.4.2

9 years, 10 months

1
0
0 0

[osmo-pcu 1/1] csn1: Add spaces between string literal and identifier

by Daniel Willmann

This is required by C++11 csn1.cpp:1147:44: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal] LOGPC(DCSN1, LOGL_NOTICE, "%"PRIu64"|", bitvec_read_field(vector, readIndex, bits_to_handle)); --- src/csn1.cpp | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/csn1.cpp b/src/csn1.cpp index 258f7c9..377c50f 100644 --- a/src/csn1.cpp +++ b/src/csn1.cpp @@ -1144,13 +1144,13 @@ csnStreamDecoder(csnStream_t* ar, const CSN_DESCR* pDescr, bitvec *vector, unsig guint8 bits_to_handle = remaining_bits_len%8; if (bits_to_handle > 0) { - LOGPC(DCSN1, LOGL_NOTICE, "%"PRIu64"|", bitvec_read_field(vector, readIndex, bits_to_handle)); + LOGPC(DCSN1, LOGL_NOTICE, "%" PRIu64 "|", bitvec_read_field(vector, readIndex, bits_to_handle)); remaining_bits_len -= bits_to_handle; bit_offset += bits_to_handle; } else if (bits_to_handle == 0) { - LOGPC(DCSN1, LOGL_NOTICE, "%"PRIu64"|", bitvec_read_field(vector, readIndex, 8)); + LOGPC(DCSN1, LOGL_NOTICE, "%" PRIu64 "|", bitvec_read_field(vector, readIndex, 8)); remaining_bits_len -= 8; bit_offset += 8; } -- 1.8.4.2

9 years, 10 months

1
0
0 0

Bounce action notification

by mailman＠lists.osmocom.org

This is a Mailman mailing list bounce action notice: List: OpenBSC Member: osmocom(a)ninoc.nl Action: Subscription disabled. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman(a)lists.osmocom.org.

9 years, 10 months

1
0
0 0

[osmo-pcu 1/2] gprs_rlcmac_pdch: Don't access private member structs

by Daniel Willmann

This patch introduces methods to get ul and dl tbf by tfi and uses them in gprs_rlcmac_sched. --- src/bts.cpp | 14 ++++++++++++++ src/bts.h | 3 +++ src/gprs_rlcmac_sched.cpp | 4 ++-- 3 files changed, 19 insertions(+), 2 deletions(-) diff --git a/src/bts.cpp b/src/bts.cpp index 9003099..b383546 100644 --- a/src/bts.cpp +++ b/src/bts.cpp @@ -990,3 +990,17 @@ int gprs_rlcmac_pdch::rcv_block(uint8_t *data, uint8_t len, uint32_t fn, int8_t return rc; } + +struct gprs_rlcmac_tbf *gprs_rlcmac_pdch::ul_tbf_by_tfi(uint8_t tfi) +{ + if (tfi >= ARRAY_SIZE(this->ul_tbf)) + return NULL; + return this->ul_tbf[tfi]; +} + +struct gprs_rlcmac_tbf *gprs_rlcmac_pdch::dl_tbf_by_tfi(uint8_t tfi) +{ + if (tfi >= ARRAY_SIZE(this->dl_tbf)) + return NULL; + return this->dl_tbf[tfi]; +} diff --git a/src/bts.h b/src/bts.h index 128b1e0..578c63d 100644 --- a/src/bts.h +++ b/src/bts.h @@ -61,6 +61,9 @@ struct gprs_rlcmac_pdch { gprs_rlcmac_bts *bts_data() const; BTS *bts() const; uint8_t trx_no() const; + + struct gprs_rlcmac_tbf *ul_tbf_by_tfi(uint8_t tfi); + struct gprs_rlcmac_tbf *dl_tbf_by_tfi(uint8_t tfi); #endif uint8_t m_is_enabled; /* TS is enabled */ diff --git a/src/gprs_rlcmac_sched.cpp b/src/gprs_rlcmac_sched.cpp index 123e375..92e97ec 100644 --- a/src/gprs_rlcmac_sched.cpp +++ b/src/gprs_rlcmac_sched.cpp @@ -81,7 +81,7 @@ static uint8_t sched_select_uplink(uint8_t trx, uint8_t ts, uint32_t fn, /* select uplink resource */ for (i = 0, tfi = pdch->next_ul_tfi; i < 32; i++, tfi = (tfi + 1) & 31) { - tbf = pdch->ul_tbf[tfi]; + tbf = pdch->ul_tbf_by_tfi(tfi); /* no TBF for this tfi, go next */ if (!tbf) continue; @@ -169,7 +169,7 @@ static struct msgb *sched_select_downlink(struct gprs_rlcmac_bts *bts, /* select downlink resource */ for (i = 0, tfi = pdch->next_dl_tfi; i < 32; i++, tfi = (tfi + 1) & 31) { - tbf = pdch->dl_tbf[tfi]; + tbf = pdch->dl_tbf_by_tfi(tfi); /* no TBF for this tfi, go next */ if (!tbf) continue; -- 1.8.4.2

9 years, 10 months

1
1
0 0

routing area reject and pdp deactivation

by Josh toal

Hi All there was typo in my earlier post therefore posting again--sorry! for that in my sgsn log I am getting <0002> gprs_gmm.c:921 -> GMM RA UPDATE REQUEST type="RA updating" LLC XID RESET REJECT <0002> gprs_gmm.c:860 <- ROUTING AREA UPDATE REJECT then <0002> gprs_gmm.c:640 -> GMM ATTACH REQUEST MI(xxxxxxx) type="GPRS attach" <0002> gprs_gmm.c:444 <- GPRS IDENTITY REQUEST: mi_type=02 <0011> gprs_bssgp.c:753 BSSGP BVCI=2 Rx Flow Control BVC <0011> gprs_bssgp.c:376 BSSGP TLLI=0xxxxxx Rx UPLINK-UNITDATA <0012> gprs_llc.c:554 LLC SAPI=1 C FCS=0xxxxx=UI DATA <0002> gprs_gmm.c:582 -> GMM IDENTITY RESPONSE: mi_type=0x02 MI(xxxxxxxxx) <0002> gprs_gmm.c:352 <- GPRS ATTACH ACCEPT (new P-TMSI=0xxxxxxx) <0011> gprs_bssgp.c:376 BSSGP TLLI=0xxxxxx Rx UPLINK-UNITDATA <0012> gprs_llc.c:554 LLC SAPI=1 C FCS=0xxxxxxxx=UI DATA <0002> gprs_gmm.c:1052 -> ATTACH COMPLETE and then <0002> gprs_gmm.c:1319 -> ACTIVATE PDP CONTEXT REQ: SAPI=3 NSAPI=5 IETF IPv4 <000f> sgsn_libgtp.c:126 Create PDP Context <000f> sgsn_libgtp.c:379 libgtp cb_conf(type=16, cause=128, pdp=0xxxxxxx, cbp=0x1xxxxx) <000f> sgsn_libgtp.c:265 Received CREATE PDP CTX CONF, cause=128(Request accepted) <0002> gprs_gmm.c:1197 <- ACTIVATE PDP CONTEXT ACK finally <0002> gprs_gmm.c:1432 -> DEACTIVATE PDP CONTEXT REQ (cause: Regular deactivation) <000f> sgsn_libgtp.c:212 Delete PDP Context <000f> sgsn_libgtp.c:402 PDP Context was deleted <000f> sgsn_libgtp.c:379 libgtp cb_conf(type=20, cause=128, pdp=(nil), cbp=0xxxxxx) <000f> sgsn_libgtp.c:321 Received DELETE PDP CTX CONF, cause=128(Request accepted) <0002> gprs_gmm.c:1290 <- DEACTIVATE PDP CONTEXT ACK Am I getting PDP deactivation because of routing area reject. Also noticed that TLLI changes from Activate PDP context onwards. This TLLI is based on TMSI/P-TMSI Upto Attach complete procedure I have different TLLI. For setup I have BSC, SGSN on eth0 and eth0:1 respectively and GGSN on eth1 ( I have external network adapter). Can anybody suggest something why I am getting pdp deactivation. regards Josh

9 years, 10 months

1
0
0 0

routing area reject and pdp deactivation

by Josh toal

Hi All in my sgsn log I am getting <0002> gprs_gmm.c:921 -> GMM RA UPDATE REQUEST type="RA updating" LLC XID RESET REJECT <0002> gprs_gmm.c:860 <- ROUTING AREA UPDATE REJECT then <0002> gprs_gmm.c:640 -> GMM ATTACH REQUEST MI(xxxxxxx) type="GPRS attach" <0002> gprs_gmm.c:444 <- GPRS IDENTITY REQUEST: mi_type=02 <0011> gprs_bssgp.c:753 BSSGP BVCI=2 Rx Flow Control BVC <0011> gprs_bssgp.c:376 BSSGP TLLI=0xxxxxx Rx UPLINK-UNITDATA <0012> gprs_llc.c:554 LLC SAPI=1 C FCS=0xxxxx=UI DATA <0002> gprs_gmm.c:582 -> GMM IDENTITY RESPONSE: mi_type=0x02 MI(xxxxxxxxx) <0002> gprs_gmm.c:352 <- GPRS ATTACH ACCEPT (new P-TMSI=0xxxxxxx) <0011> gprs_bssgp.c:376 BSSGP TLLI=0xxxxxx Rx UPLINK-UNITDATA <0012> gprs_llc.c:554 LLC SAPI=1 C FCS=0xxxxxxxx=UI DATA <0002> gprs_gmm.c:1052 -> ATTACH COMPLETE and then <0002> gprs_gmm.c:1319 -> ACTIVATE PDP CONTEXT REQ: SAPI=3 NSAPI=5 IETF IPv4 <000f> sgsn_libgtp.c:126 Create PDP Context <000f> sgsn_libgtp.c:379 libgtp cb_conf(type=16, cause=128, pdp=0xxxxxxx, cbp=0x1xxxxx) <000f> sgsn_libgtp.c:265 Received CREATE PDP CTX CONF, cause=128(Request accepted) <0002> gprs_gmm.c:1197 <- ACTIVATE PDP CONTEXT ACK finally <0002> gprs_gmm.c:1432 -> DEACTIVATE PDP CONTEXT REQ (cause: Regular deactivation) <000f> sgsn_libgtp.c:212 Delete PDP Context <000f> sgsn_libgtp.c:402 PDP Context was deleted <000f> sgsn_libgtp.c:379 libgtp cb_conf(type=20, cause=128, pdp=(nil), cbp=0xxxxxx) <000f> sgsn_libgtp.c:321 Received DELETE PDP CTX CONF, cause=128(Request accepted) <0002> gprs_gmm.c:1290 <- DEACTIVATE PDP CONTEXT ACK Am I getting PDP deactivation because of routing area reject. Also noticed that TLLI changes from Activate PDP context. This TLLI is based on TMSI/P-TMSI Upto Attach complete procedure I have different TLLI. For setup I have BSC, SGSN on eth0 and eth0:1 respectively and GGSN on eth1 ( I have external network adapter). Can anybody suggest something why I am not getting pdp deactivation. regards Josh

9 years, 10 months

1
0
0 0

[PATCH 1/3] gprs/test: Use valid MCC/MNC for BVC RESET

by Jacob Erlbeck

The code currently uses an encoded sequence of (hex) 10 20 30 40 50 60 as RAI, for which no bijective mapping to the set of representations MCC-MNC-LAC-RAC exists. This patch changes the hard-coded RAI to 11 22 33 40 50 60 which maps to 112-332-16464-96 (and vice-versa). Sponsored-by: On-Waves ehf --- openbsc/tests/gbproxy/gbproxy_test.c | 4 +- openbsc/tests/gbproxy/gbproxy_test.ok | 216 ++++++++++++++++----------------- 2 files changed, 110 insertions(+), 110 deletions(-) diff --git a/openbsc/tests/gbproxy/gbproxy_test.c b/openbsc/tests/gbproxy/gbproxy_test.c index d32ac83..ea07a77 100644 --- a/openbsc/tests/gbproxy/gbproxy_test.c +++ b/openbsc/tests/gbproxy/gbproxy_test.c @@ -142,8 +142,8 @@ static void send_bssgp_reset(struct gprs_ns_inst *nsi, struct sockaddr_in *src_a * BSSGP RESET */ unsigned char msg[22] = { 0x22, 0x04, 0x82, 0x4a, - 0x2e, 0x07, 0x81, 0x08, 0x08, 0x88, 0x10, 0x20, - 0x30, 0x40, 0x50, 0x60, 0x10, 0x00 + 0x2e, 0x07, 0x81, 0x08, 0x08, 0x88, 0x11, 0x22, + 0x33, 0x40, 0x50, 0x60, 0x10, 0x00 }; msg[3] = bvci / 256; diff --git a/openbsc/tests/gbproxy/gbproxy_test.ok b/openbsc/tests/gbproxy/gbproxy_test.ok index 0942ca3..e677ec0 100644 --- a/openbsc/tests/gbproxy/gbproxy_test.ok +++ b/openbsc/tests/gbproxy/gbproxy_test.ok @@ -82,16 +82,16 @@ result (ALIVE_ACK) = 0 Setup BSSGP: remote 0x01020304:1111, BVCI 0x1002(4098) PROCESSING BVC_RESET from 0x01020304:1111 -00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 CALLBACK, event 0, msg length 22, bvci 0x0000 -22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22 -22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 MESSAGE to SGSN at 0x05060708:32000, msg length 26 -00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 result (BVC_RESET) = 26 @@ -101,7 +101,7 @@ Current NS-VCIs: NS-VC Block count : 1 Peers: - NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96 PROCESSING BVC_RESET_ACK from 0x05060708:32000 00 00 00 00 23 04 82 10 02 @@ -159,16 +159,16 @@ result (ALIVE_ACK) = 0 Setup BSSGP: remote 0x01020304:2222, BVCI 0x2002(8194) PROCESSING BVC_RESET from 0x01020304:2222 -00 00 00 00 22 04 82 20 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 20 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 CALLBACK, event 0, msg length 22, bvci 0x0000 -22 04 82 20 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 20 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22 -22 04 82 20 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 20 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 MESSAGE to SGSN at 0x05060708:32000, msg length 26 -00 00 00 00 22 04 82 20 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 20 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 result (BVC_RESET) = 26 @@ -179,8 +179,8 @@ Current NS-VCIs: NS-VC Block count : 1 Peers: - NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96 - NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96 + NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96 PROCESSING BVC_RESET_ACK from 0x05060708:32000 00 00 00 00 23 04 82 20 02 @@ -242,8 +242,8 @@ Current NS-VCIs: NS-VC Block count : 1 Peers: - NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96 - NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96 + NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96 --- Move BSS 2 to former BSS 1 port --- Setup NS-VC: remote 0x01020304:1111, NSVCI 0x2001(8193), NSEI 0x2000(8192) @@ -291,8 +291,8 @@ Current NS-VCIs: NS-VC Block count : 1 Peers: - NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96 - NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96 + NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96 --- Move BSS 1 to current BSS 2 port --- Setup NS-VC: remote 0x01020304:1111, NSVCI 0x2001(8193), NSEI 0x2000(8192) @@ -340,8 +340,8 @@ Current NS-VCIs: NS-VC Block count : 1 Peers: - NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96 - NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96 + NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96 --- Move BSS 2 to new port --- Setup NS-VC: remote 0x01020304:4444, NSVCI 0x2001(8193), NSEI 0x2000(8192) @@ -389,8 +389,8 @@ Current NS-VCIs: NS-VC Block count : 1 Peers: - NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96 - NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96 + NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96 --- Move BSS 2 to former BSS 1 port --- Setup NS-VC: remote 0x01020304:3333, NSVCI 0x2001(8193), NSEI 0x2000(8192) @@ -441,8 +441,8 @@ Current NS-VCIs: NS-VC Block count : 1 Peers: - NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96 - NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96 + NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96 --- Move BSS 1 to original BSS 1 port --- Setup NS-VC: remote 0x01020304:1111, NSVCI 0x1001(4097), NSEI 0x1000(4096) @@ -491,23 +491,23 @@ Current NS-VCIs: NS-VC Block count : 1 Peers: - NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96 - NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96 + NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96 --- Reset BSS 1 with a new BVCI --- Setup BSSGP: remote 0x01020304:1111, BVCI 0x1012(4114) PROCESSING BVC_RESET from 0x01020304:1111 -00 00 00 00 22 04 82 10 12 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 10 12 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 CALLBACK, event 0, msg length 22, bvci 0x0000 -22 04 82 10 12 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 10 12 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22 -22 04 82 10 12 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 10 12 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 MESSAGE to SGSN at 0x05060708:32000, msg length 26 -00 00 00 00 22 04 82 10 12 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 10 12 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 result (BVC_RESET) = 26 @@ -519,9 +519,9 @@ Current NS-VCIs: NS-VC Block count : 1 Peers: - NSEI 4096, BVCI 4114, not blocked, RAC 10-32-16464-96 - NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96 - NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 4096, BVCI 4114, not blocked, RAC 112-332-16464-96 + NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96 + NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96 PROCESSING BVC_RESET_ACK from 0x05060708:32000 00 00 00 00 23 04 82 10 12 @@ -541,16 +541,16 @@ result (BVC_RESET_ACK) = 9 Setup BSSGP: remote 0x01020304:1111, BVCI 0x1002(4098) PROCESSING BVC_RESET from 0x01020304:1111 -00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 CALLBACK, event 0, msg length 22, bvci 0x0000 -22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22 -22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 MESSAGE to SGSN at 0x05060708:32000, msg length 26 -00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 result (BVC_RESET) = 26 @@ -562,9 +562,9 @@ Current NS-VCIs: NS-VC Block count : 1 Peers: - NSEI 4096, BVCI 4114, not blocked, RAC 10-32-16464-96 - NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96 - NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 4096, BVCI 4114, not blocked, RAC 112-332-16464-96 + NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96 + NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96 PROCESSING BVC_RESET_ACK from 0x05060708:32000 00 00 00 00 23 04 82 10 02 @@ -584,16 +584,16 @@ result (BVC_RESET_ACK) = 9 Setup BSSGP: remote 0x01020304:1111, BVCI 0x1002(4098) PROCESSING BVC_RESET from 0x01020304:1111 -00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 CALLBACK, event 0, msg length 22, bvci 0x0000 -22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22 -22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 MESSAGE to SGSN at 0x05060708:32000, msg length 26 -00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 result (BVC_RESET) = 26 @@ -605,9 +605,9 @@ Current NS-VCIs: NS-VC Block count : 1 Peers: - NSEI 4096, BVCI 4114, not blocked, RAC 10-32-16464-96 - NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96 - NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 4096, BVCI 4114, not blocked, RAC 112-332-16464-96 + NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96 + NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96 PROCESSING BVC_RESET_ACK from 0x05060708:32000 00 00 00 00 23 04 82 10 02 @@ -723,16 +723,16 @@ result (UNITDATA) = 4 Setup BSSGP: remote 0x01020304:3333, BVCI 0x1002(4098) PROCESSING BVC_RESET from 0x01020304:3333 -00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 CALLBACK, event 0, msg length 22, bvci 0x0000 -22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22 -22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 MESSAGE to SGSN at 0x05060708:32000, msg length 26 -00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 result (BVC_RESET) = 26 @@ -744,10 +744,10 @@ Current NS-VCIs: NS-VC Block count : 1 Peers: - NSEI 4096, BVCI 4114, not blocked, RAC 10-32-16464-96 - NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96 + NSEI 4096, BVCI 4114, not blocked, RAC 112-332-16464-96 + NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96 NSEI mismatch : 1 - NSEI 8192, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96 NSEI mismatch : 1 Gbproxy global: PROCESSING BVC_RESET_ACK from 0x05060708:32000 @@ -904,16 +904,16 @@ Current NS-VCIs: Setup BSSGP: remote 0x01020304:1111, BVCI 0x1002(4098) PROCESSING BVC_RESET from 0x01020304:1111 -00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 CALLBACK, event 0, msg length 22, bvci 0x0000 -22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22 -22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 MESSAGE to SGSN at 0x05060708:32000, msg length 26 -00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 result (BVC_RESET) = 26 @@ -932,22 +932,22 @@ MESSAGE to BSS at 0x01020304:1111, msg length 9 result (BVC_RESET_ACK) = 9 Peers: - NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96 --- Setup BVCI 2 --- Setup BSSGP: remote 0x01020304:1111, BVCI 0x2002(8194) PROCESSING BVC_RESET from 0x01020304:1111 -00 00 00 00 22 04 82 20 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 20 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 CALLBACK, event 0, msg length 22, bvci 0x0000 -22 04 82 20 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 20 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22 -22 04 82 20 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 20 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 MESSAGE to SGSN at 0x05060708:32000, msg length 26 -00 00 00 00 22 04 82 20 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 20 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 result (BVC_RESET) = 26 @@ -966,8 +966,8 @@ MESSAGE to BSS at 0x01020304:1111, msg length 9 result (BVC_RESET_ACK) = 9 Peers: - NSEI 4096, BVCI 8194, not blocked, RAC 10-32-16464-96 - NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96 + NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96 --- Send message from BSS 1 to SGSN and back, BVCI 1 --- PROCESSING UNITDATA from 0x01020304:1111 @@ -1079,16 +1079,16 @@ Current NS-VCIs: Setup BSSGP: remote 0x01020304:1111, BVCI 0x1002(4098) PROCESSING BVC_RESET from 0x01020304:1111 -00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 CALLBACK, event 0, msg length 22, bvci 0x0000 -22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22 -22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 MESSAGE to SGSN at 0x05060708:32000, msg length 26 -00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 result (BVC_RESET) = 26 @@ -1107,24 +1107,24 @@ MESSAGE to BSS at 0x01020304:1111, msg length 9 result (BVC_RESET_ACK) = 9 Peers: - NSEI 4096, BVCI 8194, not blocked, RAC 10-32-16464-96 - NSEI 8192, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96 + NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96 NSEI mismatch : 1 --- Setup BVCI 3 --- Setup BSSGP: remote 0x01020304:1111, BVCI 0x3002(12290) PROCESSING BVC_RESET from 0x01020304:1111 -00 00 00 00 22 04 82 30 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 30 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 CALLBACK, event 0, msg length 22, bvci 0x0000 -22 04 82 30 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 30 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22 -22 04 82 30 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 30 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 MESSAGE to SGSN at 0x05060708:32000, msg length 26 -00 00 00 00 22 04 82 30 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 30 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 result (BVC_RESET) = 26 @@ -1143,9 +1143,9 @@ MESSAGE to BSS at 0x01020304:1111, msg length 9 result (BVC_RESET_ACK) = 9 Peers: - NSEI 8192, BVCI 12290, not blocked, RAC 10-32-16464-96 - NSEI 4096, BVCI 8194, not blocked, RAC 10-32-16464-96 - NSEI 8192, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96 + NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96 + NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96 NSEI mismatch : 1 --- Send message from BSS 1 to SGSN and back, BVCI 1 --- @@ -1194,10 +1194,10 @@ MESSAGE to SGSN at 0x05060708:32000, msg length 4 result (UNITDATA) = 4 Peers: - NSEI 8192, BVCI 12290, not blocked, RAC 10-32-16464-96 - NSEI 4096, BVCI 8194, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96 + NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96 NSEI mismatch : 1 - NSEI 8192, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96 NSEI mismatch : 1 PROCESSING UNITDATA from 0x05060708:32000 00 00 20 02 @@ -1211,11 +1211,11 @@ NS UNITDATA MESSAGE to BSS, BVCI 0x2002, msg length 0 result (UNITDATA) = -22 Peers: - NSEI 8192, BVCI 12290, not blocked, RAC 10-32-16464-96 - NSEI 4096, BVCI 8194, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96 + NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96 NSEI mismatch : 1 NS Transmission error : 1 - NSEI 8192, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96 NSEI mismatch : 1 --- Send message from BSS 1 to SGSN and back, BVCI 3 --- @@ -1302,16 +1302,16 @@ Current NS-VCIs: Setup BSSGP: remote 0x01020304:1111, BVCI 0x1002(4098) PROCESSING BVC_RESET from 0x01020304:1111 -00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 CALLBACK, event 0, msg length 22, bvci 0x0000 -22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22 -22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 MESSAGE to SGSN at 0x05060708:32000, msg length 26 -00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 result (BVC_RESET) = 26 @@ -1330,27 +1330,27 @@ MESSAGE to BSS at 0x01020304:1111, msg length 9 result (BVC_RESET_ACK) = 9 Peers: - NSEI 8192, BVCI 12290, not blocked, RAC 10-32-16464-96 - NSEI 4096, BVCI 8194, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96 + NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96 NSEI mismatch : 1 NS Transmission error : 1 - NSEI 8192, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96 NSEI mismatch : 1 --- Setup BVCI 4 --- Setup BSSGP: remote 0x01020304:1111, BVCI 0x4002(16386) PROCESSING BVC_RESET from 0x01020304:1111 -00 00 00 00 22 04 82 40 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 40 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 CALLBACK, event 0, msg length 22, bvci 0x0000 -22 04 82 40 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 40 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22 -22 04 82 40 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +22 04 82 40 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 MESSAGE to SGSN at 0x05060708:32000, msg length 26 -00 00 00 00 22 04 82 40 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 +00 00 00 00 22 04 82 40 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 result (BVC_RESET) = 26 @@ -1369,12 +1369,12 @@ MESSAGE to BSS at 0x01020304:1111, msg length 9 result (BVC_RESET_ACK) = 9 Peers: - NSEI 8192, BVCI 16386, not blocked, RAC 10-32-16464-96 - NSEI 8192, BVCI 12290, not blocked, RAC 10-32-16464-96 - NSEI 4096, BVCI 8194, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 16386, not blocked, RAC 112-332-16464-96 + NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96 + NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96 NSEI mismatch : 1 NS Transmission error : 1 - NSEI 8192, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96 NSEI mismatch : 1 --- Send message from BSS 1 to SGSN and back, BVCI 1 --- @@ -1423,12 +1423,12 @@ MESSAGE to SGSN at 0x05060708:32000, msg length 4 result (UNITDATA) = 4 Peers: - NSEI 8192, BVCI 16386, not blocked, RAC 10-32-16464-96 - NSEI 8192, BVCI 12290, not blocked, RAC 10-32-16464-96 - NSEI 4096, BVCI 8194, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 16386, not blocked, RAC 112-332-16464-96 + NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96 + NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96 NSEI mismatch : 2 NS Transmission error : 1 - NSEI 8192, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96 NSEI mismatch : 1 PROCESSING UNITDATA from 0x05060708:32000 00 00 20 02 @@ -1442,12 +1442,12 @@ NS UNITDATA MESSAGE to BSS, BVCI 0x2002, msg length 0 result (UNITDATA) = -22 Peers: - NSEI 8192, BVCI 16386, not blocked, RAC 10-32-16464-96 - NSEI 8192, BVCI 12290, not blocked, RAC 10-32-16464-96 - NSEI 4096, BVCI 8194, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 16386, not blocked, RAC 112-332-16464-96 + NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96 + NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96 NSEI mismatch : 2 NS Transmission error : 2 - NSEI 8192, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96 NSEI mismatch : 1 --- Send message from BSS 1 to SGSN and back, BVCI 3 --- @@ -1511,12 +1511,12 @@ result (UNITDATA) = 4 Gbproxy global: Peers: - NSEI 8192, BVCI 16386, not blocked, RAC 10-32-16464-96 - NSEI 8192, BVCI 12290, not blocked, RAC 10-32-16464-96 - NSEI 4096, BVCI 8194, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 16386, not blocked, RAC 112-332-16464-96 + NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96 + NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96 NSEI mismatch : 2 NS Transmission error : 2 - NSEI 8192, BVCI 4098, not blocked, RAC 10-32-16464-96 + NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96 NSEI mismatch : 1 ===== GbProxy test END -- 1.7.9.5

9 years, 10 months

2
4
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC June 2014