November 2018 - OpenBSC - lists.osmocom.org

voting in gerrit: merge at +3? (+2+1 / +1+1+1)

by Stefan Sperling

There has been some face-to-face discussion about Osmocom's code review process within sysmocom recently. I am posting to this list now with the consent of everyone involved so far, in order to involve the Osmocom community at large in this discussion as well. There has been a lack of code review from people who don't have "+2" super powers in Gerrit. This applies to anyone among us, independently of any individual's relationship with sysmocom. The bulk of the work involved in reviewing code falls on Harald's shoulders, with Pau and Neels sharing most of the rest between themselves. At present, while people who add a +1 have their voices heard, their input does not formally affect the decision to merge a change. A change still has to pass by the pre-selected +2 gatekeepers in order to be merged, no matter how many other people have provided input. The implication for developers without +2 powers is that their time is more effectively spent on advancing their own changes towards a +2 vote, rather than spending time on whatever else is waiting in Gerrit. This may not apply to everyone, of course. But at least for me, this is certainly the case; I have only been reviewing other people's patches when I was explicitly asked to do so. Myself and several other developers hope that with a change to our review process we can fix this inertia, spread code review across more shoulders and encourage more collaborative code review in Osmocom. The basic idea is that everyone's input should count for something. If those among us with +1 powers were given a partial say on the fate of every change, our decisions will carry more weight and our influence within the project will slightly increase. We'd also be encouraged to step out of our own corners of expertise every now and then, and look at what other developers are working on. On the flip side, this means we'd carry more responsibility than we do now. We wouldn't always be relying on our +2 gate keepers and would have to apply our own judgement more carefully. The concrete proposal is to make votes in Gerrit accumulative. Each change would require a total score of +3 to be merged. This score can consist of either a +2 and a +1 vote, or three +1 votes; and no -1 votes. Also, +2 developers would keep their ability to unilaterally block or revert changes under this new model. They'd keep their existing role as arbiters in case of disputes. Max figured out how Gerrit could be configured for this behaviour. It involves Prolog code, but since we're all quite smart we should be able to figure that out, right? https://gerrit-review.googlesource.com/Documentation/prolog-cookbook.html#_… We'd be interested to hear what the community thinks about this proposal. Thanks, Stefan

5 years, 4 months

7
43
0 0

Info on Alcatel Femtocells

by Alex

Hi to everyone! I'm a new member and I really appreciate the work done here! I'm trying to use Alcatel Femtocells (ALU 9361/9362/9363) with osmo-hnbgw, but I'm still blocked at the IPSEC tunnel step. I've created an IPSEC server with EAP support, but I suspect there is a problem with my self signed certificate. Probably the femtocell has an internal trusted CA which validates server certs. I din't find the console pins on the board also, so I cannot simply connect to it and have a look at the system level. Has anyone any experience with this kind of HW or just an idea about a possible work around? Thank you and best regards Alex

5 years, 4 months

2
6
0 0

HEADS UP: don't merge .adoc or vty ref changes to osmo-gsm-manuals.git anymore!

by Neels Hofmeyr

