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
== OsmoCon 2018 ==
OsmoCon (Osmocom Conference) 2018 is the technical conference for
Osmocom users, operators and developers!
We are happy to announce the date of OsmoCon 2018. It has been scheduled
on October 18 + 19, 2018 and will happen in Berlin, Germany.
For the second time, the Osmocom Conference brings together users,
operators and developers of the Osmocom Open Source cellular
infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN
and others.
Join us for two days of presentations and discussions with the main
developers behind Open Source Mobile Communications, as well as
commercial and non-profit users of the Osmocom cellular infrastructure
software.
You can find some initial information in our wiki at
http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018
which will be updated as more information becomes available.
== Call for Participation ==
We're also at the same time announcing the Call for Participation and
call on everyone with experiences to share around the Osmocom member
projects to submit talks, workshops, discussions or other proposals.
You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp
We are particularly looking for contributions about:
* updates on features/functionality/status of individual Osmocom projects
* success stories on how Osmocom projects are deployed in practice
* migration from OsmoNITB to the post-NITB architecture
* tutorials / workshops on how to setup / analyze Osmocom projects
* statistics, reporting, operations aspects of Osmocom projects
* third-party open source utilities to be used with Osmocom projects
Looking forward to meeting many existing and new Osmocom users at OsmCon
this October!
Regards,
Harald Welte
--
- 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)
Good morning,
I wanted to get inter-BSC handover complete before today, and worked like a
maniac for the last two weeks.
I'm looking forward to your comments on the osmo-bsc rework, which started so
small and rippled through the entire code base like a flash flood. I hope you
will find review of it not too daunting, it fully qualifies as a code bomb.
It is refactoring no less than:
- dynamic timeslots,
- lchan states from allocation through release,
- assignment,
- handover
- handling of MGW endpoints, and
- the conn FSM.
- gsm_network->T123 timer handling,
- the way a BTS's neighbors are configured,
- handover and assignment rate counters,
- and whatnot.
- adding five new FSM implementations to osmo-bsc,
- and actually adding inter-BSC Handover, both sides (almost).
Of course I couldn't wrap things up completely, but the good news is that the
only problem left now is that I can't get a ttcn3 test written for inter-bsc MT
handover [1]. Consider the MT side broken yet, though it should be small fixes.
So the refactoring is done and all ttcn3-bsc-tests pass. Yes, *all*!
I will now submit the patches to gerrit; some though could want to go to
libosmocore, and for some other "neat" inventions of mine I'm watching the
comment space in curiosity.
I did try to separate some changes into individual commits, but the final chunk
is too inter-related to pull it apart without spending huge amounts of time to
make osmo-bsc work for each intermediate state.
I feel both like saying "sorry" and "you're welcome" about this at the same
time. Sorry about the size of the single patch; but a lot of code got extremely
easier to read and follow, and a lot safer too, into a nicer osmo-bsc future.
~N
[1]
I have a marginal test added for inter-bsc MO, but the inter-bsc MT gets me.
The problem there is that it is the first time a conn is initiated by the MSC
side. I can get that to work by using BSSAP on that Test_CT. It goes well up to
the point where osmo-bsc sends MGCP CRCX and expects a response. Now I want to
use the MSC_ConnHdlr to manage MGCP, but I can't for the life of me figure out
how to be able to do both at the same time. I tried for very long to resolve
"BSC_Tests.ttcn:2755.13-2756.31: error: Message type `(a)BSSAP_CodecPort.BSSAP_N_CONNECT_req' is not present on the outgoing list of port type `(a)BSSMAP_Emulation.BSSAP_Conn_PT'"
but it feels like a brick wall...
It's the final thing before I can say: I'm done, take a look at inter-BSC HO.
Hello,
I've had success with running a NITB based on the new architecture fine
when everything is on one host. However, I'd now like to split this
across multiple hosts. I have one host dedicated to running osmo-stp and
this appears to bind to the IP specified. However, the instance of
osmo-bsc running on another host always fails to connect and I think,
despite configuring to use a remote STP, it's trying localhost.
Packages installed from Debian 9.0/latest repo. Configs and osmo-bsc
output below. Any pointers as to where I'm going wrong would be much
appreciated.
Regards,
Andrew
//
**** osmo-bsc output:
$ sudo /usr/bin/osmo-bsc -c /etc/osmocom/osmo-bsc.cfg
<001d> osmo_ss7.c:1269 0: ASP Restart for server not implemented yet!
% GPRS not enabled on this BTS
% GPRS not enabled on this BTS
% GPRS not enabled on this BTS
% GPRS not enabled on this BTS
% GPRS not enabled on this BTS
% GPRS not enabled on this BTS
% Line 0 already exists
<0011> telnet_interface.c:104 telnet at 10.1.1.7 4242
<0013> input/ipaccess.c:853 enabling ipaccess BSC mode on 10.1.1.7 with
OML 3002 and RSL 3003 TCP ports
<0018> control_if.c:863 CTRL at 127.0.0.1 4249
<0008> osmo_bsc_sigtran.c:427 Initializing SCCP connection to MSC msc-0
<0008> osmo_bsc_sigtran.c:437 CS7 Instance identifier, A-Interface: 0
<001e> sccp_user.c:397 msc-0: Using SS7 instance 0, pc:0.0.2
<001e> sccp_user.c:411 msc-0: Creating AS instance
<001e> sccp_user.c:421 msc-0: Using AS instance as-clnt-msc-0
<001e> sccp_user.c:426 msc-0: Creating default route
<001e> sccp_user.c:446 msc-0: Creating ASP instance
<0011> socket.c:266 unable to connect socket: (null):2905: Connection
refused
<0011> socket.c:279 no suitable remote addr found for: (null):2905
<001d> osmo_ss7.c:1253 0: Unable to open stream client for ASP
asp-clnt-msc-0
<001e> sccp_user.c:481 msc-0: Using ASP instance asp-clnt-msc-0
<001e> sccp_user.c:484 msc-0: Creating SCCP instance
<0008> osmo_bsc_sigtran.c:480 (msc-0) A-interface: local (BSC) SCCP
address: RI=SSN_PC,PC=0.0.2,SSN=BSSAP
<0008> osmo_bsc_sigtran.c:482 (msc-0) A-interface: remote (MSC) SCCP
address: RI=SSN_PC,PC=0.0.1,SSN=BSSAP
<0013> input/ipa.c:265 accept()ed new link from 10.1.1.8 to port 3002
<0005> abis_nm.c:506 BTS0 feature 'EGPRS' reported via OML does not
match statically set feature: 0 != 1. Please fix.
<0005> abis_nm.c:506 BTS0 feature 'OML Alerts' reported via OML does not
match statically set feature: 1 != 0. Please fix.
<0005> abis_nm.c:506 BTS0 feature 'Fullrate speech V1' reported via OML
does not match statically set feature: 1 != 0. Please fix.
<0005> abis_nm.c:506 BTS0 feature 'Halfrate speech V1' reported via OML
does not match statically set feature: 1 != 0. Please fix.
<0005> abis_nm.c:506 BTS0 feature 'Fullrate speech EFR' reported via OML
does not match statically set feature: 1 != 0. Please fix.
<0005> abis_nm.c:506 BTS0 feature 'Fullrate speech AMR' reported via OML
does not match statically set feature: 1 != 0. Please fix.
<0005> abis_nm.c:506 BTS0 feature 'Halfrate speech AMR' reported via OML
does not match statically set feature: 1 != 0. Please fix.
<0005> abis_nm.c:573 OC=BTS(01) INST=(00,ff,ff): BTS0: ARI reported
sw[0/2]: osmobts is 0.8.1
<0005> abis_nm.c:445 BTS0 reported variant: omso-bts-trx
<0005> abis_nm.c:467 BTS0 Attribute Manufacturer Dependent State is
unreported
<0005> abis_nm.c:573 OC=BTS(01) INST=(00,ff,ff): BTS0: ARI reported
sw[0/1]: TRX_PHY_VERSION is Unknown
<0005> abis_nm.c:2809 IPA RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00
<0013> input/ipa.c:265 accept()ed new link from 10.1.1.8 to port 3003
<0004> bsc_init.c:333 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 868
using MCC-MNC 901-70 LAC=23 CID=0 BSIC=63
<0004> abis_rsl.c:2502 (bts=0,trx=0,ts=2,pchan=TCH/F_TCH/H_PDCH as
NONE): GPRS mode is 'none': not activating PDCH.
<0004> abis_rsl.c:2502 (bts=0,trx=0,ts=3,pchan=TCH/F_TCH/H_PDCH as
NONE): GPRS mode is 'none': not activating PDCH.
<0004> abis_rsl.c:2502 (bts=0,trx=0,ts=4,pchan=TCH/F_TCH/H_PDCH as
NONE): GPRS mode is 'none': not activating PDCH.
<0004> abis_rsl.c:2502 (bts=0,trx=0,ts=5,pchan=TCH/F_TCH/H_PDCH as
NONE): GPRS mode is 'none': not activating PDCH.
<0004> abis_rsl.c:2502 (bts=0,trx=0,ts=6,pchan=TCH/F_TCH/H_PDCH as
NONE): GPRS mode is 'none': not activating PDCH.
<0008> a_reset.c:92 A-RESET(msc-0)[0x1d6fff0]{DISC}: (re)sending BSSMAP
RESET message...
<0008> osmo_bsc_sigtran.c:92 Sending RESET to MSC:
RI=SSN_PC,PC=0.0.1,SSN=BSSAP
<001d> m3ua.c:507 XUA_AS(as-clnt-msc-0)[0x1d6f7e8]{AS_DOWN}: Event
AS-TRANSFER.req not permitted
<0008> a_reset.c:92 A-RESET(msc-0)[0x1d6fff0]{DISC}: (re)sending BSSMAP
RESET message...
<0008> osmo_bsc_sigtran.c:92 Sending RESET to MSC:
RI=SSN_PC,PC=0.0.1,SSN=BSSAP
<001d> m3ua.c:507 XUA_AS(as-clnt-msc-0)[0x1d6f7e8]{AS_DOWN}: Event
AS-TRANSFER.req not permitted
<0011> socket.c:266 unable to connect socket: (null):2905: Connection
refused
<0011> socket.c:279 no suitable remote addr found for: (null):2905
<0008> a_reset.c:92 A-RESET(msc-0)[0x1d6fff0]{DISC}: (re)sending BSSMAP
RESET message...
<0008> osmo_bsc_sigtran.c:92 Sending RESET to MSC:
RI=SSN_PC,PC=0.0.1,SSN=BSSAP
<001d> m3ua.c:507 XUA_AS(as-clnt-msc-0)[0x1d6f7e8]{AS_DOWN}: Event
AS-TRANSFER.req not permitted
^Csignal 2 received
<0005> bsc_init.c:96 shutting down OML for BTS 0
**** osmo-bsc.cfg:
e1_input
e1_line 0 driver ipa
ipa bind 10.1.1.7
cs7 instance 0
point-code 0.0.2
asp circ-OsmoBSC 2905 0 m3ua
remote-ip 10.1.1.5
sccp-address msc_remote
point-code 0.0.1
line vty
bind 10.1.1.7
msc
msc-addr msc_remote
network
network country code 901
mobile network code 70
bts 0
type sysmobts
band GSM-1800
location_area_code 23
ip.access unit_id 1800 0
gprs mode none
gprs nsvc 0 remote ip 192.168.0.9
gprs nsvc 0 remote udp port 23000
gprs nsvc 0 local udp port 23000
gprs nsvc 0 nsvci 1800
gprs nsei 1800
gprs cell bvci 1800
trx 0
rf_locked 0
arfcn 868
nominal power 23
timeslot 0
phys_chan_config CCCH+SDCCH4
timeslot 1
phys_chan_config SDCCH8
timeslot 2
phys_chan_config TCH/F_TCH/H_PDCH
timeslot 3
phys_chan_config TCH/F_TCH/H_PDCH
timeslot 4
phys_chan_config TCH/F_TCH/H_PDCH
timeslot 5
phys_chan_config TCH/F_TCH/H_PDCH
timeslot 6
phys_chan_config TCH/F_TCH/H_PDCH
timeslot 7
phys_chan_config PDCH
e1_input
e1_line 0 driver ipa
msc 0
mgw remote-ip 10.1.1.6
mgw remote-port 2427
allow-emergency deny
codec-list hr3
**** osmo-stp.cfg:
log stderr
logging filter all 1
logging color 1
logging print category 1
logging timestamp 0
logging level lss7 debug
logging level lsccp debug
logging level lsua debug
logging level lm3ua debug
cs7 instance 0
xua rkm routing-key-allocation dynamic-permitted
listen m3ua 2905
accept-asp-connections dynamic-permitted
local-ip 10.1.1.5
listen sua 14001
local-ip 10.1.1.5
line vty
bind 10.1.1.5
Hello. I have some problems.I want to create a GSM network for my final
diploma project for University.I'm using USRP2 and I haven't find any
specific configuration files for this type of USRP.Do you have any
configuration files for USRP2? I'm running Kali Linux (amd64). I've
attached the config files that I've used from osmocom.org and some
printscreens.Sorry for my English.I'm looking forward for your
response.Thank you!
Hi, sorry for my English. I installed osmocombb on Kali rolling. When i'm
trying to start my own bts, it works for 4 seconds, then i can see message
"Shutdown timer expired". Bellow you can see my config files. 1 screenshot
- 2 trx firmware on motorola c115. 2 screenshot, left - follow the
commercial BTS timer, right - starting MSC, SMS, HLR. 3 screenshot -
starting osmo-bts. 4 screen - my problem. I can connect with telnet to BSC
and BTS, but BTS - only for this 4 seconds, when it's up. I didn't replaced
filters on motorola, is it my problem? Or i just need to install smth more?
Also, if i write to the wrong mail list, tell me please where should i
write with my problem?
Hi there,
I have built and installed the requirements for OpenBTS and my USRP (Ettus N210) is responding but now I am stuck at SIM card stage. I am trying to program a Super SIM 16-in-1 using the Insten_USB_SIM_Card_Writer<https://www.amazon.com/Insten-Reader-Writer-Backup-Phone/dp/B0188GHIP2/ref=…> and following the steps mentioned here<http://openbts.org/w/index.php?title=ProgrammingSIMcards> and here<http://osmocom.org/projects/pysim/wiki> but unable to write the sim card. Every time I run the pcsc_scan command it stops working. Below is the output.
"wslopenbts@wslopenbts-desktop:~$ pcsc_scan
PC/SC device scanner
V 1.4.25 (c) 2001-2011, Ludovic Rousseau <ludovic.rousseau(a)free.fr>
Compiled with PC/SC lite version: 1.8.14
Using reader plug'n play mechanism
Scanning present readers...
Waiting for the first reader...^C"
The problem seems that the PC is not getting the SIM card reader. But the SIM card reader was plugged into the PC while running the command and the LED turned red which indicate it was getting the power from the PC. Do you think, buying another new SIM card reader can resolve the issue? I can test by buying another SIM and SIM card reader; Do any of you have any suggestion for the SIM and SIM card reader, particularly which one will be good? Finally, any guideline for me regarding programming the SIM card. I will be very grateful if you help me by giving suggestions to resolve my issue.
Can anyone please help me regarding this issue.
Thanks in advance
Best Regards,
Farah
Hello folks,
I had trouble with the osmo-trx-uhd and LimeSDR (like in Bug #2723), so I
tried the branch "laforge/lime".
The result is that the LimeSDR apparently transmit successfully data (my MS
display correctly the MCC/MNC and the spectro shows the correct frequency)
but it seems that the LimeSDR/driver/not-sure-what does not receive any
signal in return.
I know that my complete hardware and software setup (cables, tem cell,
spectro) is OK because it works fine with the Fairwaves UmTRX board.
The LimeSuiteGUI shows some problems with the RX calibration, but if I do a
full reset to default settings from the GUI, it works fine (so I suppose
that the problem does not come from the LimeSDR board itself).
If I restart osmo-trx-lms, it cause the problem again.
Is there some specific settings to do in osmo-trx.cfg to make it work?
I know that it is a work in progress, and if you need some feedback or
tests, do not hesitate to ask.
Have a nice day,
Antony
