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
Hi all,
I am currently working on https://gerrit.osmocom.org/#/c/2075/
The problem is that the conv.h should be shared between several
source code files, and it works fine for all of them, excepting
the gsm0503_test_vectors.c, which will be generated automatically
by the utils/conv_gen.py in the next commit.
The header is currently included this way:
#include "conv.h"
And building in separate directory fails:
CC conv/gsm0503_test_vectors.o
conv/gsm0503_test_vectors.c:25:18: fatal error:
conv.h: No such file or directory
#include "conv.h"
^
compilation terminated.
This is why I tried to move this header to the global include
directory. According to received feedback from Harald and
Sylvain, this approach isn't good and I need to find another one.
Any suggestions how to make the conv/gsm0503_test_vectors.c
able "to see" the conv.h header?
With best regards,
Vadim Yanitskiy.
Hi All,
Upon running "osmo-bts-trx -c osmo-bts.cfg” while "osmo-nitb -C -c openbsc.conf -T -P -m” and “osmo-trx” are running, the following error shows and also shuts down “osmo-trx”
osmo-bts-trx error:
root@entropy:~/osmocom_files# osmo-bts-trx -c osmo-bts.cfg
((*))
|
/ \ OsmoBTS
<0017> control_if.c:725 CTRL at 127.0.0.1 4238
<0010> telnet_interface.c:95 telnet at 127.0.0.1 4241
<0012> input/ipaccess.c:885 enabling ipaccess BTS mode, OML connecting to 192.168.1.129:3002
<000b> trx_if.c:584 Open transceiver for phy0.0
<0012> input/ipa.c:129 connection done.
<0012> input/ipaccess.c:706 received ID get
<0001> oml.c:475 Ignoring T200[0] (150 ms) as sent by BSC due to suspected LAPDm bug!
<0001> oml.c:475 Ignoring T200[1] (180 ms) as sent by BSC due to suspected LAPDm bug!
<0001> oml.c:475 Ignoring T200[2] (180 ms) as sent by BSC due to suspected LAPDm bug!
<0001> oml.c:475 Ignoring T200[3] (1680 ms) as sent by BSC due to suspected LAPDm bug!
<0001> oml.c:475 Ignoring T200[4] (520 ms) as sent by BSC due to suspected LAPDm bug!
<0001> oml.c:475 Ignoring T200[5] (165 ms) as sent by BSC due to suspected LAPDm bug!
<0001> oml.c:475 Ignoring T200[6] (1680 ms) as sent by BSC due to suspected LAPDm bug!
<0001> oml.c:844 ADM state already was Unlocked
<0012> input/ipa.c:129 connection done.
<0012> input/ipaccess.c:706 received ID get
<0009> pcu_sock.c:651 PCU socket not connected, dropping message
<0009> pcu_sock.c:651 PCU socket not connected, dropping message
<0009> pcu_sock.c:651 PCU socket not connected, dropping message
<0009> pcu_sock.c:651 PCU socket not connected, dropping message
<0009> pcu_sock.c:651 PCU socket not connected, dropping message
<0009> pcu_sock.c:651 PCU socket not connected, dropping message
<0009> pcu_sock.c:651 PCU socket not connected, dropping message
<0009> pcu_sock.c:651 PCU socket not connected, dropping message
<0009> pcu_sock.c:651 PCU socket not connected, dropping message
<0009> pcu_sock.c:651 PCU socket not connected, dropping message
<0009> pcu_sock.c:651 PCU socket not connected, dropping message
<0009> pcu_sock.c:651 PCU socket not connected, dropping message
<000b> trx_if.c:187 No response from transceiver for phy0.0
<0009> pcu_sock.c:848 PCU socket connected to external PCU
<0001> oml.c:72 Reporting FAILURE to BSC: 0.3.20170425
<0000> rsl.c:624 (bts=0,trx=0,ts=4,ss=0) not sending CHAN ACT ACK
<0000> rsl.c:624 (bts=0,trx=0,ts=5,ss=0) not sending CHAN ACT ACK
<0000> rsl.c:624 (bts=0,trx=0,ts=6,ss=0) not sending CHAN ACT ACK
<0000> rsl.c:624 (bts=0,trx=0,ts=7,ss=0) not sending CHAN ACT ACK
<000b> trx_if.c:187 No response from transceiver for phy0.0
<000b> trx_if.c:187 No response from transceiver for phy0.0
<000b> trx_if.c:187 No response from transceiver for phy0.0
<000b> trx_if.c:187 No response from transceiver for phy0.0
<000b> trx_if.c:187 No response from transceiver for phy0.0
<000b> trx_if.c:187 No response from transceiver for phy0.0
<000b> trx_if.c:187 No response from transceiver for phy0.0
<000b> trx_if.c:187 No response from transceiver for phy0.0
<0007> l1sap.c:413 Invalid condition detected: Frame difference is > 1!
<0001> bts.c:208 Shutting down BTS 0, Reason No clock from osmo-trx
<000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix!
<000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix!
<0000> rsl.c:528 (bts=0,trx=0,ts=4,ss=0) not sending REL ACK
<000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix!
<000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix!
<0000> rsl.c:528 (bts=0,trx=0,ts=5,ss=0) not sending REL ACK
<000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix!
<000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix!
<0000> rsl.c:528 (bts=0,trx=0,ts=6,ss=0) not sending REL ACK
<000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix!
<000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix!
<0000> rsl.c:528 (bts=0,trx=0,ts=7,ss=0) not sending REL ACK
Shutdown timer expired
osmo-trx logs:
NOTICE 139966735525632 16:51:01.4 Transceiver.cpp:794:driveControl: Changing TSC from 0 to 7
NOTICE 139966735525632 16:51:01.4 Transceiver.cpp:243:start: Starting the transceiver
Illegal instruction (core dumped)
osmo-nitb logs:
Thu Apr 27 16:50:43 2017 <001e> input/ipa.c:263 accept()ed new link from 192.168.1.129 to port 3002
Thu Apr 27 16:50:43 2017 <001e> input/ipa.c:263 accept()ed new link from 192.168.1.129 to port 3003
Thu Apr 27 16:50:43 2017 <0004> bsc_init.c:288 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 885 using MCC=1 MNC=1 LAC=1 CID=1 BSIC=63
BTS 0 reported connected PCU version 0.3.20170425
Thu Apr 27 16:51:06 2017 <001e> input/ipaccess.c:241 Sign link vanished, dead socket
Thu Apr 27 16:51:06 2017 <001e> input/ipaccess.c:69 Forcing socket shutdown with no signal link set
Thu Apr 27 16:51:06 2017 <0020> bsc_init.c:341 Lost some E1 TEI link: 1 0x7f5f48820070
Thu Apr 27 16:51:06 2017 <0020> bsc_init.c:341 Lost some E1 TEI link: 2 0x7f5f48820070
^Csignal 2 received
Also attached the configuration files used.
What seems causes the issue?
OS: Ubuntu 16.04
SDR: B210
Best Regards,
Ron Rylan B. Menez
Operations Manager
+63 998 989 7973
+63 2 893 1781
[cid:bbb8aa9b-ea08-431b-bb55-8cc77a18e169@apcprd06.prod.outlook.com]
Singapore * Philippines
Products:
Gridloc*Intelle*Hype*Lighthouse*Telco Services*Software Development
This email (including any attachment to it) is confidential and intended only for the use of the individual named above and may contain information that is privileged. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or telephone and destroy the original message (including any attachment to it). Thank you.
Hello,
is it possible to connect the openbsc from the vlr_3G Branch with sip-connector to asterisk as described on https://osmocom.org/projects/osmo-sip-conector/wiki/Osmo-sip-connector, or are there changes in the vlr_3G Branch that makes this impossible?
When trying to set this up I was able to call an UMTS-Phone which was connected to the nano3G from a softphone using jitsi, and the UMTS-Phone was ringing, but it was not possible to answer the call.
I have only limited experiences with asterisk and so I am for example unsure about what voice-codecs to use, if my asterisk-config is correct,... and so I would like to know if it should work in principle and I have to find the correct configuration.
have a nice weekend,
Andreas
Hi,
for the topic of making "releases" I wondered if we want to explore using "repo" to tie the different Osmocom repositories into a single "release". Below is an example "default.xml" that would make up a release. The default.xml would be maintained in a git repository that we could tag, e.g. something like v201704.1 (vYYYYMM.MINOR).
I could envision we have:
* A simple build shell script to build/install everything
* A script to update (and tag) the default.xml to make new releases available.
How to use it (if repo is installed):
repo init -u git://git.osmocom.org/osmocom-cellular-manifest
repo sync
./build_all.sh --prefix=/opt/cellular
aand on a new release
repo sync
./build_all.sh ...
ideas? comments?
holger
default.xml:
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remote fetch="git://git.osmocom.org" review="gerrit.osmocom.org" name="osmocom"/>
<default revision="refs/heads/master" remote="osmocom"/>
<!-- base libraries -->
<project name="libosmocore" revision="9e83c3d5ca64428befe74e5aad61bd84bccaf309"/>
<project name="libosmo-abis" revision="bf7976c0b0076410ad1bd67061dd18d0f33a7f43"/>
<project name="libosmo-netif" revision="c108c9db969c4d4abaccc88419b4ac0c44957365"/>
<project name="libsmpp34" revision="cc0bcd6bc051d5ccaf32cdbbc28f073369900857"/>
<project name="libosmo-sccp" revision="57d0449d4ed5d82050c52551c8ad6195db38fdf1"/>
<!-- RAN -->
<project name="osmo-trx" revision="de116e90c03c534fa4b51ef40dfd2bb9e843c86e"/>
<project name="osmo-bts" revision="25742a5929edecc545a4fc254f678cc834f8c3b3"/>
<project name="osmo-pcu" revision="e6d26ec09c2bcd2126416a58cb23af27318ec67e"/>
<project name="osmo-iuh" revision="46fea15afc38fb995baf4100f4de1d6a3565899f"/>
<project name="openggsn" revision="19e19e3609508d121ba46c165e5ed1502a3cf9da"/>
<project name="openbsc" revision="d75f11e6f26a50c11f73625de5c0833971900cde"/>
<project name="osmo-sip-connector" revision="417f2542163edfe8ac8729918e2452dc7787a3d7"/>
<!-- Core -->
<project name="osmo-hlr" revision="743cf42ac5dfa2661317e73f70b204bde7450ff2"/>
<!-- Misc -->
<project name="osmo-gsm-manuals" revision="4b593a2259a107211489940b8b59f44219e73b2d"/>
<!-- Copying a build script to the top level directory -->
<project name="osmo-ci" revision="e72f35cfa9969e52d0018ba4661f4519519c39ba">
<linkfile src="build/build.sh" dest="build.sh"/>
</project>
<project name="python/osmo-python-tests" path="osmo-python-tests" revision="baa6f12260c383f40a477b71743b16940c50e5aa"/>
</manifest>
Just asked holger: the osmo-stp build from cellmgr in the nightly debian
packages can be switched off. Since you've been fixing debian these days, could
you do that one as well? Hopefully we will have no more failures then.
(...except on the new ubuntu 17.04 of course, no idea what's up with that. Not
sure who added it and who will resolve those, or whether that's already done?)
Thanks!
~N
