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
Hi everyone, i would like to know if it is possible to connect a bts which
uses abis over sctp to OpenBSC and if so i would kindly ask for an
explenation on how to do that.
Kind thanks.
Hello all,
I have recently tried migrating an OsmoNITB setup to the new standard using mostly this guide right here: https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_I… <https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_I…>
However, while my nanoBTS works perfectly fine in the old setup, it just doesn not work at all in the new one. When I start osmo-bsc the LED on the BTS starts flashing green after a few seconds and then stops flashing and just stays green all the time, which is the expected behaviour. Unfortunately though, after another couple of seconds, the LED starts flashing green again and then turns red.
This is what the log shows:
BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=l2_bch.c:1154
****
** l2_bch.c#1154:BCHbcchSItypeValid( prim_p->infoType )
** IPA_SW_FATAL_ERROR
** In task "TRX Proc:L2_BCH" @ (1063).
****
.
BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=TRX Proc:L2_BCH:l2_bch.c#1154 (1063).
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=31385:WARN:OAM_RES:trx_fatal_error_log.c#255:TRX has logged the error:
.
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=31385:WARN:OAM_RES:trx_fatal_error_log.c#256:TRX Proc:L2_BCH:l2_bch.c#1154 (1063)
.
BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=BCHbcchSItypeValid( prim_p->infoType ).
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=31385:WARN:OAM_RES:trx_fatal_error_log.c#260:BCHbcchSItypeValid( prim_p->infoType )
20180328072641280 DLINP <0013> input/ipaccess.c:247 Sign link vanished, dead socket
20180328072641281 DLINP <0013> input/ipaccess.c:71 Forcing socket shutdown with no signal link set
20180328072641282 DCTRL <000e> osmo_bsc_ctrl.c:160 No more BTS connected, sending TRAP.
Now I'm not claiming that my config is already 100% correct but I feel like this isn't a configuration issue. I'm using the most recent nightly builds of the entire osmocom library.
Does anyone know what could be at fault here?
Kind regards,
Michael Spahn
Hi All,
I have a use case where I'd like to react to MS connecting to the
network, that is on initial IMSI ATTACH.
We already have the SMPP alert notification mechanism which can be used,
but unfortunately in SMPP the ms_availability_status only has 3 posible
values in the spec:
0: Available
1: Denied
2: Unavailable.
So currently if I react to status 0, this would also happen on periodic LURs
I could keep state separately but that sounds prone to errors.
The external process reacting to the alert notification could try
somehow to get the previous status from HLR or database, but that sounds
like a race condition.
One possibility might be to extend this with a further custom value 3:
Available (Initial Attach) or some such?
Any thoughts?
Hello All,
Sorry if this is an off-topic question, but I was wondering: does anyone know of any carrier that actually uses a UICC ('SIM card') with the ISIM application installed? So far all cards I saw have only USIM, maybe CSIM on them. I'd like to extend Benoit's card library with ISIM support, but there is no way to test my code right now, so I'm thinking about buying maybe a card.
Thanks.
Domi
Hi all
Somebody mentioned recently (at osmodevcon was it?) about writing to the
FPLMNS list to avoid service loss due to
LUR reject cause 11 (I think?)
I notice we don't seem to have this an a option in pySim-prog.py, so I
am wondering what tool was used?
Thanks!
(I noted the commented FIXME section for HPLMN in pySim.read.py and from
there was able to modify read address and read and decipher the FPLMN
list, although i did not get a nice readable output format yet.)
I received following error while compling osmo-trx on rasbian, i have already build libosmocore-0-11-0 from source and installed but despite this still unable to compile osmo-trx, any one can help to resolve the issue!
configure: error: Package requirements (libosmocore >= 0.11.0) were not met:
Requested ‘libosmocore >= 0.11.0’ but version of Osmocom Core Library is UNKNOWN
Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix.”
I have already build following components on Rasbian from source successfully
LimeSuite SoapySDR SoapyUHD libosmocore-0.11.0/ libosmocore-0.96.0
RegardsBabar
Dear list,
I have question about osmo-trx config with osmo-bts-trx.
if in osmo-bts-trx
osmotrx ip local 192.168.100.73
osmotrx ip remote 192.168.100.100
then what ip address fill on osmo-trx for limesdr.cfg?
bind-ip 192.168.100.73
remote-ip 192.168.100.100
Please correct me, cause I confuse osmo-trx won't running if not using same
ip as 127.0.0.1
well,
Does 127.0.0.1 is fine for only sms/call network in new split?
please advise. Thanks.
--
Best Regards,
DUO
Dear Osmocom community,
one of the main difficulty with OsmoCon 2017 last year was that nobody
submitted talks / discussions within the deadline, early enough to allow
for proper planning.
This lead to the situation where the sysmocom team had to come up with
a schedule/agenda on their own. Later on *much after the CfP deadline*,
people then squeezed in talks, making the overall schedule too full.
It is up to you to avoid this situation again in 2018 by submitting your
talk *RIGHT NOW*. We will be very strict regarding late submissions. So
if you would like to shape the Agenda of OsmoCon 2018, this is your
chance. Please use it.
We will have to create a schedule soon, as [almost] nobody will register
to a conference unless the schedule is known. If there's not sufficient
contribution in terms of CfP response from the wider community, don't
complain later that 90% of the talks are from sysmocom team members and
only about the Cellular Network Infrastructure topics.
You have been warned. Please make your CfP submission in time at
https://pretalx.sysmocom.de/osmocon2018/cfp
before the CfP deadline on
*2018-05-30 23:59 (Europe/Berlin)*
Thanks for your kind attention. Looking forward to meet with the
community at OsmoCon 2018 in October.
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)