The adocs and vty reference content from osmo-gsm-manuals.git has been "moved" to the individual project repositories. That means if you apply more .adoc changes to osmo-gsm-manuals.git, we have to port that to the new location. (The content is not yet removed from osmo-gsm-manuals.git, so you might run into believing the move hasn't happened yet.) You can already edit in the individual osmo-bsc,-msc,... repositories, and build with 'configure --enable-manuals'. The jenkins publishing job isn't updated yet, should follow soon. right, osmith? ~N

5 years, 4 months

3
4
0 0

osmo-gsm-manuals in project repos: I see no .pdf

by Neels Hofmeyr

Hi Oliver, so I merged the stuff to add the manuals to the individual git repositories, since you said that it works. But when I do --enable-manuals I don't see any PDF files generated. Also a manual 'make pdf' says "nothing to be done". (I probably should have tried it before merging after all) So what am I doing wrong? Alternatively, can you fix it please? ~N

5 years, 4 months

2
2
0 0

nanoBTS fails to start with osmo-bsc

by Pierre Kim

With the newest git repo version of osmo-bsc, my nanoBTS fails to start. I can confirm that they work normally with ip.access softBSC. I thought osmocom Redmine issue #3063 might be relevant and tried setting/unsetting force-combined-si but I am still getting the same result. Attached are the packet capture and bsc config file The following is the log from osmo-bsc: <0015> input/ipa.c:262 accept()ed new link from 192.168.27.40 to port 3002 <0004> abis_nm.c:847 OC=BTS(01) INST=(ff,ff,ff): GET ATTRIBUTE NACK <0004> osmo_bsc_main.c:178 BTS0 does not support Get Attributes OML message. <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: ARI reported sw[0/5]: 168a004 is v136d0 <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: ARI reported sw[1/5]: 168a002 is v136d0 <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: ARI reported sw[2/5]: 168a002 is v136d0 <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: ARI reported sw[3/5]: 168a001 is v136d0 <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0: ARI reported sw[4/5]: 168a001 is v136d0 <0004> abis_nm.c:494 BTS0 Attribute Manufacturer Dependent State is unreported <0004> abis_nm.c:2888 (bts=0,trx=0) IPA RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00 <0015> input/ipa.c:262 accept()ed new link from 192.168.27.40 to port 3003 <0003> osmo_bsc_main.c:283 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 600 using MCC-MNC 450-09 LAC=23 CID=0 BSIC=63 BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=l2_bch.c:1149 **** ** l2_bch.c#1149:BCHbcchSItypeValid( prim_p->infoType ) ** IPA_SW_FATAL_ERROR ** In task "TRX Proc:L2_BCH" @ (325). **** . BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=TRX Proc:L2_BCH:l2_bch.c#1149 (325). BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=31782:WARN:OAM_RES:trx_fatal_error_log.c#255:TRX has logged the error: . BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=31782:WARN:OAM_RES:trx_fatal_error_log.c#256:TRX Proc:L2_BCH:l2_bch.c#1149 (325)

5 years, 5 months

2
2
0 0

cellmgr-ng rotten (Re: Build failed in Jenkins: master-cellmgr-ng » a1=default,a2=default,a3=default,osmocom-master-debian9 #54)

by Pau Espin Pedrol

Hi all, I started looking at this failure and found out code in this repository is really old, with nobody maintain it (13 months since last commits?). I started by updating the contrib/jenkins.sh to use osmo-build-dep.sh and osmo-clean-workspace.sh like we do in other repos, because i felt it was not building up to date stuff. After updating that script, indeed it seems cellmgr-ng cannot be built against new libosmo-sccp due to some M3UA headers /API changes. There's even a tag during that commit in libosmo-sccp called "old_sua". After that commit, cellmgr-ng fails to build. If I try to build it against "old_sua", still cannot build fine with updated contrib/jenkins.sh script due to missing LIBOSMOSCCP_CFLAGS in tests/Makefile.am, and then still other headers are not found in other places, etc. I stopped at this point because I'm starting to spent too muhch time on this and it seems nobody is using it anyway. Can we disable the build of this project? Does somebody want to take care of it? Regards, Pau -- - Pau Espin Pedrol <pespin(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 Director: Harald Welte

5 years, 5 months

2
1
0 0

SMS: UCS-2 concatenation with UTF16 emoticons

by Keith

Hi all, I noticed that SMS with emoticons on the boundary of the concatenated segments are not displaying correctly on the destination handset. * - imagine the disaster when that kiss-blowing smiley face thing at the end of your SMS turns out as a diamond with a ? for the recpipient! OMG, the potential butterfly effect is too much to think about... :)) So... This is my analysis: We have 140 bytes for the message, less the 6 bytes for the user header data in the case of concatenated SMS , leaving 134 bytes. It's well know that this means 67 characters per segment for an SMS using UCS-2 encoding. But, it we fill the message with emoticons that are using 4 bytes per 'character', then we have space for 134/4 = 33 and a half. Ooops. Still, the destination handset should reassemble the message and stick the two "halves" of the emoticon together, right? - except I'm not observing this. To rule out us doing something wrong in osmo, I wonder might somebody else (who has an unlimited SMS package) from a commercial provider try sending some crafted SM from one emoji-enabled phone to another, something like this: 😱abcdefghijklmnopqrstuvwxyz123456789abcdefghijklmnopqrstuvwxyz123😱56789 That's likely going to get mangled by mailing list or your mua, so it is: [4 byte emoji]abcdefghijklmnopqrstuvwxyz123456789abcdefghijklmnopqrstuvwxyz123[4 byte emoji]56789 You could also try various messages filled with emojis. Of course, if you bring up your osmo network with SMPP-mirror you can watch the trace in wireshark, you'll see when the last emoji gets chopped in two. You could try the same message on osmo and your commerical network. If it's actually a problem of the phones, you should get [4 byte emoji]abcdefghijklmnopqrstuvwxyz123456789abcdefghijklmnopqrstuvwxyz123[two diamonds with ?]56789 Thanks! Keith.

5 years, 5 months

4
4
0 0

3G with Asterisk connection

by Pierre Kim

Hello, I'm setting up an Asterisk connection with osmo-sip-connector. Initiation of calls works fine, but no sound is getting through. My setup is as follows: Local computer is running all osmo software plus asterisk interface has IP address 192.168.27.49 plus 192.168.27.47 as alias femtocell is at 192.168.27.41 osmo-mgw.cfg mgcp bind ip 192.168.27.49 rtp port-range 4002 16000 rtp bind-ip 192.168.27.47 osmo-sip-connector.cfg sip local 192.168.27.47 5069 remote 192.168.27.49 5060 osmo-msc.cfg msc mgw remote-ip 192.168.27.49 mgw remote-port 2427 mgw local-port 2728 When I start wireshark it only shows packets flowing between 192.168.27.41(femtocell) and 192.168.27.47(osmo-mgw). No packets to/from Asterisk server, how can I fix this problem? Current documentation on osmo-mgw is quite difficult to understand.

5 years, 5 months

2
3
0 0

GSUP protocol manual in HLR, MSC, SGSN

by Neels Hofmeyr

(cross-posting so it doesn't get lost) reading Vadim's patches, I just now invented: https://osmocom.org/issues/3700 "Idea: have a separate GSUP manual" Provide feedback at that issue if you have an opinion... ~N

5 years, 5 months

1
0
0 0

3G data connection loss

by Pierre Kim

Hello, I've set up a mini 3G RAN with yesterday's git repo. The phone works fine and successfully creates a PDP context, but data only works for a few minutes before it stops. Logs from SGSN and GGSN are as follows. Any help will be appreciated. >From SGSN: <000e> sgsn_libgtp.c:175 PDP(450091417013617/0) Create PDP Context <0018> iu_client.c:530 handle_co(dir=4, proc=0) <0018> iu_client.c:530 handle_co(dir=1, proc=11) <0018> iu_client.c:530 handle_co(dir=2, proc=1) <0018> iu_client.c:507 handle_co_initial(dir=1, proc=19) <0018> iu_client.c:530 handle_co(dir=2, proc=6) <0002> gprs_gmm.c:208 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x221bd60]{Init}: Event IU Security Command Complete received. not permitted <0018> iu_client.c:599 Error in cn_ranap_handle_co (-1) <0018> iu_client.c:530 handle_co(dir=1, proc=20) <0018> iu_client.c:530 handle_co(dir=4, proc=0) <0018> iu_client.c:530 handle_co(dir=1, proc=11) <0018> iu_client.c:530 handle_co(dir=2, proc=1) <0018> iu_client.c:507 handle_co_initial(dir=1, proc=19) <0018> iu_client.c:530 handle_co(dir=2, proc=6)<0002> gprs_gmm.c:208 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x221bd60]{Init}: Event IU Security Command Complete received. not permitted <0018> iu_client.c:599 Error in cn_ranap_handle_co (-1) <0018> iu_client.c:530 handle_co(dir=1, proc=20) <0018> iu_client.c:530 handle_co(dir=4, proc=0) <0018> iu_client.c:530 handle_co(dir=1, proc=11) <0018> iu_client.c:530 handle_co(dir=2, proc=1) <0023> gtp.c:2800 Packet from 192.168.27.46:2152, length: 95 content: 32 ff 00 57 00 00 00 05 11 b4 00 00 45 00 00 53 ad fc 40 00 38 06 7b 5c 17 23 dd 7e c0 a8 64 02 01 bb cf 8c 78 70 5c a6 c2 6b 46 39 80 18 01 fc 05 54 00 00 01 01 08 0a 9f 6b cd 80 ff ff 61 96 15 03 03 00 1a 6e ec c9 35 4b a9 48 c5 23 b0 fa 35 a5 d6 e7 e5 5b 95 f0 38 45 0a cf c8 97 d1 : Unknown PDP context, GTPv1 <0023> gtp.c:2800 Packet from 192.168.27.46:2152, length: 64 content: 32 ff 00 38 00 00 00 05 11 b5 00 00 45 00 00 34 ad fd 40 00 38 06 7b 7a 17 23 dd 7e c0 a8 64 02 01 bb cf 8c 78 70 5c c5 c2 6b 46 39 80 11 01 fc dd ce 00 00 01 01 08 0a 9f 6b cd 80 ff ff 61 96 : Unknown PDP context, GTPv1 GGSN <0002> ggsn.c:735 PDP(450091417013617:5): Successful PDP Context Creation: APN=internet(internet), TEIC=1, IPv4=192.168.100.2, IPv6=none <000d> gtp.c:2761 Packet from 192.168.27.49:2152, length: 24 content: 32 1a 00 10 00 00 00 00 11 b4 00 00 10 00 00 00 05 85 00 04 c0 a8 1b 31 : Received Error Indication <0002> ggsn.c:372 PDP(450091417013617:5): Deleting PDP context <000d> gtp.c:2755 Packet from 192.168.27.49:2152, length: 24 content: 32 1a 00 10 00 00 00 00 11 b5 00 00 10 00 00 00 05 85 00 04 c0 a8 1b 31 : Unknown PDP context <000d> gtp.c:2117 Packet from 192.168.27.49:2123, length: 52 content: 32 12 00 2c 00 00 00 01 4c 0a 00 00 0e 13 10 00 00 00 05 14 05 85 00 04 c0 a8 1b 31 85 00 04 c0 a8 1b 2a 87 00 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : Unknown PDP context: 1 <000d> gtp.c:2800 Packet from 192.168.27.42:2152, length: 72 content: 32 ff 00 40 00 00 00 01 00 00 00 00 45 00 00 3c 6f 51 40 00 40 06 08 fb c0 a8 64 02 d8 3a c5 8a cb 5a 01 bb 7a dc a8 09 00 00 00 00 a0 02 ff ff ce 3c 00 00 02 04 05 b4 04 02 08 0a ff ff c7 58 00 00 00 00 01 03 03 06 : Unknown PDP context, GTPv1 <000d> gtp.c:2800 Packet from 192.168.27.42:2152, length: 72 content: 32 ff 00 40 00 00 00 01 00 01 00 00 45 00 00 3c 6f 52 40 00 40 06 08 fa c0 a8 64 02 d8 3a c5 8a cb 5a 01 bb 7a dc a8 09 00 00 00 00 a0 02 ff ff cd 42 00 00 02 04 05 b4 04 02 08 0a ff ff c8 52 00 00 00 00 01 03 03 06 : Unknown PDP context, GTPv1 <000d> gtp.c:2800 Packet from 192.168.27.42:2152, length: 72 content: 32 ff 00 40 00 00 00 01 00 02 00 00 45 00 00 3c 6f 53 40 00 40 06 08 f9 c0 a8 64 02 d8 3a c5 8a cb 5a 01 bb 7a dc a8 09 00 00 00 00 a0 02 ff ff cb 4d 00 00 02 04 05 b4 04 02 08 0a ff ff ca 47 00 00 00 00 01 03 03 06 : Unknown PDP context, GTPv1

