Hi everybody,
Had somebody made a support for a femtocell like Samsung, or
huawei(uap2105), or any common femtocells?
I just want to test and learn how MN works
Thanks
Niko
On 06/11/2018 07:12:AM, openbsc-request(a)lists.osmocom.org wrote:
> They sent me an ADM of 16 digits : 3838383838383838
This is hex:
3838383838383838 = 0x38, 0x38, 0x38, 0x38, 0x38, 0x38,0x38, 0x38 = '88888888' ASCII
Depending in what tool you are using the ADM is either: 0x3838383838383838 or '88888888'
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Hi,
> I tried this apdu, but it did not work [...]
> Any clues, why it is not working?
Most likely, your SIM card is blocked now. There is some
kind of protection against ADM PIN brute-forcing - after 3
incorrect ADM presentations, the SIM card blocks itself.
AFAIK, there is no way to unblock it anymore.
P.S. Please read how to use the mailing lists. 70% of this
E-mail is unreadable (and useless) garbage (i.e.
images, quoted replays, Avast PR, etc.).
With best regards,
Vadim Yanitskiy.
Hello,
In our country at Madagascar , operator could send message on phone with MISDN like a string not like a number. I would like to ask if it's possible to do the same thing with osmo-bts !!!
For example : They could send message with the phone and the identity on the phone is like : "Telma", "Mvola", "orangeinfo" ...with a samsung phone I could not call this identity and with tecno phone, it shows that the number is for the MISDN "telma" is 83562 and for the MISDN "Mvola" is 68652 .... The logic of this number on tecno is that , it the number on the touchscreen of the old phone without the repetition of the tape of the touch. in this, 2=abc and 3=def and 4=ghi and 5=jkl and 6=mno and 7=pqrs and 8=tuv and 9=wxyz.
My last goal is to send a message with a phone on the network (osmo-bts) and it's my that appears on the destinary.
chears,
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
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
> 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.
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.
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
