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
I'd like to share a VTY config error analysis that has a tricky solution:
I started osmo-bsc -c osmo-bsc.cfg with, according to
openbsc/doc/examples/osmo-bsc:
net
[...]
bts 0
[...]
periodic location update 30
trx 0
[...]
and get this error:
There is no such command.
Error occurred during reading below line:
trx 0
what? 'net / bts / trx' is no command??
Solution: I'm on the vlr_3G branch (incorporating 2G via A-interface) and on
this branch, I've actually moved the 'periodic location update N' command a
level up, from net / bts / periodic to net / periodic (background: assuming
that OsmoMSC does not have individual BTS info, we moved some settings up to
network level; whether this makes sense for osmo-bsc is a different question,
it's just what happens to be on the vlr_3G branch now).
So there is no net / bts / periodic command.
Why do I get an error for net / bts / trx instead?
two reasons:
1. 'trx 0' was the line following the 'periodic' command,
2. since 'periodic' exists one level above, the vty code goes to the parent
node automatically.
About 2: we tend to indent our VTY config files, but in fact the indentation
has no effect whatsoever, it is just eye candy (very useful eye candy).
The code in question: If a command does not exist, try 'vty_go_parent()' and
see if the command exists there. That's what allows us to omit 'exit' in our
config files to go to the parent node explicitly:
libosmocore/src/vty/command.c:
int config_from_file(struct vty *vty, FILE * fp)
{
int ret;
vector vline;
while (fgets(vty->buf, VTY_BUFSIZ, fp)) {
vline = cmd_make_strvec(vty->buf);
/* In case of comment line */
if (vline == NULL)
continue;
/* Execute configuration command : this is strict match */
ret = cmd_execute_command_strict(vline, vty, NULL);
/* Try again with setting node to CONFIG_NODE */
while (ret != CMD_SUCCESS && ret != CMD_WARNING
&& ret != CMD_ERR_NOTHING_TODO
&& is_config_child(vty)) {
HERE -----> vty_go_parent(vty);
ret = cmd_execute_command_strict(vline, vty, NULL);
}
cmd_free_strvec(vline);
if (ret != CMD_SUCCESS && ret != CMD_WARNING
&& ret != CMD_ERR_NOTHING_TODO)
return ret;
}
return CMD_SUCCESS;
}
In this case the 'periodic...' command does in fact now exist one level above,
so the vty_go_parent() is successful and running that command works. But, the
vty config parsing then sits above on the 'network' level, is no longer in 'bts
0' and hence refuses to accept the following bts-level command, in this case
'trx 0'. Confusing!
So it's not a bug, it's a feature. But it's a feature we might see quite often
if we move the 'periodic' command up to network level and users attempt to use
their old config files.
Same goes for the 'timezone' command, BTW, so we might want to rename commands,
or re-consider moving commands one level up in the first place. Maybe we should
leave backward compat catchers in place that print a warning.
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Hello FreeCalypso and Osmocom communities,
I am in the process of creating an informal organisation representing
the interests of those members of the GSM universe whose interests are
not represented by GSMA etc, and I am inviting you to join me in this
venture. I propose that we name our informal organisation GSMUA,
standing for GSM Users Association, and my vision for this GSMUA is to
be a counter-body (antibody?) to the official GSMA. I just registered
the gsmua.org domain name, but there is no website or mailing list set
up yet. If someone from the Osmocom camp would like to host the
server infrastructure for gsmua.org, I will happily point the DNS to
you, otherwise the FreeCalypso family can host it on our server.
My vision for GSMUA is to represent the interests of GSM end users
(empowered end users who wish to fully own and control all aspects of
their user equipment while operating on public mobile networks in a
fully spec-compliant manner), small boutique manufacturers of GSM
devices (both MS/user equipment and network infrastructure), small
community network operators and others whose interests are not
represented by GSMA etc, especially in cases where our interests are
in direct conflict with the interests of big players such as giant
device manufacturers, giant commercial network operators and
governments.
A key goal of GSMUA is to be project-neutral, that is, every person
and every small company belonging to any of the categories listed
above (empowered end user, small boutique device manufacturer, small
community network operator etc) should be fully welcome regardless of
which specific project they are associated with. As of today there
are at least two different projects offering GSM MS implementations
(OsmocomBB and FreeCalypso) and at least two different projects
offering network-side GSM implementations (Osmocom and OpenBTS), and I
hope that this number of available alternatives will continue to grow:
freedom of choice is always a good thing. But at the present time
there exists no neutral soil on which members of different projects
with a common interest (GSM networks and devices serving the interests
of end users rather than big corporations and governments) and a
common enemy (just named) can meet, and this lack of neutral meeting
ground is the problem which GSMUA is meant to solve.
I also have one practical application for GSMUA in mind already: to
manage and legitimize recycling of wasted IMEI number ranges. By the
official rules of GSMA etc each different *type* of GSM mobile
equipment requires a different TAC, i.e., a range of at least 1 million
IMEI numbers. So if a small boutique GSM device manufacturer makes a
boutique MS device of which no more than 100 units will ever be made,
999900 IMEI numbers have to be wasted by the official rules. While I
don't know of any manufacturer who got a range of 1 million IMEIs and
only made 100 devices, we do have examples like Openmoko GTA01/02 and
Pirelli DP-L10. In the case of Openmoko GTA02 I've been told that
about 15 thousand units were made in total; in the case of Pirelli
DP-L10 it appears that the total number produced was somewhere under
100 thousand. In each case a full range of 1 million IMEIs was
allocated, and at least 900 thousand numbers out of each range are
currently unused and wasted.
If a small boutique manufacturer wishes to offer a boutique GSM MS
product to the general public and wishes to ship each unit with a
world-unique IMEI that stands a good chance of being accepted as valid
by common GSM networks, and the product in question does not qualify
for IMEI allocation by the official rules (e.g., the product is a
development board specifically intended for users to run their own
firmware and connect to live public networks with it, taking full
personal responsibility for their actions) - the situation I found
myself in with my GSM MS development board - I feel that the small
boutique manuf in question should be empowered to squat on a small
subrange of someone else's IMEI range if it is known beyond reasonable
doubt to be wasted and unused.
However, this recycling of wasted IMEI number ranges could be better
organized and given at least some aura of semi-legitimacy if there
were a community body set up to manage it, and this is where my
proposed GSMUA can come in. Once we get our GSMUA up and running and
assign a group of volunteers to be IMEI recycling managers, any small
GSM or 3G+ device manufacturer who needs a small range of IMEI numbers
will be able to request one from GSMUA, and we will allocate and
assign these small subranges out of whatever wasted range we decide to
squat on, ensuring that each requestor gets a different subrange.
So these are my ideas, and I would like to see them turn into reality.
We are going to need a simple website and a community mailing list at
gsmua.org, and for the IMEI recycling service we will need a small
group of volunteers to serve as its managers - I and Das Signal from
FreeCalypso will be happy to serve on that panel, but it would be nice
to also have someone from the Osmocom camp for better neutrality.
Bright Blessings,
Mychaela Falconia,
Mother of FreeCalypso
Hi all,
I have some uncertainty about how to use the CTRL interface to set TRAPs.
In the OsmoBSC user manual (for example), the example provided doesn't
specify an option to set for the 'var' I might be particularly
interested in monitoring:
`$ ./bsc_control.py -d localhost -m`
Is this the default to monitor all? Can I go about narrowing this?
Also, I don't feel like I quite understand the TRAP portion of "Table
2: Variables available over control interface" in the OsmoBSC user
manual:
For example, the 'name' column seems to generally indicate the 'var'
that one would pass in a GET/SET command, so I'm assuming the 'name'
associated with the TRAP-enabled rows has the same significance. But
these 'names' have no real meaning to me in terms of my experience
with VTY, for example 'notification'.
I have tried to look toward the osmo-nitb unit tests for inspiration,
as there is fantastic coverage for GET/SET, out haven't seen similar
for TRAP.
Can someone please point me in the right direction?
Thanks,
Emily
Dear all,
osmo-gsm-tester is currently capable of setting up an entire network
with one or more BTSs, Modems, NITB, etc. and test signaling + SMS.
Voice testing has always been on the wishlist, but further down on the
TODO list. One issue here is that
a) many modems don't do voice at all (data-only modems for laptops)
b) some modems expose voice only as analog audio (difficult to interface,
would require custom hardware next to the modem, e.g. using USB
soundcard, calibrate the levels, ...)
c) some modems expose the voice as PCM bus. Similarly, would require
some external codec chip and/or USB soundcard or the like, plus a
custom circuit
d) some modems expose voice as "GSM codec frames over UART" or other
highty proprietary formats
e) some modems expose voice as USB audio device. Most convenient, but
only found in some Qualcomm LE based devices such as Sierra Wireless
or Quectel.
Over the weekend I was thinking of yet another method to make this much
simpler: Every phone is supposed to include a voice loop-back mode. In
this mode, the phone siply loops back all voice frames received in the
downlink and sends them back in the uplink. This functionality is
mandatory by the spec, and used to test the receiver performance of the
phone during development, manufacturing and service. IT is specified in
3GPP TS 44.014
(http://www.etsi.org/deliver/etsi_ts/144000_144099/144014/14.00.00_60/ts_144…)
which used to be GSM TS 04.04
(http://www.etsi.org/deliver/etsi_ts/101200_101299/101293/08.06.00_60/ts_101…)
before.
The idea is that one puts a special "Test SIM" (as specified in TS
51.010-1 Annex 4, where EF.AD first byte == 0x80 is the criteria in this
context) into the phone, and then sends some specific commands on Layer3
to activate the loop.
So if we can activate that loop-back functionality from the Osmocom
stack, we could test if we get back the same voice data that we send in
downlink (minus some occasional bit error, but those should be super low
given we're operating omso-gsm-tester over coaxial cabling between MS and
BTS).
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,
The osmocom software that I do not install via apt but build myself gets
installed in $HOME/usr and I do things like:
export PATH="${PATH}:${HOME}/usr/bin"
export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${HOME}/usr/lib"
export PKG_CONFIG_PATH=$HOME/usr/lib/pkgconfig
MANPATH="${MANPATH}:${HOME}/usr/man"
Therefore I don't have to install to a destination outside my home
directory which in turn means I can avoid some sudo calls.
But that actually does not matter so much, you can mentally substitute
$HOME with '/' and append '/local' in the following if you want.
I don't install to $HOME/usr directly but use stow for 'managing' the
installations, so an installation goes like this:
$ mkdir -p $HOME/src/telco/osmo/libosmo-abis
$ cd $HOME/src/telco/osmo/libosmo-abis
$ git clone git://git.osmocom.org/libosmo-abis
$ autoreconf -i
$ ./configure --prefix=$HOME/usr/stow/libosmo-abis
$ make
$ make install
$ STOW_DIR=$HOME/usr/stow stow libosmo-abis
This has two advantages:
* Good visibility of what is installed by a package.
$ tree $HOME/usr/stow/libosmocore
* Possibility of uninstalling a package even if the Makefile is not
present.
For me those two advantages outweigh the small additional effort of
using stow.
Because of that workflow I sometimes run into situations in which make
runs fail because either header files are not found during compilation
or libraries are not found during linking. The reason is that autotools
variables pointing to pkgconfig supplied directories point to a
destination under the prefix path with which configure was called. If a
dependency was not mentioned in a Makefile.am the required files are not
found because the other dependencies are in other directories.
For a system on which the osmocom-own dependency libs are installed in
distinct directories, current openbsc master HEAD requires the attached
patch for a build to succeed.
I admit that in most situations the dependencies are installed in the
same directory so this does not matter, but it is still a small bug.
Therefore I propose to modify the jenkins build scripts so that they use
distinct, stow managed directories for the dependencies. That should
help to detect oversights, although admittedly developers would have to
adapt their workflows to use stow as well in their daily hacking.
Otherwise an oversight would be detected by jenkings and not locally
which in turn would require additional cleanup commits which is not so
nice.
What is your gut feeling? Does the increased correctness of Makefiles.am
contents justify the (IMO rather small) additional effort of using stow?
Kind regards,
-Alex
Hi all,
I was wondering if it is possible to generate a TDMA frame sync output
on a GPIO line of a USRP device (and/or any other SDR supported by
osmo-trx). This way it would be much easier to do e.g. BER testing
by using a pure waveform/pattern generator for the "MS side". Such
devices (Like an E4433B) can only generate the uplink bursts with
pseudo-random sequence, but they don't have any receiver, so they're not
able to receive the downlink from the BTS in order to lock on the TDMA
frame and transmit the uplink in sync to that.
There are of course specialized devices (CMU-300, ...) or hardware
options that add such receivers for synchronization on the signal
generators, equipment side, but why go there if there would be an easy
way to generate some kind of a frame sync output.
I would appreciate to know even if there's a way to introduce such
"synchronous GPIO toggles" or the like in the command stream to UHD
devices. If that existed, it should be rather simple to insert those
whenever a new burst for TS0 is sent.
A rather computationally (and bandwidth) expensive other option might be
to use the second RF output to generate such a signal, but I was hoping
not having to abuse the 2nd channel for that ;)
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)
In our osmo-gsm-manuals, there are various code listings that one would like to
copy-paste from the PDF. That would theoretically work, but practically, the
'DRAFT' watermark in the backdrop confuses the text marking, hence making
copy-pasting some text from the manuals very very cumbersome. Though I'm not
that sure why we need a 'DRAFT' watermark in an open source manual (it's
implicitly a draft), I am fine with having such a marking.
But I would like the marking to be less obtrusive. We could experiment with
putting a bitmap image in the backdrop instead of text, or even better IMHO
would be to put it in the page header next to the version.
We could also add a generic "DRAFT" disclaimer near the beginning of each
document.
(Same goes for the sysmocom internal manuals, for which it isn't so easy to get
the asciidoc source to paste from.)
Any opinions on this?
~N
