Hello Osmocom community,
Has anyone here ever played with the RFM (Remote File Management)
feature on sysmoUSIM-SJS1 and sysmoISIM-SJA2 cards? I know that a lot
of people play with RAM (Remote Application Management) for installing
Java applets, but I am more interested in RFM for doing a different
kind of OTA programming - I am seeking to recreate the workflow of
traditional GSM network operators where "blank" (not yet activated,
but ready to activate) SIM cards sit on store shelves with their IMSI
and secret keys (Ki/K/OPc etc) already programmed at the factory,
but blank EF_MSISDN because the future user's phone number is not
known yet. Customers activate these SIMs by reading the ICCID from
the card to customer service over the phone, or salespeople in stores
scan the ICCID barcode - and then the operator's customer management
system matches that ICCID with its knowledge of the IMSI and secret
keys, and the service gets activated on the new SIM. And then the
operator's network uses SMS-PP SIM data download to program the
EF_MSISDN record in the newly activated SIM - I know full well that a
phone does not need to know its own MSISDN to make and receive calls,
but every classic GSM dumbphone has a menu command for "Show my number"
or whatever it's called, this command displays the MSISDN record from
the SIM, and traditional operators program this record OTA so that
this menu command will work. I am seeking to recreate this OTA
programming step.
I just got the needed KI[CD][23] OTA keys for my sysmoUSIM-SJS1 cards
(thanks Sysmocom support!), and I am able to exercise RFM successfully
on these cards by uncommenting these lines in the shadysim.py script:
# for RFM testing
ac.test_rfm()
exit(0)
It appears that the "tribal" knowledge (not written in any formal
document, AFAICT) of how to use the RFM feature on sysmoUSIM-SJS1
cards exists only in the following code stanzas in shadysim.py, code
that never executes unless you uncomment that ac.test_rfm() call:
def send_wrapped_apdu_rfm_sim(self, data):
# TAR RFM SIM: B00010, sysmoSIM SJS1: MSL = 6, second keyset
return self.send_wrapped_apdu_internal(data, 'B00010', 6, 2, 2)
def send_wrapped_apdu_rfm_usim(self, data):
# TAR RFM USIM: B00011, sysmoSIM SJS1: MSL = 6, third keyset
return self.send_wrapped_apdu_internal(data, 'B00011', 6, 3, 3)
It was only thanks to the above code lines and comments that I learned
that I need to use keyset 2 for SIM RFM, and how else would we know
the needed magic TAR if not for the above code and comments?
In any case, the RFM test function of shadysim.py works like a charm
on my sysmoUSIM-SJS1 cards with the right keys (successfully displays
the IMSI read out via RFM), and I am now going to work on my own C code
that will replace Python and do what I need. However, I also tried
the exact same shadysim.py RFM test function on the newer
sysmoISIM-SJA2 cards, and it does NOT work. I run the exact same
shadysim.py (modified only to uncomment the RFM test) that works
against sysmoUSIM-SJS1, but when I run it against sysmoISIM-SJA2 and
specify the respective card's KIC2 and KID2 from the webshop key data
email, I get this output:
ICCID: 8988211000000471501f
('', '')
Here is the output with a good sysmoUSIM-SJS1:
ICCID: 8988211000000386808f
('089910070000306808', '9000')
Given that the code stays exactly the same and I am merely specifying
different keys as needed for each card, there must be something
different about the new sysmoISIM-SJA2 cards with respect to RFM.
Perhaps the TAR is different? Perhaps the association of which keyset
goes for what is different? Some other differences like different
crypto algorithms being used? Perhaps a migration from 3DES to AES?
I am fine with just using sysmoUSIM-SJS1 for development of my C tools
(tools which will hopefully be extended later to work with other
vendors' SIMs beyond just Sysmocom), but it would be nice to fill in
the knowledge gap regarding sysmoISIM-SJA2 and get these cards to work
as well.
In hacking fellowship,
Mother Mychaela
Hi,
I am Matthias, a TTCN-3 tool developer from Nokia.
Thank you for opening your work. Your repository osmo-ttcn3-hacks helped me
to understand how other developers use TTCN-3 for testing. This gave me
valuable insights for tool development.
I hope I can give something back by opening up our internal TTCN-3 tools as
well. Harald suggested to introduce them on this list. I'd appreciate your
feedback.
Our project is called ntt and it provides various tools for working with
TTCN-3 [1]. For example, you can create a tags file:
$ ntt tags ./osmo-ttcn3-hacks/bts >TAGS
Or you can list things. To filter cyclic imports, for example:
$ ntt list imports ./osmo-ttcn3-hacks/bts | tsort 1>/dev/null
But the most interesting piece is probably the TTCN-3 language server: ntt implements the
language server protocol. This makes ntt a universal TTCN-3 language plugin for
virtually any editor or IDE [2].
It's still very much beta, but we are finishing the Go to Definition feature
(as replacement for ctags files). The next feature would be adding various
diagnostics.
It would be great if you could give ntt a try and share your experience or editor
configuration with me.
This is my first open source project and we still have to figure some stuff
out. So please excuse if there are still some rough edges.
Cheers,
Matthias
[1] https://nokia.github.io/ntt/
[2] https://nokia.github.io/ntt/editors/
Dear all,
we always had said the VTY is a human CLI, while the CTRL interface is for
interfacing with other software. This was primarily related to asking users
to not parse the VTY output of "show" commands or the like. For configuration
via VTY, we have to provide a stable interface anyway, as otherwise loading
config files would not be possible across [non-major] software upgrades.
While that is right in principle, the fact that we don't have a generic configuration
store / API / MIB means that one would explicitly have to add CTRL command for all relevant
settings, which may have been realistic in 2010, but is unrealistic with the hundreds of
VTY configuration parameters today.
I was thinking wither it might make sense to add a generic CTRL interface GET/SET
for "configuration" mode VTY settings. This would mean we write code once,
and immediately expose all our VTY nodes to CTRL.
Thinking of the following example done via VTY:
-----------------------------------
OsmoBSC> enable
OsmoBSC# configure terminal
OsmoBSC(config)# network
OsmoBSC(config-net)# bts 0
OsmoBSC(config-net-bts)# trx 1
OsmoBSC(config-net-bts-trx)# timeslot 0
OsmoBSC(config-net-bts-trx-ts)# training_sequence_code 3
-----------------------------------
We could have something like the following CTRL command:
SET network.bts.0.trx.1.timeslot.0.training_sequence_code 3
The devil is a bit in the details of the syntax
* the normal '.' as separator looks generally OK, I think we have [almost?] no
VTY commands that include a ','
* we somehow need some kind of separator to tell where individual VTY commands are
separated, like
SET network."bts 0"."trx 1"."timeslot 0".training_sequence_code 3
or
SET network|bts.0|trx.1|timeslot.0|training_sequence_code 3
or
SET network#bts.0#trx.1#timeslot.0#training_sequence_code 3
or
SET network.bts#0.trx#1.timeslot#0.training_sequence_code 3
SET network.bts@0.trx@1.timeslot@0.training_sequence_code 3
I think the last examples would be more "natural" for existing CTRL interface code,
as the dot separat separates tokens, and we simply expand the '#' or '@' to spaces in
the context of VTY commands
The generic vty-cfg-via-CTRL code then would basically emulate a user entering
the sequence of commands - including the "exclusion" of not allowing multiple concurrent
VTY or vty-cfg-via-CTRL users at the same time
What do you guys think?
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)
I think this might be of interest to some of the other developers.
Soemtimes we have a problem that the test suite itself is not 100% stable,
and it's not easy to reproduce a test that fails sporadically every Nth
time.
As the "execute" statement in the "control" section actually returns a verdict
type, you can use the following construct in a control section:
control {
for (var integer i := 0; i < 10000; i := i+1) {
var verdicttype v;
v := execute( TC_paging_ps_ptp_lac() );
if (v != pass) {
break;
}
}
}
This way you keep running the test suite until the given test fails for
the first time. Then go do something else for some hour(s) and by the
time you get back, hopefully you will have reproduced the problem.
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, osmocom team members
We have run OsmoGGSN project using the attached config file in this email
and the following command:
osmo-ggsn
As you can see in the config file, we have set IP 127.0.0.2 for GGSN.
After executing the above command, a tunnel named tun4 is created.
To communicate with SGSN, we use the SGSN emulator in OsmoGGSN as follow:
sgsnemu -l 127.0.0.1 -r 127.0.0.2
After executing the above command, we see that 2 packets are sent from SGSN
to GGSN. These packets are "Echo request" and "Create PDP context request"
and GGSN responses to SGSN with the packets "Echo response" and "Create PDP
context response".
To test tun4, we send a GTP <DNS> packet containing an arbitrary query to
GGSN and we see that this GTP <DNS> packet is received in Loopback (lo)
interface and also, the DNS packet is received in tun4 interface. But there
is no DNS response to our query neither in tun4 interface nor lo interface.
A screenshot of the lo interface and tun4 interface in the wireshark is
attached in this email (right is lo and left is tun4).
How can we receive DNS responses to our DNS query? (Does tun4 require
routing or something else?)
--
*When there is much light, The shadow is deep...*
Hello all!
Does anybody have any actual information about the possibility to run
osmo-trx on Ettus E100 board?
I see some references in manuals about the possibility of running
it, but I can't find details on how to do it.
I tried several ways:
1. Build from source on target HW. Unfortunately "autoreconf" crashes
with some perl module dependency.
2. Install binaries. Binaries for arm available only for Debian 9, so
I built an image and installed Debian 9.0 on SD-card. Installation of
binaries was unsuccessful because of some unmet dependencies.
3. Build from scratch on Debian 9.0. I was partially successful in it.
I was able to build osmocore and osmo-trx. The problem was to run it
because now, uhd_find_devices shows an empty list. It looks like that
kernel module usrp_e.ko should be loaded, but I have no idea where to
find its sources.
And one more question: Is it a proper place to ask questions related
to BTS and TRX? Should I move my question to some other mail list?
Thank you
Ivan
Hello,
not many discussions found on OsmoHNBGW topic.
1. Can we connect O' HNBGW directly to SGSN without STP (IPSP mode)?
2. If not, I am wondering do OSMOCOM have development support for IPSP M3UA
mode in SIGTRAN development files or elsewhere?
Thank you in advance, and keep shaking mobile development world.
Mirko K.
Hi Osmocom Community.
I'd like to extend the SMPP protocol alert notifications to be able to
differentiate between IMSI_ATTACH, NORMAL and PERIODIC LURs
The reason is to be able to react to an initial attach by sending a
"Welcome" SMS.
SMPP specifies only three status possibilities:
0 = Available
1 = Disabled
2 = Not Available (Detaching)
I've added 3 for IMSI_ATTACH - Actually I ended up using != PERIODIC
because not all phones send an ATTACH after a DETACH, some send NORMAL LUR.
With this the ESME can respond to an alert notification that has status
3 by looking up the IMSI to see if it's known/autorised etc (this is
outside of osmo-hlr in my use case, although I guess it could also be
done by checking what the HLR says inside the MSC)
Anyway.. I'm wondering if anybody else ever did this, and do we
want/accept this functionality in master osmo-msc?
Or.. any better ideas on how to do it?
Thanks
k/
Hi Community,
Happy New Year!
Would like to ask if anyone here have experience integrating OsmoBSC to Nokia MSC? Currently we are doing the integration in Nokia MSC and we encountered issue. Basically, in the SCCP part, the BSC is trying to send UDT (BSSAP) Reset but no response from the MSC. After the default timer of the RESET, we observed a SACK SST and SACK UDTS. In the SACK SST, we saw the trace that there is no Calling indicator which is my BSC point code. When checking the trace we saw this Affected Subsystem Number: 254. I’ve red some documentations in OSMO but I don’t find any SCCP management configuration in OSMO so I think this one is on MSC side. Below is the Trace we captured.
BSC Point code - 2262
Nokia Point code - 7039
Regards,
Sonny
