January 2018 - OpenBSC - lists.osmocom.org

On the use of 'decmatch' in TTCN-3
by Harald Welte 31 Aug '26

31 Aug '26

Hi, I know that TTCN-3 is still new to a lot of you, but we are writing tons of integration testing against the various osmocom programs in it. It is quite amazing technology, and I would like to ask you to bear with me reading this mail :) Pau was stating the question earlier today on not finding an example on how to use decmatch. Indeed, it took me some months to find that gem in the TTCN-3 world. It solves the problem that you often have during test of layered protocol stacks: you have separate encoders/decoders for each protocol layer, and now you want to match on some of the *inner* payload. So normally, you have some kind of header definition + a binary (octetstring) payload. This happens in RSL with the L3_INFO IE, and just the same on BSSAP/DTAP where again the L3 message (for example call control) is encapsulated inside one information element. Now you have multiple options of addressing the problem: a) hand-written calls to the decoder function b) write na 'emulation' for the entire protocol layer c) use decmatch. a) would look like this (pseudo-code): var octetstring l3oct; var RSL_Message rsl RSL.receive(tr_RSL_DATA_REQ(g_chan_nr, ?, ?)) -> value rsl { var PDU_ML3_MS_NW l3 := dec_PDU_ML3_MS_NW(rsl.payload); if (match(l3, some_template)) { ... do something } ... } Which uses the built-in pattern-matching on the RSL port to match any message that matches the tr_RSL_DATA_REQ template, and stores the resulting RSL message in a variable. It then uses an explicit call to the decoder function of the L3 message, and then uses regular conditional expressions for further matching on that inner L3 payload. This is more or less how you would write in C, python or any other quite imperative programming languages. It's very verbose, time consuming and un-abstract/elegant. TTCN-3 has many declarative aspects to it. Code like the above is a waste of your time :) b) would mean that you implement some test component that handles the RSL messages on its bottom side test port, and the L3 messages on its top side test port. That is a possible way, and if you need a lot of state/logic of RSL, it maeks sense. But what if you really simply want to have a match? Then it would be a lot of effort and a large detour. c) decmatch to the rescue! You can write RSL.receive(tr_RSL_DATA_REQ(g_chan_nr, ?, decmatch tr_RRM_RR_STATUS)) which means: * do a receive on the RSL test port, and match on an incoming RSL message that matches the tr_RSL_DATA_REQ template, with channel number specified, link_id any (?), *and* if the octetstring payload, if decoded, matches the template tr_RRM_RR_STATUS ! This is *extremely* powerful and expressive. It allows you to condense complex, parametric template matching over multiple proocol layers. It would in the end match RSL DATA REQUEST, only if they contained a [valid] encoded RR STATUS. See https://gerrit.osmocom.org/6229 for the actual test case I used for the above examples. Please also note that I never had to even write the function name of the decoder (dec_PDU_ML3_MS_NW), but TTCN-3 *automatically* figures out which decoder function it must call in order to decode from the binary octetstring. Happy (TTCN-3) hacking + Osmocom bugfixing, 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)

4 4

GSM Silent call
by samir 04 May '26

04 May '26

Hi, 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 ?

4 3

ip.access nano 3G S8 Configuration
by John Thewlis - Meath Broadband 20 Apr '26

20 Apr '26

We are trying to setup this AP as part of the 3.5G Osmocom project. We have the software stack operational and are now preparing the nano for testing. When we try to login via telnet at port 8090 we are getting a constant refusal to connect:- root@osm/openbsc/openbsc/src/ipaccess# telnet 192.168.192.30 8090 Trying 192.168.192.30... telnet: Unable to connect to remote host: Connection refused The device seems to be locked as indicated by the leds on the front panel. We have tried resetting the nano to see if this would help but to no avail. Any ideas as to how to access the device for initial configuration?. Thanks John

7 7

Need nano3G (S8 - Model 237A)
by Akib Sayyed 16 Apr '26

16 Apr '26

