OpenBSC November 2018

openbsc@lists.osmocom.org

23 participants
35 discussions

about piswords sim cards
by Çağrı ŞENKAL 06 Nov '18

06 Nov '18

Hi, I am trying to program a USIM that I bought from aliexpress- piswords store. I think I need to have ADM pin to program the cards. Is it really necessary for piswords cards, do you have any experience? If so how did you get ADM pin? They sent me an ADM of 16 digits : 3838383838383838 However I think that it should be 8 digits. I tried 8 first 8 digits and it did not work I asked them to send me correct ADM . Do you have any experience regarding piswords cards? Any help is much appreciated. Regards, Cagri SENKAL [cid:image950557.PNG@39f2571e.4ca4c0cb]<http://www.havelsan.com.tr> [cid:imagee20435.JPG@6468be44.4fabfbb6] Çağrı ŞENKAL TEST ANALİSTİ Mustafa Kemal Mahallesi 2120 Cad. No:39 06510 Çankaya Ankara TÜRKİYE [cid:image66a2f6.PNG@2379de89.4e94e966] +90 312 219 57 87 [cid:image52a873.PNG@0085d638.49a22037] +90 312 219 57 97 [cid:image63fd4b.JPG@b3e744d5.419497ba] YASAL UYARI: Bu elektronik posta işbu linki kullanarak ulaşabileceğiniz Koşul ve Şartlar dokümanına tabidir. <http://havelsan.com.tr/tr/news/e-posta-yasal-uyari> LEGAL NOTICE: This e-mail is subject to the Terms and Conditions document which can be accessed with this link. <http://havelsan.com.tr/tr/news/e-posta-yasal-uyari> [http://www.havelsan.com.tr/Library/images/mail/email.jpg] Lütfen gerekmedikçe bu sayfa ve eklerini yazdırmayınız / Please consider the environment before printing this email

1 0

AMR misconfiguration or bug
by Omar Ramadan 05 Nov '18

05 Nov '18

Hey Osmocom, I am working to test hrAMR codec with osmo-bts-oc2g but it doesn't seem the correct TCH/F frame type is being activated: <0000> ../../../osmo-bts/src/common/rsl.c:2805 (bts=0,trx=0,ts=1,pchan=TCH/F_TCH/H_PDCH as PDCH) ss=0 Rx RSL CHAN_ACTIV <0000> ../../../osmo-bts/src/common/amr.c:105 AMR Multirate with 6 modes len=2 not possible <0000> ../../../osmo-bts/src/common/rsl.c:1159 (bts=0,trx=0,ts=1,ss=0): chan_nr=TCH/H(0) on TS1 type=0x01 mode=SPEECH_AMR <0006> ../../../osmo-bts/src/common/l1sap.c:1471 activating channel chan_nr=TCH/H(0) on TS1 trx=0 <0006> ../../../osmo-bts/src/osmo-bts-oc2g/oml.c:937 (bts=0,trx=0,ts=1,ss=0): lchan2lch_par tch_mode=0x41 <0006> ../../../osmo-bts/src/osmo-bts-oc2g/oml.c:1083 (bts=0,trx=0,ts=1,ss=0) MPH-ACTIVATE.req (hL2=0x000100bb, TCH/H TxDL) <0006> ../../../osmo-bts/src/osmo-bts-oc2g/oml.c:822 (bts=0,trx=0,ts=1,ss=0) MPH-ACTIVATE.conf (TCH/H TxDL) <0006> ../../../osmo-bts/src/osmo-bts-oc2g/oml.c:833 Error activating L1 SAPI TCH/H on TS 1: Invalid parameter <0006> ../../../osmo-bts/src/osmo-bts-oc2g/oml.c:1109 (bts=0,trx=0,ts=1,ss=0) act failed mark broken due status: -4 <0006> ../../../osmo-bts/src/common/l1sap.c:623 activate confirm chan_nr=TCH/H(0) on TS1 trx=0 <0000> ../../../osmo-bts/src/common/rsl.c:787 (bts=0,trx=0,ts=1,ss=0): Sending Channel Activated NACK: cause = 0x25 Frame 202: 101 bytes on wire (808 bits), 101 bytes captured (808 bits) on interface 0 Linux cooked capture Internet Protocol Version 4, Src: 10.42.0.1, Dst: 10.42.0.50 Transmission Control Protocol, Src Port: 3003, Dst Port: 51480, Seq: 90, Ack: 206, Len: 33 IPA protocol ip.access, type: RSL Radio Signalling Link (RSL) 0000 100. = Message discriminator: Dedicated Channel Management messages (4) .... ...0 = T bit: Not considered transparent by BTS .010 0001 = Message type: CHANnel ACTIVation (0x21) Channel number IE Activation Type IE Channel Mode IE Channel Identification IE BS Power IE MS Power IE Timing Advance IE MultiRate configuration IE Element identifier: MultiRate Configuration (0x36) Length: 2 001. .... = Multirate speech version: Adaptive Multirate speech version 1 (1) ...0 .... = NSCB: Noise Suppression Control Bit: Noise Suppression can be used (default) (0) .... 1... = ICMI: Initial Codec Mode Indicator: The initial codec mode is defined by the Start Mode field (1) .... ..00 = Start Mode: 0 0... .... = 12,2 kbit/s codec rate: is not part of the subset .0.. .... = 10,2 kbit/s codec rate: is not part of the subset ..1. .... = 7,95 kbit/s codec rate: is part of the subset ...1 .... = 7,40 kbit/s codec rate: is part of the subset .... 1... = 6,70 kbit/s codec rate: is part of the subset .... .1.. = 5,90 kbit/s codec rate: is part of the subset .... ..1. = 5,15 kbit/s codec rate: is part of the subset .... ...1 = 4,75 kbit/s codec rate: is part of the subset I am trying to understand how codec negotiation is performed, and whether this is a bug or mis-configuration. I've attached the BTS pcap and configurations that are being used. Thanks, Omar

