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.
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
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
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 !
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
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
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)
This is most probably related to / fixed by https://gerrit.osmocom.org/5516 :
[ 142s] [0;m<001e> rate_ctr.c:195 counter group 'msc' already exists for index 0
[ 142s] [0;m/usr/src/packages/BUILD/openbsc/tests/testsuite.dir/at-groups/1/test-source: line 25: 20213 Segmentation fault $abs_top_builddir/tests/gsm0408/gsm0408_test
On Tue, Dec 19, 2017 at 08:14:06PM +0000, OBS Notification wrote:
> Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/o…
I recently saw this video / post in which Osmocom had be used to create a GSM Base Station with a LimeSDR mini and a Raspberry PI.
https://www.crowdsupply.com/lime-micro/limesdr-mini/updates/gsm-base-statio…
I was very interested in this, because I need to be able to test cellular broadcast messages, and this seemed to provide a way to do this.. CB seems to be supported in Osmocom.
I am a bit overwhelmed about what I need to install, to get a minimal, but functioning ‘system’ running, so I can test some features.. I ordered a LimeSDR and it hopefully will arrive sometime after the new year
But I wanted to get a jump start on it now. Is there some instructions in the wiki, I just did’tn know which ones to follow.
Kind Regards