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,
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)
Hi!
It has recently come to my attention that people find it hard to find
error messages when compiling TTCN-3 code.
This is primarily due to the hundreds to thousands of compiler warnings
which [at least our] code generates when building with ttcn3_compiler of
TITAN. While some of those warnings indeed should be resolved, a great number
of them is actually things where we know what we are doing, and where we'd
normally want to disable the warnings.
Unfortunately, TITAN doesn't have a system to selectively disable warnings like
-Wno-foo in gcc.
There are two things that help:
1) colorized output of ttcn3_compiler, which is something I submitted quite
a long time ago, but which hasn't e.g. ended up yet in a number of distribution
packages. Please feel free to use the eclipse-titan package we build in the
OBS network:osmocom:latest feeds to get that feature
2) ttcn3_compiler actually has a '-w' command line argument to make all warnings
quiet, which is also supported by ttcn3_makefilegen. You can edit the
osmo-ttcn3-hacks/regen-makefile.sh to add that option to ttcn3_makefilegen
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)
Dear team could you pls help me with this question
In bts config we have following entries:
trx 0
nominal power 23
! to use full TRX power, set max_power_red 0
max_power_red 20
and
osmotrx tx-attenuation (oml|<0-50>)
So why do we need these «max_power_red 20» and «osmotrx tx-attenuation» which both as i understand weaken the signal?
If we want to have a weak signal why we just don’t use only «nominal power» with whatever weak or strong signal value we want?
Thank you so much
--
Mario Lucas
The setup:
- I am using Osmo-MSC, Osmo-HLR, python-smpplib, and sim-tools. My SIM
card is a Sysmocom USIM-SJS1 which came with OTA keys.
- Osmo-MSC has been configured to accept SMPP connections, and
dcs-transparent has been set.
- Using sim-tools with the --smpp flag, I generated the necessary SMPP
messages to load the HelloSTK.cap file to the SIM. (Essentially, I've
followed the instructions here:
https://osmocom.org/projects/cellular-infrastructure/wiki/Shadysimpy)
- Sim-tools outputs 6 messages, so in a separate program I use
python-smpplib to push each message to the MSC over SMPP.
- The send function in my program looks like this:
parts =
["027000003815060115150000001dbf31df8eb85248617ff79260f7bf0abd332e2b3c>
"02700000901506011515000000d85420f0f778e35b4b8e0ae5d961593444f20fdebb>
"02700000901506011515000000729062e3cc920acc51be4f22fd067314bfaee313d6>
"02700000901506011515000000373f30a3c12b494d3089c70a2dd46e33e3fccac790>
"0270000068150601151500000083f04c39ef2df571bd5389f71b8c528e9b3edea046>
"02700000601506011515000000ad6eeebc9373de8bd3a8888324ffaad4d8cd935f0c>
]
for part in parts:
pdu = client.send_message(
source_addr_ton=smpplib.consts.SMPP_TON_INTL,
source_addr='0',
dest_addr_ton=smpplib.consts.SMPP_TON_INTL,
destination_addr='3331112222',
short_message=bytes.fromhex(part),
data_coding=246,
esm_class=64,
registered_delivery=True,
)
print(pdu.sequence)
I have Wireshark running on the computer hosting the MSC, and it shows GSM
SMS messages sending to the UE, however there is no response, and when I
inspect the SIM card, no applet has been loaded.
Am I missing something here? What could be causing this issue?
Thanks!