5 years, 5 months

3
6
0 0

Help with silent call

by Snehasish Kar

Hello I have read that silent-calls in GSM can be used to make a call to a target MS and listen to it without having the target knowing it. Is this theoretically possible ? If yes, can it be done in OpenBSC or any such way exists to do this or any other alternative does exists? BR Snehasish

5 years, 5 months

3
4
0 0

Failing test cases (and builds) on other architectures in Debian

by Ruben Undheim

Hi, Most of the openbsc packages are now up-to-date in Debian! : https://qa.debian.org/developer.php?email=Debian-mobcom-maintainers%40lists… , but there are a few failing builds on some officially supported Debian architectures (mostly failing test suites): osmo-bsc: - mips (https://buildd.debian.org/status/fetch.php?pkg=osmo-bsc&arch=mips&ver=1.2.1…) ("gsm0408" and many "handover" tests failing) - s390x (https://buildd.debian.org/status/fetch.php?pkg=osmo-bsc&arch=s390x&ver=1.2.…) ("gsm0408" and many "handover" tests failing) osmo-iuh: - mips (https://buildd.debian.org/status/fetch.php?pkg=osmo-iuh&arch=mips&ver=0.3.0…) ("helpers" and "ranap" tests failing) - s390x (https://buildd.debian.org/status/fetch.php?pkg=osmo-iuh&arch=s390x&ver=0.3.…) ("helpers" and "ranap" tests failing) osmo-msc: - mips64el (https://buildd.debian.org/status/fetch.php?pkg=osmo-msc&arch=mips64el&ver=1…) ("msc_vlr_test_gsm_ciph" test failing) - mipsel (https://buildd.debian.org/status/fetch.php?pkg=osmo-msc&arch=mipsel&ver=1.2…) ("msc_vlr_test_gsm_ciph" test failing) osmo-pcu: - mips (https://buildd.debian.org/status/fetch.php?pkg=osmo-pcu&arch=mips&ver=0.5.1…) (error: #error "Only little endian headers are supported yet. TODO: add missing structs") - s390x (https://buildd.debian.org/status/fetch.php?pkg=osmo-pcu&arch=s390x&ver=0.5.…) (error: #error "Only little endian headers are supported yet. TODO: add missing structs") Maybe some of you can immediately see what is wrong, and what needs to be fixed? Best regards Ruben

