Hi all,
This is my second email here so I will start with a quick introduction
before a question:
I’m part of of an early stage company called Hover (www.usehover.com). We
offer an Android software development kit written in Java that helps
smartphone app developers automate USSD sessions in the background of
native apps. A typical use case is to build a nicer user interface for, eg.
mobile money transfers or airtime top-up.
Colleagues at the University of Washington pointed me to this exciting
project, and I have a B210 set up so I can register a phone on an Osmocom
network and run *#100# to see my MSISDN from OsmoHLR. Which brings me to my
question:
I see that Rowan Phipps at UW has modified an earlier version of the
Osmocom stack to run arbitrary USSD sessions from a Python web server. It
looks like related work was started in 9658 and 9661 [1], [2]. Are these
commits working, and what would be the best way for me to contribute to or
test this work? I would prefer to run the newer Osmo* projects rather than
try to use OsmoNITB. I am in the process of reading Rowan and Fairwaves'
work and will happily share anything I learn.
As context, we have 50k+ USSD session logs (i.e. menu text, not Wireshark
traces) from various markets. My end goal is to be able to test new apps
against these logs and otherwise experiment with arbitrary USSD sessions
locally. Thank you for any suggestions you can offer.
—Michael
[1] https://gerrit.osmocom.org/#/c/osmo-msc/+/9658/
[2] https://gerrit.osmocom.org/#/c/osmo-msc/+/9661/
Hello everybody,
I hope I'm in the right place here, for my question, if not please
ignore or maybe point me to a better place.
For start, I'm quit new to the whole GSM stack and still in the process
of understanding it, so please if you have the feeling I maybe
misunderstood something horrible, I probably have! Feel free to point
that out :D.
I working together with other peoble on a project witch aims to connect
refugee camps in the middle east, to enable easy, safer and non profit
communication between them, this is often a big need for example to find
relatives, but also to communicate with in the camps because sometimes
they are huge etc..
One part (an at the moment my part) of this is to build up independent
GSM Networks per camp witch are interconnected with the other camps.
The idea is to build GSM networks with in the camp witch are autonomous.
If there is power they run, if there is internet peoble can call the
other camps (if they have internet).
Every thing need's to be done without any central entity (like an HLR
for all camps, run on a Server in Frankfurt) so that when, let say
government xy decides to only allow nation wide networking an cut's the
internet (happened since I'm here 2 times, it's annoying as f**k), the
camp's within the country and in the camp it self can still communicate.
The question is how to do this interconnection? As fare as I understand
in classical GSM infrastructure, this is done by SS7, but since we are
not interested (at least by know) to interconnect with "big" providers,
and also I did not found an open source implementation (but maybe I
missed it) this seems not an option, so the plan now is to do this
over VPN's and SIP/VOIP Server (probably asterisk). We like to be able
to scale the camps number, and to be relative easy to maintain so we can
enable people to run this them self (after we learned to run this our
self of course ;)). And these protocols are fare better documented then
SS7 so also much more esay to learn and to debug.
We are still testing and researching and so I thought it is maybe a good
time to ask her if this is a valid way or I missing something, or maybe
you can point me towards some documentations where people did some
similar things. We are all not professionals and do this more or less
with learning by doing, but we don't need to do all the mistakes other
did before us :D (maybe some but not all)
thx in advance and for this great project witch enabled us to do stuff
like this
naif
Hey,
I am trying to set up test bench for base-band fuzzing using the Osmocom
stack and a couple of SDRs (b210 and bladerf).
I have managed to setup everything to my liking in terms of a functional
network using the tutorial
(https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_I…)
and the latest stable packages from
https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds
Now I want to enable the silent_call functionality to begin testing but
I can't seem able to do so.
I have reverted the silent_call patch
(https://gerrit.osmocom.org/#/c/openbsc/+/1930/) for OpenBSC inside the
"new" OsmoMSC but unfortunately that did not work.
I have then started trying to figure out how the silent_call interacts
with the rest of the state machine, but I don't seem to be making much
progress.
Please see attached a log for the communication between OsmoMSC (which
triggers silent_call) and OsmoBSC. The connection seems to fail due to
issues related to either "Congestion" (if GPRS is enabled) or a timeout
of T0 (if GPRS is disabled).
Can anyone help?
Thanks
--
Mihai
== OsmoCon 2018 ==
OsmoCon (Osmocom Conference) 2018 is the technical conference for
Osmocom users, operators and developers!
We are happy to announce the date of OsmoCon 2018. It has been scheduled
on October 18 + 19, 2018 and will happen in Berlin, Germany.
For the second time, the Osmocom Conference brings together users,
operators and developers of the Osmocom Open Source cellular
infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN
and others.
Join us for two days of presentations and discussions with the main
developers behind Open Source Mobile Communications, as well as
commercial and non-profit users of the Osmocom cellular infrastructure
software.
You can find some initial information in our wiki at
http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018
which will be updated as more information becomes available.
== Call for Participation ==
We're also at the same time announcing the Call for Participation and
call on everyone with experiences to share around the Osmocom member
projects to submit talks, workshops, discussions or other proposals.
You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp
We are particularly looking for contributions about:
* updates on features/functionality/status of individual Osmocom projects
* success stories on how Osmocom projects are deployed in practice
* migration from OsmoNITB to the post-NITB architecture
* tutorials / workshops on how to setup / analyze Osmocom projects
* statistics, reporting, operations aspects of Osmocom projects
* third-party open source utilities to be used with Osmocom projects
Looking forward to meeting many existing and new Osmocom users at OsmCon
this October!
Regards,
Harald Welte
--
- 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)
Hi,
I'm wondering where I can source the Siemens BS11 firmware. It looks
like OpenBSC is not providing any firmware images.
# bs11_config -p /dev/ttyUSB0
bs11_config (C) 2009-2010 by Harald Welte and Dieter Spaar
This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY
LMT LOGON: ACK
PHASE: 1 Software required Abis-link: Down
No valid Safety Load file "BTSBMC76.SWI"
Thanks,
Andrew
Recently, dexter has added this commit:
http://git.osmocom.org/osmo-bsc/commit/?id=b9d3c71af347906cef2bb54be57418a9…
Our osmo-gsm-tester tests fail to pass since this commit thwarts all L3
Complete.
The commit refuses to compose a Layer-3-Complete message if the speech codecs
supported by the BSS cannot be included, either because none are configured, or
because none remain after all the criteria of finding codecs permitted.
It may be mandatory to include the speech codecs or not, what bugs me is that
we even refuse a mere attach to the network just because speech codecs are not
available. Those only become interesting much much later, only for voice.
The backwards-compatibility consideration: configurations that have always
worked well are suddenly likely to fail. Users will wonder what happened, and
we need to avoid that.
I think instead of thwarting L3 Complete entirely, we should loudly error-log,
but still send out an L3 Complete while simply omitting the speech codec list.
It might be a spec violation for AoIP, but practically works fine, AFAICT.
Again, the way to handle this spec violation should be to log an error, not to
break all access.
The alternative would be, IMHO, to abort osmo-bsc startup right away,
complaining about misconfiguration, if that is possible at all. But no.
Let's allow L3 Complete even in the absence of speech codecs that all
participants support. There are USSD and SMS and GPRS that are all going to be
broken just because codecs don't match.
The commit right after sets, apparently, the full list of codecs as supported
by default. Is that not working? Do we override that in the osmo-gsm-tester
config? Either way, even if the allowed codecs are all configured properly, but
there is simply no match between MS,BTS,BSC,MSC, we would still refuse LU,
right?
Hence I would like to revert above commit / replace with error logging.
@dexter, what do you think? Am I making sense, or am I missing something?
Thanks!
~N
P.S.: in that commit log, it would have been nice to mention the config items
that would help solve the situation. It's not entirely clear to me yet what the
misconfigured items are on the osmo-gsm-tester setup.
Hi All.
This is very brief, but something that's been on my mind to make a
ticket about.
I realise maybe it's better to ask first if there is a plan.
The issue is about restarting MSC or BSC (or both).
I still really haven't looked at the split setup enough yet, in terms of
getting familiar with all the info available from logging in both
programs, so I don't have a good analysis of what's going on. Sorry.
But my point here is not to describe a bug to be fixed but just asking
in general what is the strategy to deal with daemon restarts,
intentional or not. Is there a plan to implement some kind of
non-volatile state?
The problem in terms of usability, from simple observation:
In the case of restarting the MSC with two phones connected, of course
the phones don't notice anything. One now needs to attempt a call setup
at least 3 times, including a call setup attempt from the "callee" phone
before we can even call it.
I tried restarting both BSC and MSC, in various orders, and I did not
get a satisfactory result. Of course, restarting the BSC restarts
osmo-bts which causes (some) phones to notice the temporary loss of
BCCH, but of course no LUR or anything as LAC doesn't change, so there's
some state that is not getting set right someplace on restart, as I
said. both phones need to interact before one of them can be called.
Yeah, so, sorry for the lame analysis, but I think this should be pretty
easy to reproduce, and at this time there are people who are MUCH more
familiar with osmo-msc and osmo-bsc than me, who probably know what I'm
talking about and can comment.
Thanks!
k/
Hi all
Another one not quite ready for a ticket, but maybe worth mentioning here.
A while back I noticed a phone of mine was holding channels open all the
time. Turns out in does checks for call forwarding status and such on
camping.
This got fixed in Legacy OpenBSC:
https://gerrit.osmocom.org/#/c/openbsc/+/503/
I noticed this, or something similar is back with the split setup.
Try dialing *#21# for example. or pick a code from here:
http://www.geckobeach.com/cellular/secrets/gsmcodes.php
Then make a call. On some phones you can't, but if it does proceed, then
hangup. On all the phones I tried you now have not only a lingering
SDCCH, but also a TCH/F and on one phone, it doesn't ever go away, until
you turn off the phone, or drop the BCCH.
sorry again for the lame bug report. I don't want to forget it and I
can't pay it due attention in the coming days.
k/
