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
We're still having massive stability problems with osmo-bts-trx on the osmo-gsm-tester.
I have run a tcpdump on the ntp port for the past days, and nothing is doing
ntp besides the actual ntp service.
Today I started ntp while an osmo-bts-trx run was active and what do you know,
the osmo-bts-trx process exits immediately. I think this is bad, osmo-bts-trx
shouldn't use wall clock time for precise timing needs.
Besides that, I have no idea what could cause the clock skews, except maybe
that the CPU or the USB are not fast enough?? I'm wondering, is there still
such a thing as a separate linux realtime kernel?
We will soon take to productive use another main unit which will be a cleanly
installed OS. If we see the same problems on that system and can't find a
software fix, we may need to reconsider the tester for osmo-bts-trx...
~N
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
Dear all,
I've started to implement some test cases that validate the accuracy of
OsmoBTS and OsmoBSC SYSTEM INFORMATION generation.
Those test cases are written in TTCN-3, which is a special programming
language specifically designed for testing and validation of protocol
stacks. For those present at OsmoDevCon, I've briefly presented about
it there.
In terms of general core infrastructure, I've written:
* Definition of GSM RR and some other commonly used GSM types using the
TTCN-3 type description language and the TITAN RAW (binary) encoder/decoder.
The beauty of this is that one can simply describe the message
structure without having to generate any code for encoding/decoding
the message. See
http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSM_Types.ttcn
and
http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSM_SystemInformation.…
* A GSMTAP Test Port, whcih is basically how a TTCN-3 testcase/testsuite
interacts with a given IUT (implementation under test). It is
implemented as dual-faced port on top of the TITAN IPL4asp (ip layer 4)
port and implements GSMTAP header encoding/decoding from/to TTCN-3
structured data types:
http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSMTAP_PortType.ttcn
which uses
http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSMTAP_Types.ttcn
describing the GSMTAP header format.
* Helper functions to emulate interactive use of the VTY based on the
existing TITAN TELNETasp Test Port:
http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/Osmocom_VTY_Functions.…
* L1CTL type definition (again using auto-generated encoder/decoders!)
http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/L1CTL_Types.ttcn
as well as an L1CTL Test Port at
http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/L1CTL_PortType.ttcn
Using the above one can easily interface from TTCN3 with L1CTL of
virtphy in order to e.g. sync to a BTS on a given ARFCN and establish
a dedicated radio channel. Here is where the beautoy of the TTCN3
type language, templates and matching can be seen. It's very easy to
perform something like "does this IMMEDIATE ASSIGNMENT match the RA +
FN of the RACH request that I sent?
Based on all of the above, there's two test suites:
== Test Suites
1) SYSTEM INFORMATION contents and scheduling validation
I've written some SI validation code which can be found at
http://git.osmocom.org/osmo-ttcn3-hacks/tree/sysinfo
SI scheduling is quite complex, particularly when you have many of the
2ter/2bis/2quater/13/2n/... enabled. At some point actually you will
overflow what's possible to comply with the rules in a BCCH Norm. and
you have to go to a BCCH Extd. (OsmoBTS doesn't implement the latter
yet, btw).
See e.g. function f_validate_si_scheduling() for validation of scheduling
constraints:
http://git.osmocom.org/osmo-ttcn3-hacks/tree/sysinfo/Test.ttcn#n229
Later in the file you can find test cases TC_cellid() and below for the
individual test cases that validate that individual VTY configured
values such as BSIC, CellId, LAC, ... are actually broadcast in the SI
message. IT will update its internal matching template and then perform
a sequence of VTY commands to e.g. change the LAC followed by verifying
that the LAC of the decoded SI has actually changed.
The above tools have helped to discover (and fix) the following bugs:
* http://osmocom.org/issues/2368
* http://osmocom.org/issues/2367
* http://osmocom.org/issues/2365 (very critical, I believe)
and also the not-yet-fixed but low-importance
* http://osmocom.org/issues/2364
2) LAPDm testing
I've written some (early) LAPDm testing code at
http://git.osmocom.org/osmo-ttcn3-hacks/tree/lapdm
The idea here is to test for valid and invalid transactions on the Um
interface and see how OsmoBTS and the libosmcore lapdm code perform.
With very few lines, this has already uncovered the following issues:
* http://osmocom.org/issues/2370
* http://osmocom.org/issues/2380
Unfortunately my progress was severely affected over the weekend as I
spent about one working day wrapping my head around something that
turned out to be a bug in the Eclipse TITAN RAW coder, see
https://www.eclipse.org/forums/index.php/t/1087557/ - fortuantely the
Titan team has provided both a work-around and a fix today, which I
count as excellent service.
If you're curious about TTCN-3, I strongly recommend
http://www.ttcn-3.org/files/TTCN3_P.pdf as an introductory slide deck.
== Outlook
I want to add more test cases to the sysinfo and lapdm test suites and
get hands-on experience with the Junit XML output plugin. At that
point, a Debian 9 build slave of our jenkins should be able to
automatically build + run the latest test cases from
osmo-ttcn3-hacks.git and present the individual test case results inside
jenkins.
I also want to add test suites for validation of:
* proper generation + scheduling of of PAGING REQUEST in the BTS,
considering paging groups particularly in the context of different
BS_AG_BLKS_RES values
* CBCH validation
* proper generation of CCCH load indications by the BTS, i.e. generate a
certian load e.g. on uplink RACH and check the reports
* TA loop verification (add timing information to GSMTAP and then
dynamically change timing from MS side to see that BTS is compensating
as expected
* power control loop verification: GSMTAP already has a field for
transmitting RSSI in dBm. We can adjust this from the MS side to
validate the BTS will adjus the instructed transmit power level of the
virtual MS accordingly
* actually exhaust all channels of a multi-TRX virtual BTS in different
channel combinations, verify we can establish all existing logical
channels in each configuration
* combine the last topic with configurations that have dynamic PDCH/TCH
channels to verify we properly switch forward and backward
* various link failure conditions, i.e. does the BTS close the logical
channel in the expected timing after uplink loss?
Despite my current excitement about all of this, I'm not sure how much
time I will be able to spend on this, given that the sysmocom customer
priority is typically not the development of automatic test suites. But
I'll try my best.
If anyone wants to join: TITAN is just one "apt-get install eclipse-titan"
away!
== What's not good to test with TTCN-3 / TITAN:
While the existing infrastructure I've built is very suitable to test
low-level protocol topics, I think it's not particularly
useful/applicable in other areas:
* SI REST OCTETS and GPRS RLC/MAC, as they're defined in CSN.1 and TITAN
has no CSN.1 encoder/decoder. For easy mathing/generation of those
messages, we'd have to find something like an external
CSN.1-to-ASN.1-BER or CSN.1-to-XML converter which we could use. I'd
be happy to consider paying a reasonable amount for a proprietary
product, just as long as we are sure that it will provde the kind of
productivity that's useful here.
* full end-to-end tests with actual mobile phones, RF and BTSs in the
picture. We already have osmo-gsm-tester for this, and Titan with its
powerful type language, templates and matching capabilities doesn't
provide all that much benefit here over other languages/approaches
* higher-layer protocol testing. We do have OsmocomBB as a L2 + L3
MS-side implementation, and I don't think it makes sense to replicate
this. Even while the message encoding/decoding is super easy with
TITAN, we still have all the related state machines. So I'd rather
extend OsmocomBB where needed for automatic test cases than reinvent
the wheel here.
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 All,
I’m not sure if this is a valid question but still I’m going to try.
I just updated from my old version of OSMOCOM to the latest one.
Upon trying to test the updated version, it seems that the ring back tone, the one that rings in the Caller (Anum/Mobile Originating) side if the call started to ring on the Callee (BNUM/Mobile Terminating) side, is missing.
Can anyone direct me to the right path where to check it?
Below are the configuration files used for each OSMOCOM elements.
Best Regard,
Ron Menez
ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>
We are trying to setup this AP as part of the 3.5G Osmocom project.
We have the software stack operational and are now preparing the nano
for testing.
When we try to login via telnet at port 8090 we are getting a constant
refusal to connect:-
root@osm/openbsc/openbsc/src/ipaccess# telnet 192.168.192.30 8090
Trying 192.168.192.30...
telnet: Unable to connect to remote host: Connection refused
The device seems to be locked as indicated by the leds on the front panel.
We have tried resetting the nano to see if this would help but to no avail.
Any ideas as to how to access the device for initial configuration?.
Thanks
John
In the libosmo-sigtran cs7-instance vty scope, we have the same point-code
command on adjacent scopes:
cs7 instance 1
point-code 1.2.3 ! sets primary_pc
sccp-address msc
point-code 0.0.1
sccp-address sgsn
point-code 0.0.2
So if we reverse the order, we're in trouble:
cs7 instance 1
sccp-address msc
point-code 0.0.1
sccp-address sgsn
point-code 0.0.2
point-code 1.2.3 ! sets primary_pc
The parser interprets the last point-code to belong to the sgsn address scope,
not the outer cs7 scope.
We could rename the sccp-address one to 'pc', but...
This reinforces the idea to do strict parsing of leading spaces in all our vty
config files to interpret as explicit scope exit. That would break some running
configs with odd spacing, but would also fix all of these issues forever.
Given we're moving to a kind of Osmocom 2.0, now would be a good time to make
such a change.
If we from now on disallow tabs and enforce single-space indenting of child
scopes, the code for that should be rather simple: count leading spaces and
done. And we'd need to turn this off for interactive VTY shells.
~N
