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