Dear List I am extremely sorry for off the topic question. I am willing to buy nano3G Nodeb. Is anyone in list have spare which can be sold. Please let me know. -- Akib Sayyed Matrix-Shell akibsayyed(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243 <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

8 10

Splitting out M3UA and MTP3 out of Open BSC into a separate library
by Arran Cudbard-Bell 15 Apr '26

15 Apr '26

Hi, Developing a module for FreeRADIUS to support EAP-SIM and EAP-AKA authentication against a HLR. The HLR we were targeting only supported a SCTP/M3UA/SCCP/TCAP/MAP stack, so we couldn't use SUA. Ripping the M3UA/MTP3 code out of OpenBSC worked surprisingly well. We ended up running the event loop in a separate thread to work around the threading issues. Unfortunately the HLR implements the ANSI variant of everything, whereas OpenBSC and supporting libraries seem to have been written to be compatible with the ITU standards. ...but the differences are fairly minor at MTP3 and SCCP layers, and i've started work on a patchset for libosmo-sccp. https://gerrit.osmocom.org/#/c/73/ Anyway, trying to gauge interest in splitting those layers out of Open BSC into a separate library, would be happy to take on M2UA as well for consistency. It would almost certainly get more projects using the code. There's very little out there even in Perl land for working with SS7. Thanks, -Arran Arran Cudbard-Bell <a.cudbardb(a)freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

9 9

[PATCH 4/4] core/conv: Add optimized Viterbi decoding
by Vadim Yanitskiy 15 Apr '26

15 Apr '26

Hi Tom and all, After a quick look at the 4th patch, related to your optimized Viterbi decoder, I have noticed that currently the convolutional code definitions from the 'src/gsm/gsm0503_conv.c' are out of the 'tests/conv' test coverage... So, I would like to extend the test coverage. All I need are the test vectors, which I'll add to existing ones. Some of them I already found in your 4th patch, but some pending I need to write myself. Right now I have a simple question... Let's look at one example: { .name = "GSM RACH (non-recursive, flushed, not punctured)", .code = &gsm_conv_rach, .in_len = 14, .out_len = 36, // ??? .has_vec = 0, .vec_in = { }, .vec_out = { }, } As I noticed, the 'in_len' may be taken from the code definition: const struct osmo_conv_code gsm0503_rach = { .N = 2, .K = 5, .len = 14, // The 'in_len' is here! .next_output = xcch_output, .next_state = xcch_state, }; But I don't know how to calculate the 'out_len'... Could you please give me some hint? I already started to work on your 4th patch: https://gerrit.osmocom.org/1542 https://gerrit.osmocom.org/1543 With best regards, Vadim Yanitskiy.

2 2

Video Recordings of OsmoCon 2017
by Harald Welte 09 Feb '26

09 Feb '26

Hi all, the Osmocom Conference 2017 last week was an overwhelming success. We received lots of positive feedback from all sides. Thanks to all the speakers, to the attendees as well as to the anonymous sponsor of the travel grant funds. It is my great pleasure that due to the great support by C3VOC (The CCC Video Operation Center), we have full recordings of all talks given at OsmoCon 2017. You can find the videos on the C3VOC site at https://media.ccc.de/search/?q=osmocon They are also linked individually from the OsmoCon 2017 homepage at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017 I hope the video recordings will be of help for everyone who could not make it to the event in person. We will also be collecting the slides and put them up on the wiki during the next few days. Please don't hesitate to raise any feedback and/or questions. Technical feedback/questions regarding Osmocom software / projects should be addressed to the appropriate mailing lists, such as openbsc(a)lists.osmocom.org. Feedback to the organizers should be sent to osmocon2017(a)sysmocom.de. Looking forward to the next OsmoCon, which we'll expect to be spanning ore than just a single day. 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)

3 2

GPRS - local and foreign TLLIs
by Luca Melette 04 Feb '26

04 Feb '26

Hello everybody, after setting up a nanoBTS with OpenBSC/SGSN/GGSN, I had some troubles trying to connect my smartphone to the GPRS cell. Investigating the BTS-to-SGSN traffic, I saw that the frames sent by the SGSN were all marked with the same N(U) value (at LLC layer), the value was 0. With some debug, I found that the there was a mismatch in the TLLI storage, used to keep the status of attached terminals. The mentioned code is contained in gprs_llc.c, involving LL Entity functions and gprs_llc_tx_ui(). /* look-up or create the LL Entity for this (TLLI, SAPI) tuple */ lle = lle_by_tlli_sapi(msgb_tlli(msg), sapi); if (!lle) { struct gprs_llc_llme *llme; LOGP(DLLC, LOGL_ERROR, "LLC TX: unknown TLLI 0x%08x, " "creating LLME on the fly\n", msgb_tlli(msg)); llme = llme_alloc(msgb_tlli(msg)); lle = &llme->lle[sapi]; } The TX function uses the previously received TLLI to lookup for the LLE. The lle_by_tlli_sapi() performs the search, but preliminary it applies a foreign2local TLLI conversion to ensure to have a local one. Since no valid entry for the searched TLLI is found, a new one is created. And the problem is here. The new entry has the foreign TLLI. Next time the lookup fails again, and a new entry is created. This way, the counter N(U) is always reset, and the mobile do not recognize the message sequence and no attach is possible. My question is about foreign and local TLLIs. I patched the lookup, avoiding the conversion, so that the LLE is found and everything works fine... but... What is the sense of the conversion? Should the TLLI be always stored as a local one? Can this problem be solved with another foreign2local while allocating new entries? Actually, my problem has been solved with that workaround. But I'm curious to know what is the right way. Hope somebody can answer :) Thanks. Cheers, LM

5 6

OsmoNITB timeslots configuration and UmTRX
by Родион Гадыршин 27 Jan '26

27 Jan '26

Hello, list. I have umtrx v2.1 and I have already built GSM and GPRS components. Now I want to know which way of configuring timeslots in osmobsc.cfn is the best. I want GPRS, calls and SMS work. My current configuration is: timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config SDCCH8 hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config PDCH hopping enabled 0 timeslot 5 phys_chan_config PDCH hopping enabled 0 timeslot 6 phys_chan_config PDCH hopping enabled 0 timeslot 7 phys_chan_config PDCH hopping enabled 0 Is there a better way to configure? Maybe better use TCH/F_TCH/H_PDCH, but I have heard, that TCH/F is currently not working in dynamic configurations - only TCH/H does. And there is no only TCH/H_PDCH mode. So, could you please give me an advice?

3 2

Pysim error: SW match failed
by Martin Nagy 16 Aug '25

16 Aug '25

Hi all, After buying a super Sim Kit (16 in 1) from China, I tried the reader (green PCB inside a blue transparent plastic case with a blue LED) and SIM (identified as a fakesupersim) with pysim tool. However i am getting the following error: /pySim-prog.py -n 26C3 -c 49 -x 262 -y 42 -z 1234 -j 1 -t auto Insert card now (or CTRL-C to cancel) Autodetected card type fakemagicsim Generated card parameters : > Name : 26C3 > SMSP : e1ffffffffffffffffffffffff058100945555ffffffffffff000000 > ICCID : 8949262427518313026 > MCC/MNC : 262/42 > IMSI : 262422461512085 > Ki : 7b74741a1ee14337ec23f9ab92a13648 > OPC : ccd867d60797d8d45354a51b3ef568ff Programming ... Traceback (most recent call last): File "./pySim-prog.py", line 530, in <module> card.program(cp) File "/home/nadicek/pysim/pysim/pySim/cards.py", line 231, in program self._scc.update_binary('6f30', hplmn + 'ff' * (tl-3)) File "/home/nadicek/pysim/pysim/pySim/commands.py", line 53, in update_binary return self._tp.send_apdu_checksw(pdu) File "/home/nadicek/pysim/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1])) RuntimeError: SW match failed ! Expected 9000 and got 9804. I checked mailing lists and haven’t found anybody who had similar problem with pysim. Also I have tried forcing different models of SIM, but nothing is working. Obviously I can remove this check from the script file (__init__.py in /pySim/transport), however somebody had a reason to put such condition there. I would like to ask if it is safe to remove that line of code and the purpose of that line of code. Thanks a lot and best regards Martin

3 3

Re: Help with sccp library
by mosbah abdelkader 07 Jul '25

07 Jul '25

> I don't understand. This callback will be called with data you need to write > to the network. In case of MTP Level3 you will need to wrap that around the > msgb you got. I means: is the interaction with mtp3 layer implemented (is sending sccp data by mtp3 implemented by the library?)? Also, what about the reception of data from mtp3 layer. is that implemented in the sccp lib. I am asking these questions because I see the code of mtp3 in the lib but no significant call is present in the sccp part of the lib. Thank you for your help.

4 3

dynamic traffic channels
by Neels Hofmeyr 20 May '25

20 May '25

On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote: > [translated from german] > is it certain that we switch a channel to PDCH only when > gprs mode != none? A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we send a PDCH ACT message. We send a PDCH ACT message - during init (CHANNEL OML's state changed to enabled -> send PDCH ACT), - and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH. So the question is, when we receive a channel release ack, could that be the PDCH release and we switch PDCH right back on by accident? No, because we only receive a chan rel ack when the *TCH/F* is being released. That is because the PDCH release is initiated "internally" from the PDCH DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches on, which existed before dyn PDCH: if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) { LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n", gsm_lchan_name(lchan)); return 0; } In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but not in the rsl_rx_dyn_pdch(). This is analogous to the ip.access way -- the ip.access nanobts replies to a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel release ack. Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH for clarity? (But we shouldn't actually send a release ack, to stay compatible.) Even though it works as-is, we should indeed add another flag check: - We do check the flags that no ACT/DEACT is already pending; - And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE; - But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE. This should never happen, but it would make sense to ensure that. ~Neels

3 5

GSM 04.08 L2 pseudo length in ACCH System Information messages
by Vadim Yanitskiy 12 Mar '18

12 Mar '18

Hi everyone, I few days ago, during some usual R&D process, I noticed the following messages, appearing in the log output of OsmocomBB/mobile application: "ACCH message type 0xXX unknown." The network, a phone was connected to, was may own and based on more or less recent versions of OsmoNiTB, OsmoBTS, and OsmoTRX. Despite I used to see such messages before, I didn't pay too much attention. But this time I've decided to figure out, what's wrong there... The source of such messages is the gsm48_rr.c / gsm48_rr_rx_acch(): static int gsm48_rr_rx_acch(struct osmocom_ms *ms, struct msgb *msg) { // ... struct gsm48_system_information_type_header *sih = msgb_l3(msg); // ... switch (sih->system_information) { case GSM48_MT_RR_SYSINFO_5: return gsm48_rr_rx_sysinfo5(ms, msg); case GSM48_MT_RR_SYSINFO_5bis: return gsm48_rr_rx_sysinfo5bis(ms, msg); case GSM48_MT_RR_SYSINFO_5ter: return gsm48_rr_rx_sysinfo5ter(ms, msg); case GSM48_MT_RR_SYSINFO_6: return gsm48_rr_rx_sysinfo6(ms, msg); default: LOGP(DRR, LOGL_NOTICE, "ACCH message type 0x%02x unknown.\n", sih->system_information); return -EINVAL; } } To get I bit more details, I modified this function to print the whole L3 payload, and got some interesting results. As it turned out, the payloads were shifted one byte left - there was no 'l2_plen', which is assumed by: /* Section 9.1.3x System information Type header */ struct gsm48_system_information_type_header { uint8_t l2_plen; uint8_t rr_protocol_discriminator :4, skip_indicator:4; uint8_t system_information; } __attribute__ ((packed)); So, my first idea was that this is a bug of OsmocomBB, that would be fairly easy to fix, so after a quick look at the GSM 04.08 specification I wrote (and merged :/) this: https://gerrit.osmocom.org/#/c/5204/ And everything was great, until I connected a 'patched' mobile to a commercial mobile network... And all SI messages during a dedicated connection were false-identified as SI5ter. This seemed strange to me, so I decided to compare a SI message from commercial network with a message captured in my own one: https://habrastorage.org/webt/t8/zs/vv/t8zsvvjjglzfisnjqlnnsy4kgas.png And this confused me even more, then I've expected. Why there is 0x49? Wireshark false-identified this message as something related to SMS... What if this is exactly the 'l2_plen' assumed in OsmocomBB before? I looked at the specifications again, and found out that initially I refered an outdated 5.3.0 version, which was the first link in Google: http://www.etsi.org/deliver/etsi_gts/04/0408/05.03.00_60/gsmts_0408v050300p… while the latest one is 7.21.0: http://www.etsi.org/deliver/etsi_ts/100900_100999/100940/07.21.00_60/ts_100… So, I compared the 9.1.37-40 sections of both versions, and bingo! In the higher version ACCH System Information messages do have the 'L2 Pseudo Length' (10.5.2.19) field. Finally, what I've learned: - OsmocomBB / mobile follows the new version here (with l2_plen); - OsmoNiTB generates the ACCH SI messages without the l2_plen; - Recent Wireshark versions fail to decode the ACCH SI messages with l2_plen, while older ones are able to do that; - I should not merge the changes so quick. My questions are: - Which way of composing the SI messages is correct? - If both are correct, how to parse them correctly? - Should we change OsmoNiTB / OsmoBSC to follow the latest specs? And of course, I have to revert the change I've merged. With best regards, Vadim Yanitskiy.

2 1

Submissions for OsmoDevCon 2018
by Harald Welte 04 Mar '18

04 Mar '18

Dear Osmocom community, it's already end of January and OsmoDevCon 2018 in April is getting closer and closer. As indicated before, I would like to group the topics by days and put together at least a rough framework shcedule, so that people with specific interests don't have to be present for four full days to make sure they don't miss anything. So I'd like to re-invite all attendees to consider adding a topic/porposal to the wiki page at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2018#section-9 so that we can group different topic areas and put together a rough schedule outline. A proposal doesn't mean you have to give a talk. It could be anything, including * a talk that you would want to listen to, and you're looking for somebody to give it * a discussion about a certain topic * a workshop / hands on session * lightning talks? Like any community event, OsmoDevCon lives by its contributors. I can't wait to hear about all the things you've been up to. Thanks! 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)

1 1

Approach to system testing for Osmocom stack
by Holger Freyther 25 Feb '18

25 Feb '18

Hi, the lua binding code was added to be able to automate OpenBSC tests. In theory we should be able to do this for SMS and UpdateLocation (call handling with MNCC exposing is left as a todo) but in practice we miss a piece of software to coordinate this and run the test. We miss it because it is an interesting problem but also I lost time on switching countries, learning new tricks at a project... The basic testing structure looks easy as well. We want to define the number of concurrent subscribers (0, 10, 100, 1000, n) and to make it simple a single test (UL, send SMS, t) and execute the same test for each subscriber and call it a success if y% of tests succeed within time T. The way to measure this is easy as well. The lua script would print some data (e.g. the name of the ms) when it starts and completes. For some degrees of freedom I don't have a good idea.. and feedback is welcome. I am not sure if I should spawn, configure, add subscribers, a flavor of Osmocom cellular? I look into having some set of templates for the config, the stack to launch and in concept it looks awfully similar to something the GSM tester is doing. Shall we leave virtbts/cellular to the Osmocom tester and just focus on coordinating mobile? My feeling is to leave this to the Osmo GSM tester. If we have n subscribers I would launch m copies of "mobile" (but run multiple MS in a single binary). So with 4 MS per mobile process and 10k subs we would end with 2.5k processes + many log messages coming from each. Would that scale with python? Should we look into doing this one in Go? Or can some of GSM tester be used (the template part)? I would probably design this concurrently with Go(besides being the first). any ideas/comments? holger

4 12

fairwaves HO patches
by Neels Hofmeyr 23 Feb '18

23 Feb '18

Hi Ivan, as I'm working towards load-based handover and incorporating your patches, I found that most of it is concerned with libmsc. In contrast, I am currently working on osmo-bsc, in libbsc, and would like to ask your advice. Some parts of the patch aren't easy to understand for me, and I'd like to make sure that I am not dismissing parts of it as non-applicable to libbsc even though they might be important. Since your patches were written, the code has changed. Now that we have the separate osmo-bsc, we will need two layers of handover: intra-BSC and inter-BSC. Intra-BSC is a handover between two cells that are serviced by the same BSC, and the higher layers (MSC) should not even notice that anything has happened -- MSC has asked the BSC to service a call by BSSAP Assignment, and the BSC is free to choose and change around the lchans it assigns to that. That is the layer I'm currently dug into. Inter-BSC is a handover between cells that are serviced by two different BSCs. That seems to be the land your patch is improving. The MSC is involved and so is MNCC. (Both MSC and BSC levels will need their own DTAP cache, and they are by definition completely independent -- MSC caches the DTAP coming from MNCC during Inter-BSC handover, BSC caches DTAP from MSC during Intra-BSC handover.) Since your patch is applied onto openbsc.git, where all of BSC and MSC are still one osmo-nitb, I want to make sure that I sort your patch right. Do some of its semantics apply to osmo-bsc master, even if the code changed? The smaller patches are either already applied to osmo-bsc master, or I've submitted them on gerrit just now: handover_decision: Add more log messages to get more information about HO causes in logs handover_decision: Fix condition for power budget handover attempt handover_logic: set correct link to bts for subscriber_connection in case of moving this connection to another bts Remaining are a small and *the* complex one: transaction: Add new function trans_find_by_lchan handover: Implement proper handover procedure handling at any stage of the call Here is the last one with inline questions, I hope they are not too stupid; or too long, it ended up being a lot to read. Thanks in advance for taking a look: > commit f7f4dc5e3b0dd61b8322946597147baef5d0464b > Author: Ivan Kluchnikov <kluchnikovi(a)gmail.com> > Date: Wed Aug 23 18:09:50 2017 +0300 > > handover: Implement proper handover procedure handling at any stage of the call > > Enhancements for each stage of handover procedure should be implemented in order to support handover at any stage of the call. > For these purposes new in_handover state and ho_queue for call control messages was introduced for gsm_subscriber_connection. > > Stage 1: HO-Command is sent to MS > gsm_subscriber_connection state should be changed to in_handover=1. > In this state all transmission of signalling layer messages (except RR messages needed for handover procedure) > should be suspended until resuming is indicated. > All call control messages for connection received from network side should be buffered in ho_queue. > All call control messages for connection received from MS side should be ignored. > Channel mode modification procedures should be also suspended. > > Stage 2: HO-Detect is received from MS > Audio path should be switched on network side. > > Stage 3-1: HO-Complete is received from MS > Resumption procedure after successful handover should be performed: > - gsm_subscriber_connection state should be changed to normal (in_handover=0). > - all buffered call control messages (ho_queue) should be sent to MS on new lchan. > - suspended channel mode modification procedures should be performed on new lchan. > > Stage 3-2: HO-Fail is received from MS > Resumption procedure after failed handover should be performed: > - gsm_subscriber_connection state should be changed to normal (in_handover=0). > - all buffered call control messages (ho_queue) should be sent to MS on old lchan. > - suspended channel mode modification procedures should be performed on old lchan. > > Stage 3-3: T3103 expired: Handover has failed without HO-Complete or HO-Fail > Resumption procedure should not be performed in case of T3103 expired: > - gsm_subscriber_connection state should be changed to normal (in_handover=0). > - all buffered call control messages (ho_queue) should be cleaned without sending them to MS. > - suspended channel mode modification procedures should not be performed. > > Change-Id: Icb9b5c35ef0c894af2ea762e539f1a9216447fb7 > > diff --git a/openbsc/include/openbsc/bsc_api.h b/openbsc/include/openbsc/bsc_api.h > index 3a931199..baacbeda 100644 > --- a/openbsc/include/openbsc/bsc_api.h > +++ b/openbsc/include/openbsc/bsc_api.h > @@ -51,5 +51,6 @@ int gsm0808_cipher_mode(struct gsm_subscriber_connection *conn, int cipher, > int gsm0808_page(struct gsm_bts *bts, unsigned int page_group, > unsigned int mi_len, uint8_t *mi, int chan_type); > int gsm0808_clear(struct gsm_subscriber_connection *conn); > +int gsm0808_ho_clear(struct gsm_subscriber_connection *conn); > > #endif > diff --git a/openbsc/include/openbsc/gsm_data.h b/openbsc/include/openbsc/gsm_data.h > index ac573c49..542b2611 100644 > --- a/openbsc/include/openbsc/gsm_data.h > +++ b/openbsc/include/openbsc/gsm_data.h > @@ -138,6 +138,8 @@ struct gsm_subscriber_connection { > struct gsm_network *network; > > int in_release; > + int in_handover; > + struct llist_head ho_queue; > struct gsm_lchan *lchan; /* BSC */ > struct gsm_lchan *ho_lchan; /* BSC */ > struct gsm_bts *bts; /* BSC */ > diff --git a/openbsc/src/libbsc/bsc_api.c b/openbsc/src/libbsc/bsc_api.c > index 8a4c85ff..71e82d03 100644 > --- a/openbsc/src/libbsc/bsc_api.c > +++ b/openbsc/src/libbsc/bsc_api.c > @@ -253,11 +253,14 @@ struct gsm_subscriber_connection *bsc_subscr_con_allocate(struct gsm_lchan *lcha > conn->bts = lchan->ts->trx->bts; > lchan->conn = conn; > llist_add_tail(&conn->entry, &net->subscr_conns); > + INIT_LLIST_HEAD(&conn->ho_queue); > return conn; > } > > void bsc_subscr_con_free(struct gsm_subscriber_connection *conn) > { > + struct msgb *msg; > + > if (!conn) > return; > > @@ -283,6 +286,11 @@ void bsc_subscr_con_free(struct gsm_subscriber_connection *conn) > conn->secondary_lchan->conn = NULL; > } > > + while (!llist_empty(&conn->ho_queue)) { > + msg = msgb_dequeue(&conn->ho_queue); > + msgb_free(msg); > + } > + > llist_del(&conn->entry); > talloc_free(conn); > } > @@ -747,6 +755,17 @@ int gsm0808_clear(struct gsm_subscriber_connection *conn) > return 0; > } > > +/* > + * Release handover RF Channel. > + */ > +int gsm0808_ho_clear(struct gsm_subscriber_connection *conn) > +{ > + if (conn->ho_lchan) > + bsc_clear_handover(conn, 1); > + > + return 0; > +} > + > static void send_sapi_reject(struct gsm_subscriber_connection *conn, int link_id) > { > struct bsc_api *api; > diff --git a/openbsc/src/libbsc/handover_logic.c b/openbsc/src/libbsc/handover_logic.c > index af4e8013..b7085c34 100644 > --- a/openbsc/src/libbsc/handover_logic.c > +++ b/openbsc/src/libbsc/handover_logic.c > @@ -186,10 +186,17 @@ static void ho_T3103_cb(void *_ho) > { > struct bsc_handover *ho = _ho; > struct gsm_network *net = ho->new_lchan->ts->trx->bts->network; > + struct msgb *msg; > > DEBUGP(DHO, "HO T3103 expired\n"); > rate_ctr_inc(&net->bsc_ctrs->ctr[BSC_CTR_HANDOVER_TIMEOUT]); > > + ho->new_lchan->conn->in_handover = 0; > + while (!llist_empty(&ho->new_lchan->conn->ho_queue)) { > + msg = msgb_dequeue(&ho->new_lchan->conn->ho_queue); > + msgb_free(msg); > + } > + (Your ho_queue seems to live in libbsc, while most of the patch seems to be concerned with libmsc. But nevermind, from jolly's patches I already have a similar queue in osmo-bsc, and we'll probably use yours for libmsc.) > ho->new_lchan->conn->ho_lchan = NULL; > ho->new_lchan->conn = NULL; > lchan_release(ho->new_lchan, 0, RSL_REL_LOCAL_END); > @@ -214,6 +221,8 @@ static int ho_chan_activ_ack(struct gsm_lchan *new_lchan) > > gsm48_send_ho_cmd(ho->old_lchan, new_lchan, 0, ho->ho_ref); > > + new_lchan->conn->in_handover = 1; > + In current osmo-bsc master, we already set conn->ho_lchan before sending out the chan activation request. I'd actually assume setting the flag only now, after the activ ack, is a bit too late? > /* start T3103. We can continue either with T3103 expiration, > * 04.08 HANDOVER COMPLETE or 04.08 HANDOVER FAIL */ > ho->T3103.cb = ho_T3103_cb; > @@ -221,7 +230,8 @@ static int ho_chan_activ_ack(struct gsm_lchan *new_lchan) > osmo_timer_schedule(&ho->T3103, 10, 0); > > /* create a RTP connection */ > - if (is_ipaccess_bts(new_lchan->ts->trx->bts)) > + if (is_ipaccess_bts(new_lchan->ts->trx->bts) && > + new_lchan->tch_mode != GSM48_CMODE_SIGN) > rsl_ipacc_crcx(new_lchan); Please explain ... what case / behavior is this fixing? Do we ever see CMODE_SIGN handovers? Would we also need to check for GSM48_CMODE_DATA_*? > @@ -273,6 +283,11 @@ static int ho_gsm48_ho_compl(struct gsm_lchan *new_lchan) > if (is_e1_bts(new_lchan->conn->bts)) > switch_trau_mux(ho->old_lchan, new_lchan); > > + if (ho->old_lchan->conn->mncc_rtp_connect_pending) { > + new_lchan->abis_ip.connect_port = ho->old_lchan->abis_ip.connect_port; > + new_lchan->abis_ip.connect_ip = ho->old_lchan->abis_ip.connect_ip; > + } > + So if an RTP connect to MNCC is pending, we copy the old lchan's RTP port and IP? Which is this, the MNCC / call router side IP and port? Why not set this at the initiation of the HO already? > @@ -295,27 +310,9 @@ static int ho_gsm48_ho_compl(struct gsm_lchan *new_lchan) > static int ho_gsm48_ho_fail(struct gsm_lchan *old_lchan) > { > struct gsm_network *net = old_lchan->ts->trx->bts->network; > - struct bsc_handover *ho; > - struct gsm_lchan *new_lchan; > - > - ho = bsc_ho_by_old_lchan(old_lchan); > - if (!ho) { > - LOGP(DHO, LOGL_ERROR, "unable to find HO record\n"); > - return -ENODEV; > - } > > rate_ctr_inc(&net->bsc_ctrs->ctr[BSC_CTR_HANDOVER_FAILED]); > > - new_lchan = ho->new_lchan; > - > - /* release the channel and forget about it */ > - ho->new_lchan->conn->ho_lchan = NULL; > - ho->new_lchan->conn = NULL; > - handover_free(ho); > - > - lchan_release(new_lchan, 0, RSL_REL_LOCAL_END); > - > - I'm puzzled by this removal. No actions during ho_fail? Is this really intended, or just some rebase artifact? > return 0; > } > > diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c > index e5402d0a..84338d72 100644 > --- a/openbsc/src/libmsc/gsm_04_08.c > +++ b/openbsc/src/libmsc/gsm_04_08.c > @@ -147,6 +147,15 @@ static int gsm48_conn_sendmsg(struct msgb *msg, struct gsm_subscriber_connection > sign_link->trx->bts->nr, > sign_link->trx->nr, msg->lchan->ts->nr, > gh->proto_discr, gh->msg_type); > + > + if (conn->in_handover) { > + msgb_enqueue(&conn->ho_queue, msg); > + DEBUGP(DCC, "(bts %d trx %d ts %d) Suspend message sending to MS, " > + "active HO procedure.\n", > + sign_link->trx->bts->nr, > + sign_link->trx->nr, msg->lchan->ts->nr); > + return 0; > + } (here DTAP handled in libmsc ends up in the ho_queue that otherwise seems to live in libbsc ... as I said above this queue will probably move to libmsc altogether to become part of osmo-msc master.) > } > > return gsm0808_submit_dtap(conn, msg, 0, 0); > @@ -1749,11 +1758,8 @@ static int switch_for_handover(struct gsm_lchan *old_lchan, > struct rtp_socket *old_rs, *new_rs, *other_rs; > > /* Ask the new socket to send to the already known port. */ > - if (new_lchan->conn->mncc_rtp_bridge) { > - LOGP(DHO, LOGL_DEBUG, "Forwarding RTP\n"); > - rsl_ipacc_mdcx(new_lchan, > - old_lchan->abis_ip.connect_ip, > - old_lchan->abis_ip.connect_port, 0); > + if (new_lchan->ts->trx->bts->network->mncc_state) { > + /* Audio path should be switched after receiving ho detect message.*/ > return 0; > } I notice that in the current head, the entire switch_for_handover() has been dropped; it was doing libbsc lchan stuff from within libmsc. Hence we must have added similar logic in osmo-bsc.git and completely dropped this. I think the commit re-implementing handover in osmo-bsc is http://git.osmocom.org/osmo-bsc/commit/?id=39c609b7c924524172ad311bdf89f92b… It appears that lchan->abis_ip.connect_ip and connect_port aren't used at all in osmo-bsc master, but are still present in the struct. I'll ask others about that. In any case, the code base has changed substantially, and this patch hunk no longer applies at all. Am I interpreting this hunk correctly: it moves the ipacc_mdcx to tell the new lchan about its RTP peer to a later stage? In current osmo-bsc master, it seems that this ipacc_mdcx happens as soon as the ipacc_crcx is complete, seen in osmo-bsc/src/osmo-bsc/osmo_bsc_audio.c in handle_abisip_signal(), always using the IP:port the MSC sent us. > > @@ -1821,8 +1827,10 @@ static int handle_abisip_signal(unsigned int subsys, unsigned int signal, > if (subsys != SS_ABISIP) > return 0; > > + net = lchan->ts->trx->bts->network; > + > /* RTP bridge handling */ > - if (lchan->conn && lchan->conn->mncc_rtp_bridge) > + if (lchan->conn && net->mncc_state) > return tch_rtp_signal(lchan, signal); What are the semantics here? It seems odd to move from a check of a conn-specific state (conn->mncc_rtp_bridge) to a check of a global value (net->mncc_state). In any case, this is MNCC related and should not impact Intra-BSC handover, right? > > /* in case we use direct BTS-to-BTS RTP */ > @@ -1851,7 +1859,6 @@ static int handle_abisip_signal(unsigned int subsys, unsigned int signal, > > /* check if any transactions on this lchan still have > * a tch_recv_mncc request pending */ > - net = lchan->ts->trx->bts->network; > llist_for_each_entry(trans, &net->trans_list, entry) { > if (trans->conn && trans->conn->lchan == lchan && trans->tch_recv) { > DEBUGP(DCC, "pending tch_recv_mncc request\n"); > @@ -2017,6 +2024,13 @@ static int tch_recv_mncc(struct gsm_network *net, uint32_t callref, int enable) > switch (bts->type) { > case GSM_BTS_TYPE_NANOBTS: > case GSM_BTS_TYPE_OSMO_SYSMO: > if (ipacc_rtp_direct) { > LOGP(DCC, LOGL_ERROR, "Error: RTP proxy is disabled\n"); > return -EINVAL; > } > + /* RTP bridge handling */ > + if (lchan->conn && net->mncc_state) { > + return 0; > + } If we have a conn and using external MNCC, don't continue at all? I'm not following, would be nice if the comment explained why we need to drop out here. (added some more code context manually) > /* In case, we don't have a RTP socket to the BTS yet, the BTS > * will not be connected to our RTP proxy and the socket will > * not be assigned to the application interface. This method > * will be called again, once the audio socket is created and > * connected. */ > if (!lchan->abis_ip.rtp_socket) { > DEBUGP(DCC, "queue tch_recv_mncc request (%d)\n", enable); > return 0; > } > if (enable) { > /* connect the TCH's to our RTP proxy */ > rc = rsl_ipacc_mdcx_to_rtpsock(lchan); > if (rc < 0) > return rc; > /* assign socket to application interface */ > rtp_socket_upstream(lchan->abis_ip.rtp_socket, > net, callref); > } else > rtp_socket_upstream(lchan->abis_ip.rtp_socket, > net, 0); > break; > > @@ -3325,6 +3339,41 @@ static void mncc_recv_rtp_err(struct gsm_network *net, uint32_t callref, int cmd > return mncc_recv_rtp(net, callref, cmd, 0, 0, 0, 0); > } > > +static void mncc_recv_rtp_modify(struct gsm_lchan *lchan, uint32_t callref) This is to tell the call router that the payload type has changed, right? I've asked in the redmine about whether/how we'd convey an RTP payload change to the MNCC in case of an Intra-BSC handover... https://osmocom.org/issues/1606#note-45 > +{ > + int msg_type; > + struct gsm_network *net = lchan->ts->trx->bts->network; > + > + LOGP(DMNCC, LOGL_NOTICE, "%s sending pending RTP modify ind.\n", > + gsm_lchan_name(lchan)); > + > + switch (lchan->abis_ip.rtp_payload) { > + case RTP_PT_GSM_FULL: > + msg_type = GSM_TCHF_FRAME; > + break; > + case RTP_PT_GSM_EFR: > + msg_type = GSM_TCHF_FRAME_EFR; > + break; > + case RTP_PT_GSM_HALF: > + msg_type = GSM_TCHH_FRAME; > + break; > + case RTP_PT_AMR: > + msg_type = GSM_TCH_FRAME_AMR; > + break; > + default: > + LOGP(DMNCC, LOGL_ERROR, "%s unknown payload type %d\n", > + gsm_lchan_name(lchan), lchan->abis_ip.rtp_payload); > + msg_type = 0; > + break; > + } > + > + mncc_recv_rtp(net, callref, MNCC_RTP_MODIFY, > + lchan->abis_ip.bound_ip, > + lchan->abis_ip.bound_port, > + lchan->abis_ip.rtp_payload, > + msg_type); > +} > + > static int tch_rtp_create(struct gsm_network *net, uint32_t callref) > { > struct gsm_bts *bts; > @@ -3374,6 +3423,9 @@ static int tch_rtp_create(struct gsm_network *net, uint32_t callref) > LOGP(DMNCC, LOGL_DEBUG, "RTP create: codec=%s, chan_type=%s\n", > get_value_string(gsm48_chan_mode_names, m), > get_value_string(gsm_chan_t_names, lchan->type)); > + if (trans->conn->in_handover) { > + return 0; > + } Am I reading right: if we're doing handover, the MSC shouldn't sent another BSSAP Assignment to the BSC; instead, the BSC level figures out another lchan and done ... ? > return gsm0808_assign_req(trans->conn, m, > lchan->type != GSM_LCHAN_TCH_H); > } > @@ -3420,23 +3472,21 @@ static int tch_rtp_connect(struct gsm_network *net, void *arg) > * same package! > */ > trans->conn->mncc_rtp_connect_pending = 1; > + if (trans->conn->in_handover) { > + lchan->abis_ip.connect_port = rtp->port; > + lchan->abis_ip.connect_ip = rtp->ip; > + return 0; > + } > return rsl_ipacc_mdcx(lchan, rtp->ip, rtp->port, 0); We're not telling the BTS about the call router's IP:port anymore? Please explain... > } > > static int tch_rtp_signal(struct gsm_lchan *lchan, int signal) > { > struct gsm_network *net; > - struct gsm_trans *tmp, *trans = NULL; > + struct gsm_trans *trans; > > net = lchan->ts->trx->bts->network; > - llist_for_each_entry(tmp, &net->trans_list, entry) { > - if (!tmp->conn) > - continue; > - if (tmp->conn->lchan != lchan && tmp->conn->ho_lchan != lchan) > - continue; > - trans = tmp; > - break; > - } > + trans = trans_find_by_lchan(lchan); > > if (!trans) { > LOGP(DMNCC, LOGL_ERROR, "%s IPA abis signal but no transaction.\n", > @@ -3459,7 +3509,7 @@ static int tch_rtp_signal(struct gsm_lchan *lchan, int signal) > maybe_switch_for_handover(lchan); > break; > case S_ABISIP_MDCX_ACK: > - if (lchan->conn->mncc_rtp_connect_pending) { > + if (lchan->conn->mncc_rtp_connect_pending && !lchan->conn->in_handover) { if we're in handover, we don't need to tell MNCC that RTP got connected, because that already happened when the call got established initially? So mncc_rtp_connect_pending has a second meaning during handover? > lchan->conn->mncc_rtp_connect_pending = 0; > LOGP(DMNCC, LOGL_NOTICE, "%s sending pending RTP connect ind.\n", > gsm_lchan_name(lchan)); > mncc_recv_rtp_sock(net, trans, MNCC_RTP_CONNECT); > } > break; > @@ -3471,6 +3521,134 @@ static int tch_rtp_signal(struct gsm_lchan *lchan, int signal) > return 0; > } > > +static void ho_queue_clean(struct gsm_subscriber_connection *conn) > +{ > + struct msgb *msg; > + while (!llist_empty(&conn->ho_queue)) { > + msg = msgb_dequeue(&conn->ho_queue); > + msgb_free(msg); > + } > +} > + > +static void ho_resumption(struct gsm_lchan *lchan, struct gsm_trans *trans) > +{ > + struct msgb *msg; > + enum gsm48_chan_mode m; > + > + while (!llist_empty(&lchan->conn->ho_queue)) { > + msg = msgb_dequeue(&lchan->conn->ho_queue); > + gsm48_conn_sendmsg(msg, lchan->conn, trans); > + } > + > + if (trans->conn->mncc_rtp_create_pending && > + lchan->tch_mode == GSM48_CMODE_SIGN) { > + m = mncc_codec_for_mode(lchan->type); > + gsm0808_assign_req(lchan->conn, m, lchan->type != GSM_LCHAN_TCH_H); Wait, now we *do* send a BSSAP Assignment after all? (excuse if I'm being noob, I'm still finding my way through handover in general) shouldn't we rather dequeue the cached DTAP after this instead of before? > + } > + > + if (trans->conn->mncc_rtp_connect_pending) { > + rsl_ipacc_mdcx(lchan, lchan->abis_ip.connect_ip, lchan->abis_ip.connect_port, 0); > + } > +} > + > +static int ho_complete(struct gsm_lchan *new_lchan) > +{ > + struct gsm_trans *trans; > + > + new_lchan->conn->in_handover = 0; > + trans = trans_find_by_lchan(new_lchan); > + if (!trans) { > + LOGP(DHO, LOGL_ERROR, "%s HO detected, but no transaction for new_lchan.\n", > + gsm_lchan_name(new_lchan)); > + ho_queue_clean(new_lchan->conn); > + return 0; > + } > + > + ho_resumption(new_lchan, trans); > + return 0; > +} > + > +static int ho_fail(struct gsm_lchan *old_lchan) > +{ > + struct gsm_trans *trans; > + > + old_lchan->conn->in_handover = 0; > + trans = trans_find_by_lchan(old_lchan); > + if (trans) > + ho_resumption(old_lchan, trans); > + else { > + LOGP(DHO, LOGL_ERROR, "%s HO fail, but no transaction for old_lchan.\n", > + gsm_lchan_name(old_lchan)); > + ho_queue_clean(old_lchan->conn); > + } > + > + gsm0808_ho_clear(old_lchan->conn); > + return 0; > +} > + > +static int ho_detect(struct gsm_lchan *new_lchan) > +{ > + struct gsm_trans *trans; > + struct gsm_lchan *old_lchan; > + > + trans = trans_find_by_lchan(new_lchan); > + > + if (!trans) { > + LOGP(DHO, LOGL_ERROR, "%s HO detected, but no transaction for new_lchan" > + " with enabled tch_recv.\n", > + gsm_lchan_name(new_lchan)); > + return 0; > + } > + > + if (!new_lchan->conn->mncc_rtp_bridge) { > + LOGP(DHO, LOGL_ERROR, "%s HO detected, but connection not in mncc_rtp_bridge mode.\n", > + gsm_lchan_name(new_lchan)); > + return 0; > + } > + > + old_lchan = bsc_handover_pending(new_lchan); > + if (!old_lchan) { > + LOGP(DHO, LOGL_ERROR, "%s HO detected, but no old_lchan for handover.\n", > + gsm_lchan_name(new_lchan)); > + return 0; > + } > + > + LOGP(DHO, LOGL_DEBUG, "HO detected, forwarding RTP\n"); > + rsl_ipacc_mdcx(new_lchan, > + old_lchan->abis_ip.connect_ip, > + old_lchan->abis_ip.connect_port, 0); > + > + mncc_recv_rtp_modify(new_lchan, trans->callref); > + > + return 0; > +} > + > +/* some other part of the code sends us a signal */ > +static int handle_lchan_signal(unsigned int subsys, unsigned int signal, > + void *handler_data, void *signal_data) > +{ > + struct lchan_signal_data *lchan_data; > + struct gsm_lchan *lchan; > + > + lchan_data = signal_data; > + switch (subsys) { > + case SS_LCHAN: > + lchan = lchan_data->lchan; > + if (!lchan->conn) > + return 0; > + switch (signal) { > + case S_LCHAN_HANDOVER_DETECT: > + return ho_detect(lchan); > + case S_LCHAN_HANDOVER_COMPL: > + return ho_complete(lchan); > + case S_LCHAN_HANDOVER_FAIL: > + return ho_fail(lchan); > + } > + break; > + } > + > + return 0; > +} > > static struct downstate { > uint32_t states; > @@ -3853,6 +4031,11 @@ static int gsm0408_rcv_cc(struct gsm_subscriber_connection *conn, struct msgb *m > gsm48_cc_msg_name(msg_type), trans?(trans->cc.state):0, > gsm48_cc_state_name(trans?(trans->cc.state):0)); > > + if (conn->in_handover) { > + DEBUGP(DCC, "Message unhandled, handover procedure.\n"); > + return 0; > + } > + If in handover, drop all CC on the floor? How about a call release, i.e. I hang up while I'm coincidentally being handovered? > /* Create transaction */ > if (!trans) { > DEBUGP(DCC, "Unknown transaction ID %x, " > > > Thanks again! ~N

3 4

grcardsim: fails with "bad echo value"
by Marek Sebera 31 Jan '18

31 Jan '18

Hi, sim card by identification ATR: 3B 9F 95 80 1F C3 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 A8 GREEN CARD, Grcard (Hong Kong ) Co.,Limited, LTE Usim Card (Telecommunication) Celcom Postpaid 3G (Telecommunication) when trying to program using ./pySim-prog.py -n OpenBSC -i 901700000003080 -c 001 -x 001 -y 02 -s 1791198229180000075 -d /dev/ttyUSB0 -a 58001006 -t grcardsim pySim-prog.py fails with following stacktrace Programming ... Traceback (most recent call last): File "./pySim-prog.py", line 636, in <module> card.program(cp) File "/home/username/pysim/pySim/cards.py", line 271, in program self._scc.verify_chv(5, pin) File "/home/username/pysim/pySim/commands.py", line 111, in verify_chv return self._tp.send_apdu_checksw(self.cla_byte + '2000' + ('%02X' % schv_no) + '08' + fc) File "/home/username/pysim/pySim/transport/__init__.py", line 85, in send_apdu_checksw rv = self.send_apdu(pdu) File "/home/username/pysim/pySim/transport/__init__.py", line 68, in send_apdu data, sw = self.send_apdu_raw(pdu) File "/home/username/pysim/pySim/transport/serial.py", line 202, in send_apdu_raw self._tx_string(pdu[5:]) File "/home/username/pysim/pySim/transport/serial.py", line 168, in _tx_string raise ProtocolError("Bad echo value (Expected: %s, got %s)" % (b2h(s), b2h(r))) pySim.exceptions.ProtocolError: Bad echo value (Expected: 33353338333033303331333033303336, got 3335333833303330333330333033366e) - using usb sim card reader which creates standard serial line on /dev/ttyUSB0 programming also fails when using Gemalto Ezio Shield ./pySim-prog.py -n OpenBSC -i 901700000003080 -c 001 -x 001 -y 02 -s 1791198229180000075 -p 0 -a 58001006 -t grcardsim fails with following stacktrace Programming ... Traceback (most recent call last): File "./pySim-prog.py", line 636, in <module> card.program(cp) File "/home/smarek/Documents/PROJEKTY/SECURITY/TELCO/SIMCARDS/pysim/pySim/cards.py", line 271, in program self._scc.verify_chv(5, pin) File "/home/smarek/Documents/PROJEKTY/SECURITY/TELCO/SIMCARDS/pysim/pySim/commands.py", line 111, in verify_chv return self._tp.send_apdu_checksw(self.cla_byte + '2000' + ('%02X' % chv_no) + '08' + fc) File "/home/smarek/Documents/PROJEKTY/SECURITY/TELCO/SIMCARDS/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1])) RuntimeError: SW match failed ! Expected 9000 and got 6b00. Thank you for your help MS

3 9

Pysim - "Unable to connect with protocol: T0 or T1. Card is unpowered."
by Osmocom Mailing List 31 Jan '18

31 Jan '18

Hey, I ordered a generic blank LTE SIM card from ebay. When I try to read it I get the following message. "Unable to connect with protocol: T0 or T1. Card is unpowered." Before you ask, no, the sim is not in the wrong position. Check the attached images. Am I doing something wrong or is the card faulty? The reader is working, I was able to read/write to a SuperSIM (X-sim) and it detected a bunch of commercial SIMs from local operators (wasn't able to read any SIM specific value but I think that's normal). I just want to know if I should open a report agains the seller. Images: https://imgur.com/a/jrtPL Here's the technical data: READER Model: Gemalto PC USB-TR (now, IDBridge CT30) Specifications: https://www.gemalto.com/products/pc_link_readers/index.html SIM (acording to ebay listing) Name: LTE Blank USIM Card SIM Card Size: Standard SIM Card,Micro SIM Card and Nano SIM Card, 3 in 1 Compatible: 4G FDD LTE WCDMA GSM Feature: Can be written ICCID, IMSI, KI, OPC . Application: For Telecommunications Operator Thanks, Filipe Laíns <https://github.com/FFY00> Sent via Migadu.com, world's easiest email hosting

2 1

[openbsc 1.0.0.14-98a2ba] testsuite: 4 failed
by Марат Узяков 31 Jan '18

31 Jan '18

Hi! Please help!

1 0

Help migrating away from NITB
by Rafael Diniz 23 Jan '18

23 Jan '18

Hi all, I'm starting to get used to the new stack with split components, and all seems to be working fine, SMS and USSD are working, but no voice calls yet. ps ax: 7611 pts/4 S+ 0:00 osmo-mgw -c osmo-mgw-for-bsc.cfg 7653 pts/6 S+ 0:00 osmo-bsc -c osmo-bsc.cfg 7705 pts/3 S+ 0:00 osmo-msc -c osmo-msc.cfg 7760 pts/8 S+ 0:00 osmo-mgw -c osmo-mgw-for-msc.cfg 7785 pts/0 Sl+ 1:59 osmo-trx 7803 pts/7 S+ 0:08 osmo-bts-trx -c osmo-bts.cfg 17288 pts/1 S+ 0:00 osmo-hlr -l hlr.db -c osmo-hlr.cfg 17299 pts/5 S+ 0:02 osmo-stp -c osmo-stp.cfg Config files are deeply based in the nitb.tar in the wiki. I read in an email from December that osmo-bsc_mgcp is still required. Is that the case? Thanks, Rafael Diniz

2 2

testing osmo-bsc osmo-hlr osmo-msc
by Sandi Suhendro 22 Jan '18

22 Jan '18

Hello guys. Im testing the osmo-bsc osmo-hlr osmo-msc. I can make call but sometimes cannot, also same with text message. now the auto create subscriber not working which is Im looking and its very good and nice improovement. I ussually using osmo-sip-connector with openbsc and asterisk, but since I read that osmo-msc handling the features and also for future osmocom GSM stacks, so Im trying to migrate and test it. does my setting for the osmocom stacks is right with this? : osmo-bsc -c ~/osmo/osmo-bsc.cfg osmo-hlr -l hlr.db -c ~/osmo/osmo-hlr.cfg osmo-stp -c ~/osmo/osmo-stp.cfg osmo-mgw -c ~/osmo/osmo-mgw-for-msc.cfg osmo-mgw -c ~/osmo/osmo-mgw-for-bsc.cfg osmo-msc -c ~/osmo/osmo-msc.cfg DId I miss something? Im sure I miss something. :-) and how to connect osmo-msc with asterisk? Thanks. -- Best Regards, DUO

2 2

Build failed in Jenkins: Coverity-Upload » linux_amd64_debian8 #1736
by jenkins＠lists.osmocom.org 22 Jan '18

22 Jan '18

See <http://jenkins.osmocom.org/jenkins/job/Coverity-Upload/label=linux_amd64_de…> ------------------------------------------ [...truncated 2.16 MB...] CC osmo-bts-sysmo/sysmo_l1_fwd.o CXXLD libgprs.la CXXLD osmo-pcu CXXLD osmo-pcu-remote make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' Making all in examples make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' Making all in tests make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' CXX pcu_emu.o CXX test_replay_gprs_attach.o CC openbsc_clone.o CXX test_pdp_activation.o CXXLD emu/pcu_emu make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[1]: Nothing to be done for 'all-am'. make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' + make install Making install in include make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' make[2]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/pcu' /usr/bin/install -c -m 644 osmocom/pcu/pcuif_proto.h '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/pcu' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' Making install in src make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin' /bin/sh ../libtool --mode=install /usr/bin/install -c osmo-pcu '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin' libtool: install: /usr/bin/install -c osmo-pcu /home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin/osmo-pcu make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' Making install in examples make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[2]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/etc/osmocom' /usr/bin/install -c -m 644 osmo-pcu.cfg '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/etc/osmocom' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' Making install in tests make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[2]: Nothing to be done for 'install-exec-am'. make[2]: Nothing to be done for 'install-data-am'. make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[2]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/pkgconfig' /usr/bin/install -c -m 644 osmo-pcu.pc '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/pkgconfig' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' + popd ~/osmo-ci/coverity/source-Osmocom + build_osmobts + pushd osmo-bts ~/osmo-ci/coverity/source-Osmocom/osmo-bts ~/osmo-ci/coverity/source-Osmocom + do_build --enable-sysmocom-bts --enable-trx + autoreconf --install --force libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. configure.ac:21: installing './compile' configure.ac:23: installing './config.guess' configure.ac:23: installing './config.sub' configure.ac:9: installing './install-sh' configure.ac:9: installing './missing' src/common/Makefile.am: installing './depcomp' src/osmo-bts-sysmo/Makefile.am:25: warning: bin_PROGRAMS was already defined in condition TRUE, which includes condition ENABLE_SYSMOBTS_CALIB ... src/osmo-bts-sysmo/Makefile.am:10: ... 'bin_PROGRAMS' previously defined here src/osmo-bts-sysmo/Makefile.am:12: warning: source file 'misc/sysmobts_par.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:12: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. src/osmo-bts-sysmo/Makefile.am:27: warning: source file 'misc/sysmobts-calib.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:27: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:27: warning: source file 'misc/sysmobts-layer1.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:27: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_misc.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_par.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_nl.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_2050.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_vty.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_nl.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_temp.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_calib.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:42: warning: source file 'misc/sysmobts_util.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:42: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:42: warning: source file 'misc/sysmobts_par.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:42: but option 'subdir-objects' is disabled tests/agch/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/agch/Makefile.am:7: but option 'subdir-objects' is disabled tests/cipher/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/cipher/Makefile.am:7: but option 'subdir-objects' is disabled tests/misc/Makefile.am:9: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/misc/Makefile.am:9: but option 'subdir-objects' is disabled tests/paging/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/paging/Makefile.am:7: but option 'subdir-objects' is disabled tests/power/Makefile.am:8: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/power/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/utils.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/l1_if.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/oml.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/l1_transp_hw.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/tch.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/calib_file.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/calib_fixup.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/misc/sysmobts_par.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/eeprom.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/tx_power/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/tx_power/Makefile.am:7: but option 'subdir-objects' is disabled + ./configure --prefix=/home/osmocom-build/osmo-ci/coverity/install-Osmocom --enable-sysmocom-bts --enable-trx checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking whether make sets $(MAKE)... (cached) yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for pkg-config... /usr/bin/pkg-config checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.20... yes checking for ANSI C header files... (cached) yes checking for LIBOSMOCORE... yes checking for LIBOSMOVTY... yes checking for LIBOSMOTRAU... yes checking for LIBOSMOGSM... yes checking for LIBOSMOCTRL... yes checking for LIBOSMOABIS... yes checking for LIBOSMOCODEC... yes checking for LIBOSMOCODING... yes checking for ORTP... yes checking whether to enable support for sysmobts calibration tool... no checking whether to enable support for sysmoBTS L1/PHY support... yes checking for sysmocom/femtobts/superfemto.h... no configure: error: sysmocom/femtobts/superfemto.h can not be found in . [WARNING] Build command ./build_Osmocom.sh exited with code 1. Please verify that the build completed successfully. Emitted 1913 C/C++ compilation units (100%) successfully 1913 C/C++ compilation units (100%) are ready for analysis For more details, please look at: /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt Build step 'Execute shell' marked build as failure

1 4

OSMO-TRX with OSMO-NITB and OSMO-BTS error
by Ronan Empig 22 Jan '18

22 Jan '18

Hi, I am using LimeSDR and I would like to setup a mini GSM base station. I am following this instructions: https://discourse.myriadrf.org/t/limesdr-osmo-trx-no-work/1938/27 However, I am getting trouble starting tranceiver: *TERMINAL 1:* ronan@ronan-MS-N014:~/Downloads$ osmo-nitb -c openbsc.cfg -l hlr.sqlite3 -P -C <0005> abis_nm.c:2800 (bts=0,trx=0) Changing adm. state Unlocked -> Unlocked [vty] <001e> telnet_interface.c:104 telnet at 127.0.0.1 4242 <0005> bsc_init.c:465 WARNING: You are running an 'accept-all' network on a BTS that is not barred. This configuration is likely to interfere with production GSM networks and should only be used in a RF shielded environment such as a faraday cage! <0020> input/ipaccess.c:848 enabling ipaccess BSC mode on 0.0.0.0 with OML 3002 and RSL 3003 TCP ports <0017> smpp_smsc.c:1001 SMPP at 0.0.0.0 2775 <0025> control_if.c:854 CTRL at 127.0.0.1 4249 DB: Database initialized. DB: Database prepared. <0020> input/ipa.c:263 accept()ed new link from 127.0.0.1 to port 3002 <0005> abis_nm.c:507 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix. <0005> abis_nm.c:507 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix. <0005> abis_nm.c:573 BTS0: ARI reported sw[0/2]: sysmobts is 0.7.0.20180115 <0005> abis_nm.c:446 BTS0 reported variant: omso-bts-trx <0005> abis_nm.c:468 BTS0 Attribute Manufacturer Dependent State is unreported <0005> abis_nm.c:573 BTS0: ARI reported sw[0/1]: TRX_PHY_VERSION is Unknown <0020> input/ipa.c:263 accept()ed new link from 127.0.0.1 to port 3003 <0004> bsc_init.c:311 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 514 using MCC=1 MNC=1 LAC=1 CID=0 BSIC=63 <0020> input/ipaccess.c:243 Sign link vanished, dead socket <0020> input/ipaccess.c:71 Forcing socket shutdown with no signal link set *TERMINAL 2:* ronan@ronan-MS-N014:~/Downloads$ osmo-bts-trx -c osmo-bts.cfg ((*)) | / \ OsmoBTS <0017> control_if.c:854 CTRL at 127.0.0.1 4238 <0010> telnet_interface.c:104 telnet at 127.0.0.1 4241 <0012> input/ipaccess.c:886 enabling ipaccess BTS mode, OML connecting to 127.0.0.1:3002 <000b> trx_if.c:599 Open transceiver for phy0.0 <0012> input/ipa.c:129 connection done. <0012> input/ipaccess.c:707 received ID get <0001> oml.c:229 O&M Get Attributes [0], Manufacturer Dependent State is unsupported by TRX. <0001> oml.c:680 Ignoring T200[0] (150 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:680 Ignoring T200[1] (180 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:680 Ignoring T200[2] (180 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:680 Ignoring T200[3] (1680 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:680 Ignoring T200[4] (520 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:680 Ignoring T200[5] (165 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:680 Ignoring T200[6] (1680 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:1049 ADM state already was Unlocked <0012> input/ipa.c:129 connection done. <0012> input/ipaccess.c:707 received ID get <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1108205-0=1108205 > 1! <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1108421-1108300=121 > 1! <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1108638-1108435=203 > 1! <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1108855-1108652=203 > 1! <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1109072-1108870=202 > 1! <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1109289-1109086=203 > 1! <0001> bts.c:210 Shutting down BTS 0, Reason No clock from osmo-trx <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1112227-1109693=2534 > 1! <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> bts.c:205 BTS is already being shutdown. <000b> trx_if.c:172 No response from transceiver for phy0.0 Shutdown timer expired ronan@ronan-MS-N014:~/Downloads$ *TERMINAL 3:* ronan@ronan-MS-N014:~/Downloads$ sudo osmo-trx -e [sudo] password for ronan: linux; GNU C++ version 5.4.0 20160609 <%2802%29%20016%200609>; Boost_105800; UHD_003.010.002.000-release Info: SSE3 support compiled in and supported by CPU Info: SSE4.1 support compiled in, but not supported by CPU Config Settings Log Level............... NOTICE Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 GSM Core Address.........127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 4 EDGE support............ Enabled Reference............... Internal C0 Filler Table......... Disabled Multi-Carrier........... Disabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 -- Make connection: 'LimeSDR-USB [USB 2.0] 9060B00470E28' -- Reference clock 30.720 MHz -- Device name: LimeSDR-USB -- Reference: 30.72 MHz -- Init LMS7002M(0) -- Ver=7, Rev=1, Mask=1 -- LMS7002M calibration values caching Disable -- Transceiver active with 1 channel(s) NOTICE 139639362156288 07:03:23.5 Transceiver.cpp:791:driveControl: Changing TSC from 0 to 7 NOTICE 139639362156288 07:03:23.5 Transceiver.cpp:244:start: Starting the transceiver ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=174420 time_end=171360 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=174420 time_end=171360 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=179520 time_end=176460 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=179520 time_end=176460 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=184620 time_end=181560 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=184620 time_end=181560 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=190740 time_end=186660 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=190740 time_end=186660 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=196860 time_end=192780 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=196860 time_end=192780 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=201960 time_end=198900 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=201960 time_end=198900 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=207060 time_end=204000 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=207060 time_end=204000 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=213180 time_end=209100 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=213180 time_end=209100 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=217260 time_end=215220 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=217260 time_end=215220 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=224400 time_end=219300 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=224400 time_end=219300 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=229500 time_end=226440 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=229500 time_end=226440 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=234600 time_end=231540 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=234600 time_end=231540 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=239700 time_end=236640 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=239700 time_end=236640 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=245820 time_end=241740 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=245820 time_end=241740 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=251940 time_end=247860 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=251940 time_end=247860 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=258060 time_end=253980 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=258060 time_end=253980 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=263160 time_end=260100 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=263160 time_end=260100 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=268260 time_end=265200 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=268260 time_end=265200 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=273360 time_end=270300 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=273360 time_end=270300 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=279480 time_end=275400 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=279480 time_end=275400 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=285600 time_end=281520 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=285600 time_end=281520 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=290700 time_end=287640 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=290700 time_end=287640 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=322320 time_end=292740 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=322320 time_end=292740 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=328440 time_end=324360 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=328440 time_end=324360 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=333540 time_end=330480 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=333540 time_end=330480 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=338640 time_end=335580 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=338640 time_end=335580 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=343740 time_end=340680 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=343740 time_end=340680 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=349860 time_end=345780 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=349860 time_end=345780 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=355980 time_end=351900 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=355980 time_end=351900 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=360060 time_end=358020 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=360060 time_end=358020 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=367200 time_end=362100 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=367200 time_end=362100 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=372300 time_end=369240 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=372300 time_end=369240 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=378420 time_end=374340 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=378420 time_end=374340 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=383520 time_end=380460 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=383520 time_end=380460 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=389640 time_end=385560 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=389640 time_end=385560 ALERT 139639362090752 07:03:24.5 UHDDevice.cpp:867:check_rx_md_err: UHD: Loss of monotonic time ALERT 139639362090752 07:03:24.5 UHDDevice.cpp:867:check_rx_md_err: UHD: Loss of monotonic time ALERT 139639362090752 07:03:24.5 UHDDevice.cpp:868:check_rx_md_err: Current time: 0, Previous time: 0.359668 ALERT 139639362090752 07:03:24.5 UHDDevice.cpp:868:check_rx_md_err: Current time: 0, Previous time: 0.359668 ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:867:check_rx_md_err: UHD: Loss of monotonic time ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:867:check_rx_md_err: UHD: Loss of monotonic time ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:868:check_rx_md_err: Current time: 0.120517, Previous time: 0.359668 ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:868:check_rx_md_err: Current time: 0.120517, Previous time: 0.359668 ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=399840 time_end=391680 ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=399840 time_end=391680 ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=410040 time_end=408000 ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=410040 time_end=408000 ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=415140 time_end=412080 ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=415140 time_end=412080 ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:867:check_rx_md_err: UHD: Loss of monotonic time ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:867:check_rx_md_err: UHD: Loss of monotonic time ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:868:check_rx_md_err: Current time: 0, Previous time: 0.383206 ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:868:check_rx_md_err: Current time: 0, Previous time: 0.383206 ERR 139639362090752 07:03:24.8 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=440640 time_end=417180 ERR 139639362090752 07:03:24.8 UHDDevice.cpp:1383:write: Skipping

5 11

osmo-trx with USRP1 - libusrp vs. UHD
by Alexander Huemer 21 Jan '18

21 Jan '18

Hi! I played with osmo-trx today and tried to run it with a USRP1 that I have laying around, though to no avail. osmo-trx supports two kinds of devices, USRP1 via libusrp and UHD. libusrp was last included in gnuradio 3.4.2[1] from Dec 2013, it unsurprisingly does not build on a recent Linux distribution, due to API incompatibilities with boost. The USRP1 would theoretically be supported by UHD, though the device initialization code in osmo-trx explicitly treats it differently, see [2,3]. I found an old ML post[4] from 2015 that pretty much asks the same question but did not get an answer. Supposedly there is a simple reason why USRP1 is not driven via UHD in osmo-trx, but I don't know. Can somebody please enlighten me? Tom, maybe you? I would like to understand whether it is feasible to use an USRP1 with UHD for osmo-trx or one would have to go down the rabbit hole to build libusrp on a modern system. Kind regards, -Alex [1] https://gnuradio.org/releases/gnuradio/ [2] https://git.osmocom.org/osmo-trx/tree/Transceiver52M/UHDDevice.cpp#n512 [3] https://git.osmocom.org/osmo-trx/tree/Transceiver52M/USRPDevice.cpp [4] https://lists.osmocom.org/pipermail/openbsc/2015-January/000058.html

5 14

libosmocore wiki page and doxygen online documentation
by Pau Espin Pedrol 18 Jan '18

18 Jan '18

Hi, I was trying to find if the doxygen documentation is uploaded and publicly available somewhere in some web server. Google pointed me to this libosmocore wiki page: ftp://ftp.osmocom.org/api/latest/libosmonetif/ In there, there are several links to stuff like http://www.osmocom.org/doc/libosmocore/latest/html/, but I get access forbidden when trying to use that one. On the other hand, I found somewhere else a link to http://ftp.osmocom.org/api/latest/libosmonetif/html/ which seems to be working. Now the question is: which is the expected way to access the documentation? should "www.osmocom.org" work instead of having to use "ftp.osmocom.org"? -- - 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

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC January 2018