5 7

Re: Help with silent call
by Vadim Yanitskiy 04 Nov '18

04 Nov '18

> If yes, can it [silent call] be done in OpenBSC or any such way > exists to do this or any other alternative does exists? Please check out http://ftp.osmocom.org/docs/latest/, you can find OsmoNiTB / OsmoMSC user manuals there. Silent call feature is supported, but not documented. Feel free to contribute! With best regards, Vadim Yanitskiy.

1 0

Re: EUSE with user input
by Vadim Yanitskiy 03 Nov '18

03 Nov '18

Hello Michael, > I have tried changing the session state to > `OSMO_GSUP_SESSION_STATE_CONTINUE`, and the gsup_msg_type to > `OSMO_GSUP_MSGT_PROC_SS_REQUEST` in `euse_tx_ss`. I see the “You > sent…” response on my phone, but do not get an input field. Since GSUP is used as the transport layer for encoded USSD payload, changing GSUP header fields wouldn't change the payload itself. In other words, what you are doing is correct, but additionally you need to change the message itself. The current code is using gsm0480_gen_ussd_resp_7bit() function from libosmocore, where you can find the following: // ... /** * Here you should change GSM0480_OP_CODE_PROCESS_USS_REQ * to GSM0480_OP_CODE_USS_REQUEST (see GSM 04.80). */ /* Pre-pend the operation code */ msgb_push_TLV1(msg, GSM0480_OPERATION_CODE, GSM0480_OP_CODE_PROCESS_USS_REQ); // ... /** * ... * Here you should change GSM0480_CTYPE_RETURN_RESULT * to GSM0480_CTYPE_INVOKE (see GSM 04.80). */ /* Wrap this up as a Return Result component */ msgb_wrap_with_TL(msg, GSM0480_CTYPE_RETURN_RESULT); so it makes sense to introduce a new function. Moreover, you should take care about InvokeID, it should uniquely identify each request-response pair in the following way: msc { MS [label="Subscriber"], EUSE [label="SS/USSD handler"]; MS => EUSE [label="GSM0480_OP_CODE_PROCESS_USS_REQ, GSM0480_CTYPE_INVOKE, invokeID=X"]; EUSE => MS [label="GSM0480_OP_CODE_USS_REQUEST, GSM0480_CTYPE_INVOKE, invokeID=X+1"]; MS => EUSE [label="GSM0480_OP_CODE_USS_REQUEST, GSM0480_CTYPE_RETURN_RESULT, invokeID=X+1"]; EUSE => MS [label="GSM0480_OP_CODE_PROCESS_USS_REQ, GSM0480_CTYPE_RETURN_RESULT, invokeID=X"]; } I am using X because not all phones start counting from 0, and this should be handled properly. X+1 is just an example, it can be calculated in a different way, but in any case it should be unique for the current stack of requests. Keep us updated, good luck! With best regards, Vadim Yanitskiy.

1 0

BSSAP parsing in Osmo*SC
by Max 02 Nov '18

02 Nov '18

Hi. While browsing through the code I've noticed that BSSMAP is parsed differently by OsmoBSC and OsmoMSC. In MSC we use "msg->l3h = &msg->l2h[sizeof(struct bssmap_header)];" in a_iface_bssap.c:707 and 202 In BSC we use "msg->l4h = &msg->l3h[sizeof(struct bssmap_header)];" in osmo_bsc_bssap.c:988 What's the reason for this difference? I thought that if protocol is the same than the basic layering and parsing should look the same as well. -- - Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Harald Welte

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC November 2018