Hi,
My name is Brackley Cassinga Form DRC, we run a community network called
pamoja net where we offer gsm services using osmocom open source software
and OC Base station.
Recently I have tried to install another base station as the same installed
but I could not find any resource guiding through all the steps to take to
run NIB on a base station.
I'm currently running Ubuntu and I will appreciate if you could guide me on
the installation of BSC,hlr,MSC , in order to run a basic gsm network.
Thank you. Regards
--
*Ir Brackley heshima Casinga **Pacifique*
*CEO and Founder of kwanzatechnologie*
KwanzaTechnologies ,GlobalElectronics
+243977265291 | +243977265291 | Pcassinga(a)gmail.com/
brackley(a)ensemblepourladifference.org
www.kwantechnologies.jimdosite.com <http://www.kwantechnologies.com/> |
Skype: Brackley cassinga <https://webapp.wisestamp.com/#>
Av Semliki N 43
Dear Osmocom community,
pySim-prog was nice when there were only 5 parameters on a SIM that we
could program, and where the use case was pretty limited. Today, we
have SIM/USIM/ISIM cards with hundreds of files and even more parameters
to program. We cannot add a command line argument for each file to
pySim-prog.
Instead, this introduces an interactive command-line shell / REPL,
in which one can navigate the file system of the card, read and update
files both in raw format and in decoded/parsed format.
The idea is primarily inspired by Henryk Ploetz' venerable
cyberflex-shell, but implemented on a more modern basis using
the cmd2 python module.
You can see the very first prototype in the laforge/shell branch of pysim.git
You can do things with it like this:
===> Start-up and authenticate with adm pin
----------------------------------------------------------------------
$ ./pysim-shell.py -p 0
Using PC/SC reader interface
Autodetected card type: sysmoISIM-SJA2
AIDs on card: ['a0000000871002ffffffff8907090000', 'a0000000871004ffffffff8907090000']
Welcome to pySim-shell!
pySIM-shell (3f00)> verify_adm 92990895
----------------------------------------------------------------------
===> interactive help
----------------------------------------------------------------------
pySIM-shell (3f00)> help
Documented commands (use 'help -v' for verbose/'help <topic>' for details):
ISO7816 Commands
================
read_binary select_adf select_file update_binary update_record verify_chv
pySim Commands
==============
intro verify_adm
USIM Commands
=============
read_ehplmn ust_service_activate ust_service_deactivate
pySim-shell built-in commands
=============================
alias help macro quit run_script shell
edit history py run_pyscript set shortcuts
----------------------------------------------------------------------
===> more interactive help
----------------------------------------------------------------------
pySIM-shell (3f00)> help read_binary
usage: read_binary [-h] [--file-id FILE_ID] [--offset OFFSET] [--length LENGTH] [--record-nr RECORD_NR]
Read binary data from a transparent EF
optional arguments:
-h, --help show this help message and exit
--file-id FILE_ID File ID
--offset OFFSET Byte offset for start of read
--length LENGTH Number of bytes to read
--record-nr RECORD_NR
Number of record to read
----------------------------------------------------------------------
===> navigating the FS and reading files
----------------------------------------------------------------------
pySIM-shell (3f00)> select_file 7f20
['622c8202782183027f20a509800171830400018d088a01058b032f0601c60f90017083010183018183010a83010b']
pySIM-shell (3f00/7f20)> read_binary --file-id 6f07
089910070000400310
----------------------------------------------------------------------
===> interaction with local filesystem, i.e. I/O redirect + shell commands
----------------------------------------------------------------------
pySIM-shell (3f00)> select_adf a0000000871002
pySIM-shell (a0000000871002)> select_file 5f3b
pySIM-shell (a0000000871002/5f3b)> read_binary --file-id 4f20 > /tmp/f
pySIM-shell (a0000000871002/5f3b)> !cat /tmp/f
ffffffffffffffff07
----------------------------------------------------------------------
===> piping output through shell tools like grep
----------------------------------------------------------------------
pySIM-shell (3f00)> read_ust | grep 86
Service 86 - Allowed CSG Lists and corresponding indications
----------------------------------------------------------------------
===> enabling/disabling services
----------------------------------------------------------------------
pySIM-shell (3f00/7f20)> ust_service_activate 123
pySIM-shell (3f00/7f20)> ust_service_deactivate 123
----------------------------------------------------------------------
It's a very first prototype, but it is really promising.
The major tasks I see to make this go anywhere is:
* have "File" class with encoder/decoder methods, which are registered
automatically with a 'file system' layer that knows about the DF/ADF
hierarchy
** this allows us to have a "read-decoded" command, which will
call the decode method of the file, automatically resolved by the
selected FID/path
* automatic mapping of file-name -> FID and FID -> file name
** when printing (like in the path), use the human-readable names
** allow users to use human-readable names in SELECT
* decode + display the TLVs / FCPs after a SELECT (like cyberflex-shell
* ability to enable/disable APDU trace
* dynamically register/deregster commands based on the path, i.e. offer
USIM commands only when in ADF_USIM
We have quite a bit of that infrastructure in the c-language libosmosim,
(part of libosmocore.git), but unfortunately not in python :/
Let me know if anyone is interested in joining this effort.
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)
Hi, osmocom team members.
In order to have an internet connection in UE, we have run OsmoGGSN project
to set up GGSN. Also, SGSN is developed in our system.
At this step, UE connects to our network core and we can query to an
arbitrary site in the UE browser and we see the answer of the query without
any problem and everything is OK. But after about 30 or 40 seconds, UE
sends "Deactivate PDP Context Request" with SM Cause "SM Cause: Protocol
error, unspecified (111)" and the connection is reset and a new "Activate
PDP Context Request" is required. What is the reason and how can we solve
it?
--
*When there is much light, The shadow is deep...*
Dear Osmocom community,
as the pandemic continues and physical meetings are out of the question
for the forseeable future, it would be a good idea to have a periodic
virtual online meeting of the interested Osmocom community.
I was thinking of a format where we would serve two major purposes:
1) technical talks about osmocom relevant topics - ideally
current/recent developments
* can be pre-recorded to avoid any problems with technical setup,
streaming, ...
* should ideally have a Q+A session at their initial "airing" during
one OsmoDevCall
2) unstructured solicited social event (USSE)
* random chat in audio (optionally video)
* not recorded, obviously
The recording of the technical presentation should then be permanently
made available (like the presentations of our prior OsmoCon /
OsmoDevCon).
Not every OsmoDevCall would neccessarily need the two parts, but I think
it would be great if we can make that happen. We could also have e.g. a
two-weekly schedule for the USSE and a monthly schedule for the
technical presentation.
We'd need somebody to volunteer to "manage" the "broadcast" side of
this, preferably somebody with at least some prior exposure to online
events (like the c3voc).
I'm using https://osmocom.org/issues/4928 to collect a tentative list
of topics. Feel free to add your ideas there, as well as any comment/
feedback you may have.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello list,
we are working on extensions to pySim for the sjs2 card mainly to make our 5G phones to accept our network.
How should we send this patches?
Via this mailing list or should we wait a little longer until Harald finished restructuring the mailing lists?
Best Regards
Bjoern
Hello esteemed masters of Osmocom and Sysmocom,
As I am doing some experiments with sysmoISIM-SJA2 cards in order to
make a contingency plan in case I am not able to buy cards from Grcard
beyond the 5 sample cards I got in February (my contact person there
hasn't been responding to email for the past 3 days), I have noticed a
discrepancy between this card's ATR and the file characteristics byte
it returns in response to SELECT in the GSM 11.11 SIM protocol,
regarding allowed levels for clock stop.
My sysmoISIM-SJA2 cards (bought from the webshop in late Jan into
early Feb) return the following ATR:
3B 9F 96 80 1F 87 80 31 E0 73 FE 21 1B 67 4A 4C 75 30 34 05 4B A9
The TA byte for T=15 indicates allowed voltage classes and allowed
levels for clock stop. On this card this byte equals 0x87, meaning
all 3 voltage classes (good), but also indicating that when the clock
is stopped, it should be HIGH.
However, the file characteristics byte returned in response to SELECT
(both MF and DF_GSM) in the GSM 11.11 SIM protocol is 0xB1; decoding
this byte per 3GPP TS 51.011, it says "clock stop allowed, no preferred
level". Thus the file characteristics byte says that there is no
preferred level, yet ATR says that HIGH level is preferred - or not
just preferred, but required? (7816-3 seems to say it is only a
preference, not a requirement; I seem to recall some other spec that
said it's a requirement, but I can't find it now.)
This discrepancy poses a potential problem if these cards are to be
used in classic GSM/2G dumbphones whose original firmwares are based
on the reference from TI. That reference fw code does not look at ATR
for the purpose of determining allowed clock stop levels (most classic
SIMs didn't have that T=15 TA byte in their ATR, it became commonly
present when UICC/USIM stuff came along), instead it looks at the file
characteristics byte returned in response to SELECT of DF_GSM.
Furthermore, if the file characteristics byte says that there is no
preferred level for clock stop, TI's reference fw configures the hw to
leave the clock LOW during idle. I can only reason that other classic
dumbphone firmwares (from other chip vendors) may very likely do the
same: GSM SIM specs (11.11 and 51.011) don't require ME implementations
to look at T=15 bytes in ATR, instead they direct MEs to follow the
file characteristics byte.
Can someone from Sysmocom officially confirm whether or not it is OK
to operate sysmoISIM-SJA2 cards with clock stop at LOW level, contrary
to ATR asking it to be HIGH? I have done a limited test of putting
one of these cards into an FCDEV3B (with this aspect of the firmware
left unmodified, so the clock line was low during idle) and the SIM
interface appeared to still be alive after some deep sleep (clock stop)
cycles. However, it was a very limited test, and I don't have my own
network set up yet to make a more thorough test - and in any case, an
official confirmation would be much better than anecdotal observations.
TIA,
Mychaela
Dear Osmocom community,
This topic has been past due for way too many years by now:
A re-organization of our major mailing lists.
I would like to propose the following changes. Pleas let me know if you
have any comments or feedback. I'm aware that renaming will mean people
have to update their mail filter rules, but I think we're long past the
point where the names of some of our lists started to confuse users.
== openbsc(a)lists.osmocom.org ==
* openbsc doesn't exist anymore since OsmoNITB, which is also obsolete
* does already cover anything "Osmocom CNI" related
* Proposed new name: osmocom-cni(a)lists.osmocom.org
== osmocom-net-gprs(a)lists.osmocom.org ==
This date back to when GPRS was a highly experimental add-on to our GSM
code base. This list should simply be merged with openbsc@ as osmocom-cni(a)lists.osmocom.org
== simtrace(a)lists.osmocom.org ==
Historically was created to cover only the simtrace project.
We should rename this to osmocom-simcard(a)lists.osmocom.org or something
along those lines.
I would like to suggest it covers
* SIMtrace / SIMtrace2 hardware + firmware
* pySim and related tools for working with SIM/USIM/UICC cards
* any other information / discussion related to SIM/USIM/UICC cards,
like OTA, ARA-M, ...
== osmodevcon(a)lists.osmocom.org ==
This has been a private list for people attending OsmoDevCon
I would like to open up list membership to the general public, and ensure
it also covers the new OsmoDevCall. We could then have discussions regarding
feedback, topics, scheduling, etc. on that list.
Maybe rename it to osmocom-events(a)lists.osmocom.org instead?
To differentiate: osmocom-event-orga(a)lists.osmocom.org should remain a
private list related to organizational / administrative topics of those
involved with organizing future events.
== nextepc(a)lists.osmocom.org ==
Should have been renamed to open5gs(a)lists.osmocom.org quite some time
ago, I simply forgot about it. My apologies.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello esteemed masters of Osmocom,
(asking here because Harald's proposed osmocom-simcard list hasn't
been created yet)
I have some questions and experience-based corrections related to the
gold nuggets contained in this wiki page:
https://osmocom.org/projects/cellular-infrastructure/wiki/GrcardSIM2
First let me establish relevance: even though Sysmocom stopped selling
these GR2 cards ages ago and it looks like the wider Osmocom community
also stopped playing with them once sysmoUSIM-SJS1 came out, these
same GrcardSIM2 cards are still available from Grcard in the present
day. A week and a half ago I received 5 sample cards (plain white, no
printing, unprogrammed) from Grcard that return the same ATR as is
listed for sysmoSIM-GR2, and all of the card-model-specific
proprietary commands described on the above wiki page work exactly the
same on these cards as they once worked on sysmoSIM-GR2. I am now in
the process of ordering a batch of 200 of these cards from Grcard,
with my own custom printing applied (so they will look pretty, not
plain white and not black like sysmoISIM-SJA2) - essentially I am
bringing back an exact equivalent of the discontinued sysmoSIM-GR2.
With relevance thus established, let's move on technical questions:
* The wiki page describes a file named EF.WEKI, file ID 0001 under
DF.GSM. Whoever wrote this wiki page, how did you get this fancy
name EF.WEKI? Was there some kind of document from Grcard that
described this card-model-specific proprietary file? Does that
document still exist somewhere? Can there be some way for mere
mortals like me to see that document?
* The wiki page describes byte 3 of EF.WEKI as selecting COMP128
algorithm version. It lists 0 as selecting COMP128v1 and 1 as
selecting COMP128v2, and these two codes are correct - confirmed by
programming these codes, doing a RUN GSM ALGO command, and comparing
returned SRES and Kc against osmo-auc-gen. However, the page lists 3
as selecting COMP128v3, and this part is not correct - writing 3 in
there results in COMP128v2 being selected, just like code 1. Instead
I need to write 2 into the lower nibble of this byte in order to get
COMP128v3 SRES and Kc in response to RUN GSM ALGO.
* The COMP128 selection code is just the lower nibble of byte 3 of
EF.WEKI - the upper nibble is something else that currently eludes my
understanding. The wiki page instructs users to write 0 into the
upper nibble, and so does pySim-prog - yet in the initial
"unprogrammed" state of the cards I received from Grcard, this upper
nibble is set to 2, not 0. I could not see any observable difference
in card behaviour whether the upper nibble is set to 0 or 2 - either
way the lower nibble selects COMP128 version for RUN GSM ALGO
operations.
* The wiki page gives the impression that EF.WEKI is 19 bytes long in
total. However, the actual size of this transparent EF on the card is
35 bytes, i.e., there is another 16-byte field (some other key?) after
Ki. Of the people who were once privileged with proper official
documentation for these cards, might anyone be able to tell what this
other key is for? Could it perhaps be some kind of key for OTA?
Before someone tells me that I should direct these questions to Grcard,
given that I am buying cards from them, let me assure everyone that
yes, of course I am doing everything I can to pry this information out
of them. However, they seem to have the same attitude as most Chinese
companies where they just want you to buy their product and not ask
any technical questions, and whatever answers they do give are so
terse that they feel like non-answers. But there is also the undeniable
fact that once upon a time these cards were resold by Sysmocom, once
upon a time this Osmocom community right here worked with these cards,
and someone in this community (or on Sysmocom staff) must have gotten
enough documentation to write the wiki page and pySim-prog support for
them. Thus I feel at least somewhat justified in asking this community
for help with bringing back this lost knowledge.
On a happier note, my fc-pcsc-tools suite (fc-simtool and its limited-
function companion fc-uicc-tool) is advancing quite a bit in
functionality. I don't know how it compares to pysim-shell since I
gave up trying to get the latter to run under Slackware (just too many
difficult dependencies), but from what I read in mailing list posts,
pysim-shell seems to be rather UICC-centric - I couldn't tell if it is
supposed to work on non-UICC GSM 11.11 protocol cards or not. In
contrast, my fc-simtool (written in C, zero dependencies beyond
libpcsclite) speaks the classic GSM 11.11 SIM protocol and does
everything that is possible within this protocol, including innovative
hacks like brute force search of the file ID space. This tool should
be ideal for cards like GrcardSIM2 which are non-UICC and for which
the classic GSM 11.11 SIM protocol is native. The companion utility
fc-uicc-tool for the UICC protocol is quite minimal in functionality,
just enough to satisfy the few areas of curiosity I had in relation to
that protocol and the cards I have around that speak it. These new
C-language SIM tools live here:
https://www.freecalypso.org/hg/fc-pcsc-tools/
The code is 100% my own original work and there is a LICENSE file at
the top of the repository declaring it as public domain, so there
should be no problem with Free Software status of the work.
In hacking fellowship,
Mother Mychaela
Hey all,
short FYI regarding jenkins.osmocom.org: two new raspberry pi nodes are
available, in order to reduce wait times for free build slots during
heavy osmo-trx development.
All three pis execute the jenkins jobs on top of raspbian10 now, unlike
the old setup where it was on top of debian 9 in a LXC running in
raspbian10. In other words, the LXC layer is gone now, and there might
be slight differences related to debian9 vs. debian 10 packages. For all
the jobs running in docker instead of directly on the host, there should
be no difference at all.
Details are in OS#5055.
Best,
Oliver
--
- Oliver Smith <osmith(a)sysmocom.de> https://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