5 years, 5 months

5
16
0 0

Femto Access Point provisioning for Osmocom/Sysmocom

by Mykola Shchetinin

Hello, dear Osmocom Community and Sysmocom Team! We are trying out Osmocom software (3G only) to replace the proprietary software that we are using now. And we like it very much :) Our femtocells were provisioned with the same proprietary software we used but now we have to do that ourselves when using Osmocom software. We have come up with a solution which we wish to share with you and hope it will come in handy. Also, I am curious about how you handle it. How do you provision femtocells you have? We've found this page: https://osmocom.org/projects/cellular-infrastructure/wiki/Configuring_the_i… But we were unable to follow the procedures described there as they are outdated (to be precise, they are for outdated firmware). We use ip.access nano3g femtocells (S8 and S16) which are provisioned by means of CWMP server (also called ACS - auto configuration server). (more info: https://en.wikipedia.org/wiki/TR-069) The network configuration and an address of ACS for a femtocell to use are configured through the web page after a factory reset of a femtocell. We looked at FreeACS at first (https://github.com/freeacs/freeacs). It looked quite dead half year ago, but it seems that it is being revived. Then we looked at GenieACS (https://github.com/genieacs/genieacs) and managed to make it provision the femtocell. I did get all CWMP params from the femtocell first by sending appropriate CWMP messages (getParameterNames, getParameterValues) to the FAP from the ACS and recording traffic with tcpdump. From the information I got, I made a configuration file where I changed some parameters like PLMNID or NTP server addresses to desired values. Then I wrote a script which read the configuration file and set the params of the femtocell using functions provided by GenieACS. I configured the GenieACS to execute the script when getting a request from femtocell. The sample configuration file and sample scripts are described in a document-reminder I wrote for myself: https://gist.github.com/efistokl/b95538772e54e5edb7765021c2b5a745#22-config… I didn't make it use different configurations for different femtocells yet. I just made it to allow me to work with Osmocom software and my femtocell. I wish to improve the usability of this by writing some cli program to make the configuration process of the femtocell more automated as we will need to provision multiple femtocells connected to a single Osmocom system and a single ACS later. (or change the ACS choice completely) Thank You for creating and maintaining such a cool software! Kind regards, Mykola Shchetinin P.S. Does anybody have experience using some other ACS/CWMP solution? Could you share it?

