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
If the SIP server dies in the middle of a call, osmo-sip-connector is in a
bad state and generates a never ending stream of error messages:
58): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f25
It looks like the messages are generated from sofia-sip and I have managed
to suppress the messages by setting the environment variable SU_DEBUG < 3:
http://sofia-sip.sourcearchive.com/documentation/1.12.7/tport__internal_8h_…
However, it looks like osmo-sip-connector is clearly in a bad state when
this happens and we need a way to detect and release these ghosted calls.
Hi,
The virtual layer 1 is currently in a state where the l23 app can
successfully connect to the bts and most of the signaling messages
will be forwarded and handled. TCH is not yet implemented.
I have some problems still, not knowing if these are caused by
configuration problems or my coding :).
- Trying to initiate a call via the mobile vty will result in
VTY:
call 1 123
OsmocomBB#
% (MS 1)
% Call has been rejected
call 1 123
OsmocomBB#
% (MS 1)
% Call has been released
And no actual call setup message is transfered over the Um interface.
What could be reasons for that? I am using the test-sim option the
mobile app offers.
- Occasionaly the T3210 timer is fired, which causes a new registering
within the network.
LOG:
gsm48_mm.c:336 timer T3210 (loc. upd. timeout) has fired
How can i prevent that?
- I did not implement a tdma or multiframe scheduler in the mobile
uplink as the logical channel is directly put to the gsmtap-header and
thus known by the bts. As Harald used a multiframe based scheduling
for the bts downlink, i wonder if this might be necessary, though. To
submit msgs with the correct frame number for example.
- In my wireshark capture files, the gsmtap messages sent over the
multicast sockets are only recognized as UDP messages. I have to
"cast" them with the wireshark context menu "Decode as...". Why?
I would be super happy if someone of you could check out my project
(osmo-bts, branch stumpf/virt-phy + osmocom-bb, branch
stumpf/virt-phy) try to run it with the config files lying within the
project folders and tell me the problems they see :).
Here you can find a wireshark capture file of 2 mobiles connecting to
a virt bts. I also tried to init calls from both of them but the call
setup is not send.
https://www.dropbox.com/s/2ccky4ljc8ngahz/mobilex2--ms-virt--bts-virt--bsc-…
Kind Regards,
Sebastian Stumpf
Hi list, Hi all.
This is quite Rhizomatica, or at least litecel 2050 specific, please
excuse me for that. I also don't know, maybe it applies to other use cases.
Rhizomatica has one community where an attempt was made to increase
coverage at the same time as capacity, by installing two 2050s with a
somewhat overlapping coverage area. We have currently plans to do the
same in other places.
The goal of this email is to try to establish the work needed to be done
in order to fix what I outline below, I may just be lacking knowledge in
some cases, in other It seems we need to implement some things.
I have grabbed fairwaves' meas_json and meas_web and modified a little
to give me a visualisation of the neighbour meas reports.
So my first doubt is about idle cell reselection on the part of the MS.
It doesn't seem to be operating quite as I would imagine it should and I
am wondering is there any parameter that might make a difference, such
as cell_identity? Is cell reselection hysteresis/offset relevant when
handover is disabled? These parameters are not described in the manual.
If I understood them I could update that. In the meantime, we seem to be
getting reports from users that "the signal is weak" near what I might
call the secondary BTS. At the same time, user reports are not terribly
reliable. However what seems to be happening is that the MS is camped on
the primary BTS, subsequently they have moved away so their handset is
showing less 'bars'. I'm sometimes seeing TCH in use on the primary BTS
that are showing neighbour measurements from the secondary that are more
favourable.
Of course, I am often seeing messages such as:
handover_decision.c:203 (bts=3,trx=0,ts=2): Cell on ARFCN 242 is better:
Skipping, Handover disabled
Obviously, this makes sense, and I am not sure why historically we have
handover disabled, I presume it is issues with rtp, although we are
using the rtp_proxy. I don't have two BTS so I can't test locally here.
Could anybody comment on the state of that?
I am assuming that there is no way we can do load balancing unless we
first have handover enabled, at the same time it is unclear to me if it
will even work with handover. I believe this is called "Traffic
Handover" Is this already implemented in the BSC? As in, can the BSC
assign a channel on another ARFCN to the MS if the current ARFCN (the
one the MS makes the access request on) has no TCH available?
I also have a doubt about operation with a Litecel/2050. Obviously you
don't really want rescue handover operating between the two BTS that are
present in the Litecel as it is the same antenna, and this shouldn't
happen anyway as the signal levels should never be sufficiently
different, but we do want load balancing handover. I do see "no
resources available" log messages, (especially related to the BROKEN
channels issue) when one BTS in a litecel has no more capacity but the
other does, so it would seem that the BSC is not managing this. Is that
correct?
Would it be correct to assume that maybe some handover rules are
required that would specify: Handover from BTS 0 to BTS 3 but not from
BTS 0 to BTS 1?
Finally, I have a doubt about the rtp proxy mode. Was it ever discussed
to implement SIP Mobility aka re-Invite in order to be able to do
BTS-MGW rtp and also handover? This would seem to me to be a good thing
to have?
k/
What should we do if the HLR sends no Insert Data?
When a subscriber does a Location Updating, the VLR sends a Location Updating
request to the HLR. The HLR typically responds with a Location Updating Result
as success and, in a *separate* message, sends an Insert Data to the VLR to
tell it the subscriber's MSISDN. So it is possible to do a successful Location
Updating without being told the MSISDN (as my test verifies).
What should the VLR do if it never receives the Insert Data from the HLR? In
that case the subscriber is attached but cannot be reached by MSISDN. Should
we actively wait for Inser Data and reject the subscriber if not successful?
It would be fairly easy to just send the MSISDN along in the Location Updating
Result. Why this separate message?
Thx,
~N
Hello,
We have already contacted our SIM cards provider (sysmocom), and they have
referred us towards this Mailing List.
We have purchased sysmoUSIM-SJS1 cards and we are having the following
problem when trying to program them:
We want to change the MCC and MNC values to the ones of our
OpenAirInterface LTE system, and Ki and OPC of the SIM card are changing
despite we are not intending for that to happen. The main issue with this
behavior is that as we have two sets of Ki and OPC values, when we are
going to register the user in the LTE database, we don't know for sure
which set of parameters we are supposed to introduce.
Here on I'll describe the configuration we are using and the commands
introduced when programming the SIM cards:
As programming software we are using PySIM.
The default parameters of the SIM we are programming are:
ADM: 20168462
ICCID: 8988211000000099120
Ki: 5B868E2B30C61190ABEFBA1CA6F6D56F
OPC: B3425076F23BA6054557FA359B4F9C0C
The parameters we are meaning to program are:
MCC: 001
MNC: 01
IMSI: 001010000009912
The command we are using to program in the SIM card is:
./pySim-prog.py -p 0 -a 20168462 -x 001 -y 01 -t sysmoUSIM-SJS1 -i
001010000009912 -s 8988211000000099120
And after programming the card, we are getting this:
[image: Imágenes integradas 1]
Do you what's the reason why this is happening?
Thank you very much for your time
Best regards,
Giselle Glez
I just ran my first tests of both OsmoNITB and OsmoSGSN connecting to OsmoHLR.
It turns out OsmoHLR uses the ipaccess_unit data a.k.a. CCM (whatever CCM
means) to route GSUP replies back to its sender.
It looks like "NAME-00-00-00-00-00-00".
However, all of our GSUP client code simply sets the unit id to:
"SGSN-00-00-00-00-00-00".
The result is that the VLR never receives an UPDATE LOCATION RESULT, because it
is sent to the SGSN instead, since that was the first one to say that it is
"SGSN-00...".
I would extend the GSUP clients to allow setting an ID from VTY, or maybe a
random ID. At this point it would suffice to make the MSC side say it is
"MSC-00-00-00-00-00-00" but that's beside the point.
Do we really want to do that? Any peer could come along and say it is someone
else, very easy to misconfigure (and not very security sensitive when thinking
of OAP -- which we're not using but maybe we will one day).
For some messages, OsmoHLR uses the conn pointer from msg rx to route the
response back -- that works. AFAICT it just receives messages and replies to
them right away (but haven't seen / understood all of it). For the case of the
UPDATE LOCATION RESULT, it would also be possible to use the same conn pointer,
but the code chooses to resolve by id and then sends to the wrong peer. If it
used the peer's IP address and port instead, things would work out.
With the attached and possibly very stupid patch, OsmoHLR works for me with
both MSC and SGSN talking to it even though they have identical IPA IDs: I
bluntly store the conn in struct lu_operation and re-use it later.
Which way shall we resolve this?
~N