OpenBSC December 2017

openbsc@lists.osmocom.org

20 participants
29 discussions

by Martin Nagy

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

2 weeks, 5 days

Re: Help with sccp library

by mosbah abdelkader

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

1 month, 4 weeks

dynamic traffic channels

by Neels Hofmeyr

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 months, 2 weeks

GSM 04.08 L2 pseudo length in ACCH System Information messages

by Vadim Yanitskiy

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.

7 years, 5 months

osmo-trx with USRP1 - libusrp vs. UHD

by Alexander Huemer

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

7 years, 7 months

stricter rate counter group allocation breaks applications

by Neels Hofmeyr

A recent patch to libosmocore refuses to allocate a rate counter group with an index that already exists. Per se that's a good thing, but it needs fixes in a whole range of callers. Numerous callers wrongly just pass 0 as rate counter group, so as soon as a second <thing> shows up, the application may deny service; that's unacceptable. For example, OsmoSGSN now crashes with the second subscriber showing up! causing patch: https://gerrit.osmocom.org/5418 my proposed change: https://gerrit.osmocom.org/5516 I'd like to request everyone to refrain from submitting patches that are insufficiently tested, in general of course, but in particular until after congress, please ;) ~N

7 years, 8 months

help !!!

by Liang hengshuo

When I run pysim ,I cannot read the card ,and always tell me this: lab434@lab434-OptiPlex-7050:~/pysim$ ./pySim-read.py -p0 Reading ... ICCID: Traceback (most recent call last): File "./pySim-read.py", line 99, in <module> print("IMSI: %s" % (dec_imsi(res),)) File "/home/lab434/pysim/pySim/utils.py", line 57, in dec_imsi l = int(ef[0:2]) * 2 # Length of the IMSI string ValueError: invalid literal for int() with base 10: 'ff' Anything you know may help me ,thank you !

7 years, 8 months

gerrit load

by Neels Hofmeyr

I noticed that gerrit places constant load on the server. When I first checked, it was between 30 and 60% CPU load, now is more like 10-15%, but still it is constant load. I'm pretty sure we're not all clicking around in gerrit all the time, so what would it be: Gerrit does things in the background, like checking whether unmerged patches have merge conflicts to the current master. I'm not perfectly sure how often this happens, but my guess is that it happens a lot. We have around 150 open patches on gerrit. If not for sanity, maybe the CPU load on the gerrit server could be another reason to reduce that number. Related: I notice that the sync of gerrit's git repositories takes longer than it used to. It would be a minute max, while just now I got >10min, and I remember Pau noting something similar recently. I think we should plain abandon patches that have been idling around for more than 3 months. That would discard about 30, so not that many. Then we have quite a number that are currently in Merge Conflict... Seems that we don't get around looking at each one and deciding to kick it or keep it. ~N

7 years, 8 months

Use osmocombb and openbsc to do man-in-the-middle attacks

by 西电__张皓

Hello, I would like to use openbsc to do a fake base station and osmocombb to do an attack cell phone, to implement a man-in-the-middle attack. I have two questions: 1. How do I send location updates and authentication information between openbsc and osmocombb, 2. How to modify the code thank you very much

7 years, 8 months

Branch cleanup in osmo-mgw.git

by Harald Welte

Dear all, I'm seeing plenty of branches which I believe were forgotten to clean up: gerrit/lynxis/pre_release gerrit/neels/client_vty gerrit/neels/new_mgw gerrit/neels/osmo-mgw gerrit/neels/pending gerrit/neels/pmaier/mgw2 gerrit/neels/pmaier_mgw gerrit/neels/pmaier_mgw6 gerrit/neels/split gerrit/neels/wip gerrit/pmaier/aoip2 gerrit/pmaier/mgw gerrit/pmaier/mgw2 gerrit/pmaier/mgw3 gerrit/pmaier/mgw4 gerrit/pmaier/mgw5 gerrit/pmaier/mgw6 gerrit/pre_release I would appreciate if the respective authors could have a look and remove them if the respective branch is confirmed to be no longer needed. 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)

7 years, 8 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC December 2017