5 years, 5 months

3
2
0 0

GSN Error Indication behavior

by Pierre Kim

After some debugging I found that the intermittent data loss was caused by the GSN not properly reacting to Error Indication packets. >From GGSN: <0002> ggsn.c:809 PDP(450091417013617:5): Packet received on APN(internet): forwarding to tun apn0 <000d> gtp.c:2681 Packet from 192.168.27.49:2152, length: 24 content: 32 1a 00 10 00 00 00 00 40 8e 00 00 10 00 00 00 05 85 00 04 c0 a8 1b 31 : Received Error Indication <0002> ggsn.c:372 PDP(450091417013617:5): Deleting PDP context <000d> pdp.c:255 Begin pdp_tiddel tid = 5716310714190054 <000d> pdp.c:262 End pdp_tiddel: PDP found When the GGSN receives an error indication, isnt' it supposed to acknowlege the SGSN and attempt to reinitialize the connection? In my case the GGSN simply deleted the PDP context locally and both SGSN and GGSN gets flooded by unknown PDP context error, while the phone keeps trying to transmit data. Tested on lastest git version and lastest release version: osmo-sgsn 1.3.0, osmo-ggsn 1.2.1 Regards, Pierre

5 years, 5 months

3
3
0 0

handover request

by Max

Hi. I've noticed that we don't have any code (besides basic definition) for handover request message (BSS_MAP_MSG_HANDOVER_RQST) from 48.008 3.2.1.8 in libosmocore or osmo-*sc. Is it because it's in some patch hanging somewhere in gerrit or we don't need it (yet)? -- - 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

