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 developers,
the number of branches in many repositories (most notably libosmocore)
is growing to a rather large number, and I would like to encourage everyone
to have a quick look about which branches can be deleted by now (and delete
them, if no longer needed).
Thanks!
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)
Dear all,
36c3 is going to happen soon, and as usually we're planing to setup
our own GSM/UMTS network (LTE is to be discussed). While we do have
enough UMTS NodeB units, we're looking for heroes who could sacrifice
their GSM base stations (preferably sysmoBTS or nanoBTS) for the
duration of the congress. Note that we're not considering SDRs (unless
somebody with a strong aspiration wants to ensure proper clock
distribution, filtering, power amplification, etc).
Please let us know 1) how many (and what kind of) units we could
borrow from you, 2) can you bring them to Leipzig before the first
day, or can you drop them somewhere in Berlin (Sysmocom? AfRa?).
Thanks!
On behalf of the GSM team,
Vadim Yanitskiy.
Somehow osmo-hlr is no longer building in OBS for a variety of targets
--
- 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)
I noticed the MSC test that wants osmo-msc to repeat a Paging to the BSC and
hNodeB.
After fixing the Iu tests, I wanted to get this last ttcn3-msc-test working, so
I was about to implement repeated Paging from osmo-msc, but the more I think
about it, the less it makes sense to me.
The commit log in osmo-ttcn3-hacks says:
Repeating will improve the reachability of MS when a Paging is lost
or not received because the MS is moving between states.
This reasoning seems flawed to me, because the BSC / hNodeB is between the MSC
and the MS, and the BSC *does* repeat Paging. That should cover MS moving
between states.
The link between MSC and {BSC,hNodeB} is considered reliable, and AFAICT
nothing really gets better when repeating a Paging request to the BSS.
It could make sense to maybe repeat Paging with a larger/more general Cell
Identifier List? But why not send the full list in the first place?
Also 3GPP TS 48.008 3.1.10 Paging says:
A single PAGING message across the MSC to BSS interface contains information
on the cells in which the page shall be broadcast.
I interpret the "A single" as: there is no repetition of Paging requests toward
the BSS, and that's also what makes most sense to me infrastructurally.
Is there any spec indicating repeated Paging from the MSC?
I would actually remove the test TC_lu_and_mt_sms_paging_repeated.
If that's the wrong call, we should specify how osmo-msc should repeat Paging.
Before that, having the test makes little sense...
What do you guys think?
~N
Hi all,
I wrote a script and am wondering whether it makes sense to publish it in
libosmocore/contrib/.
For codec negotiation patches, I was writing ladder diagrams manually in the
mscgen format, and it was so annoying to type "[label=]" all the time, that I
decided to write a script that parses a leaner ladder diagram format and
converts it to mscgen format.
I was going to use this format in osmo-msc.git, but actually, after I wrote the
first osmo-msc codec ladder diagram, I went a step further and automated the
process by transcribing an osmo-msc log output directly to a ladder diagram.
That script can output to mscgen format, so in the end there is no dependency
on that simpler ladder format from my osmo-msc patches.
When writing ladder diagrams manually in the future, I'll probably choose my
simpler ladder format. I could always submit the converted format instead of
that, i.e. keep the simpler format to myself entirely.
I could publish the script privately...
Any opinions? Does it make sense to put this in libosmocore/contrib/ before any
Osmocom git trees actually depend on it?
See branch neels/contrib
http://git.osmocom.org/libosmocore/commit/?h=neels/contrib&id=f1ec9483de0f9…
~N