5 years, 5 months

2
2
0 0

ttcn3 question

by Neels Hofmeyr

I guess I'm again hitting the same ttcn3 wall that has caused me trouble countless times before... I'm trying to run the already existing TC_ho_into_this_bsc(), but before it starts I want to occupy all lchans. This is the working TC_ho_into_this_bsc(): testcase TC_ho_into_this_bsc() runs on test_CT { var MSC_ConnHdlr vc_conn; var TestHdlrParams pars := f_gen_test_hdlr_pars(); f_init(1, true); f_sleep(1.0); pars.handover.sccp_addr_msc := g_bssap.sccp_addr_own; pars.handover.sccp_addr_bsc := g_bssap.sccp_addr_peer; vc_conn := f_start_handler(refers(f_tc_ho_into_this_bsc), pars); vc_conn.done; } I just want to insert a bit of TC_chan_exhaustion() like so: testcase TC_ho_in_fail_no_chan() runs on test_CT { var integer i; var MSC_ConnHdlr vc_conn; var TestHdlrParams pars := f_gen_test_hdlr_pars(); f_init(1, true); f_sleep(1.0); /* occupy all lchans */ for (i := 0; i < NUM_TCHF_PER_BTS + NUM_TCHH_PER_BTS + NUM_SDCCH_PER_BTS; i := i+1) { var RslChannelNr chan_nr := f_chreq_act_ack('23'O, i); } pars.handover.sccp_addr_msc := g_bssap.sccp_addr_own; pars.handover.sccp_addr_bsc := g_bssap.sccp_addr_peer; vc_conn := f_start_handler(refers(f_tc_ho_in_fail_no_chan), pars); vc_conn.done; } But no matter which way I turn it, ttcn3 does not agree. * I either get: 21:36:03.008137 mtc BSC_Tests.ttcn:1553 Dynamic test case error: Using the value of an unbound component reference. 21:36:03.008163 mtc BSC_Tests.ttcn:1553 setverdict(error): none -> error This is during f_connect_handler(): connect(vc_conn:BSSMAPEM, g_bssap.vc_BSSMAP:PROC); with the log revealing [1] below * Or I get: 21:31:45.678006 mtc BSC_Tests.ttcn:366 Dynamic test case error: Port IPA_RSL[0] has neither connections nor mappings. Message cannot be sent on it. 21:31:45.678094 mtc BSC_Tests.ttcn:366 setverdict(error): none -> error This stuff really gets me steaming with ttcn... anyhow... I'm fairly certain it has to do with the 'true' arg of f_init() starting the RSL emulation, so I need to re-invent TC_chan_exhaustion() on the MSC_ConnHdlr? Sort of like the hack I have in f_tc_ho_into_this_bsc()? " /* Hack: the proper way would be to wait for the BSSMAP Handover Request ACK and extract the * actual assigned chan_nr from its L3 (RR Handover Command) message. But osmo-bsc starts acting * on the lchan even before we get a chance to evaluate the BSSMAP Handover Request ACK. So we * need to assume that osmo-bsc will activate TS 1 and already set up this lchan's RSL emulation * before we get started. */ var RslChannelNr new_chan_nr := valueof(t_RslChanNr0(1, RSL_CHAN_NR_Bm_ACCH)); f_rslem_register(0, new_chan_nr); g_chan_nr := new_chan_nr; f_sleep(1.0); " I wish it were easier...? ~N [1] 21:36:03.008009 mtc BSC_Tests.ttcn:1552 XXXXX { vc_M3UA := VirtMSC-M3UA(4), vc_IPA := <unbound>, vc_WAIT := <unbound>, vc_SCCP := VirtMSC-SCCP(3), sccp_pars := { sio := { ni := '10'B, prio := '00'B, si := '0011'B }, opc := 185, dpc := 187, sls := 0, sccp_serviceType := "mtp3_itu", ssn := 254 }, sccp_addr_own := { addressIndicator := { pointCodeIndic := '1'B, ssnIndicator := '1'B, globalTitleIndic := '0000'B, routingIndicator := '1'B }, signPointCode := '00000010111001'B, subsystemNumber := 254, globalTitle := omit }, sccp_addr_peer := { addressIndicator := { pointCodeIndic := '1'B, ssnIndicator := '1'B, globalTitleIndic := '0000'B, routingIndicator := '1'B }, signPointCode := '00000010111011'B, subsystemNumber := 254, globalTitle := omit }, vc_BSSMAP := <unbound> } -- - Neels Hofmeyr <nhofmeyr(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 * Geschäftsführer / Managing Directors: Harald Welte

5 years, 5 months

1
0
0 0

ipaccess-proxy usage help

by Mihai Ordean

Hey guys, Sorry to keep insisting on this, but I don't seem to be able to make ipaccess-proxy work with either the old OpenBTS nor with the new Osmocom stack. Did anyone have any recent(ish) experience using it. At this point I'd appreciate any tip anyone can provide towards getting a working setup. Thanks, -- Mihai

5 years, 5 months

1
0
0 0

OC-2G merge to osmo-bts

by Harald Welte

Dear Osmocom team, Omar has thankfully submitted patches for inclusion of OC-2G support to gerrit, see https://gerrit.osmocom.org/#/c/osmo-bts/+/11447/ for the bulk of the code. An initial review showed there are *many* parts that are identical to osmo-bts-litecell15, and we generally don't like "copy+paste" programming. In the end we have multiple compies of essentially the same source files, becoming a maintenance problem over time, when fixes are applied to one copy, but not the other. I've manually looked through each of the files and looked at the differences between the oc2g and the lc15 counterpart. == 100% identical to osmo-bts-sysmo or osmo-bts-lc15: oml_router.c oml_router.h misc/oc2gbts_nl.c == 99% identical to lc15 (just names changed) hw_misc.h hw_misc.c l1_transp.h l1_trans_hw.c oc2gbts.c / lc15bts.c oc2gbts_vty.c / lc15bts_vty.c oml.c tch.c utils.c utils.h l1_if.h misc/oc2gbts_bts.h misc/oc2gbts_bid.h misc/oc2gbts_clock.h misc/oc2gbts_clock.c misc/oc2gbts_led.c misc/oc2gbts_swd.c misc/oc2gbts_swd.h == 80% identical to lc15 (some small changes) l1_if.c misc/oc2gbts_bts.c misc/oc2gbts_mgr.c misc/oc2gbts_mgr.h misc/oc2gbts_mgr_nl.c misc/oc2gbts_temp.c misc/oc2gbts_temp.h == more differences compared to lc15, possibly not intentional? / what to do? misc/oc2gbts_temp.c misc/oc2gbts_mgr_vty.c misc/oc2gbts_misc.c misc/oc2gbts_par.c misc/oc2gbts_power.c misc/oc2gbts_util.c So we have to discuss how to go about this. The 100% identical files are easy, one can simply lik the existing implementation. We could also introduce a "src/nuran-common" directory for common code between the different models. For those parts with less similarity, this may require some refactoring, so that common/shared code goes to common/shared files and really only those bits that differ are handled in the respective implementations. Given that osmo-bts-litecell15 also started as copy of osmo-bts-sysmo, there may be room for further unification, but let's not conflate those two discussions. In terms of process, * we could first merge all the copies and then further unify the code, or * we could first modify the existing core/lc15 code to be able to merge OC2G coe without introducing lots of copied code. Any comments/suggestions/ideas? Regards, Harald -- - 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)

5 years, 5 months

3
5
0 0

Cheap, and easy accesible femtocell support

by NG

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

5 years, 5 months

2
1
0 0

Re: about piswords sim cards (?a?r? ?ENKAL)

by Alan Evans

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

5 years, 5 months

2
3
0 0

Re: about piswords sim cards (?a?r? ?ENKAL)

by Vadim Yanitskiy

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.

5 years, 5 months

1
0
0 0

MISDN like a string not like a number

by Radiarisainana Sitraka

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,

5 years, 5 months

2
1
0 0

about piswords sim cards

by Çağrı ŞENKAL

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

5 years, 5 months

1
0
0 0

AMR misconfiguration or bug

by Omar Ramadan

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 years, 5 months

5
7
0 0

Re: Help with silent call

by Vadim Yanitskiy

> 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.

5 years, 5 months

1
0
0 0

Re: EUSE with user input

by 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.

5 years, 5 months

1
0
0 0

BSSAP parsing in Osmo*SC

by Max

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

5 years, 5 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC November 2018