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,
My name is Brackley Cassinga Form DRC, we run a community network called
pamoja net where we offer gsm services using osmocom open source software
and OC Base station.
Recently I have tried to install another base station as the same installed
but I could not find any resource guiding through all the steps to take to
run NIB on a base station.
I'm currently running Ubuntu and I will appreciate if you could guide me on
the installation of BSC,hlr,MSC , in order to run a basic gsm network.
Thank you. Regards
--
*Ir Brackley heshima Casinga **Pacifique*
*CEO and Founder of kwanzatechnologie*
KwanzaTechnologies ,GlobalElectronics
+243977265291 | +243977265291 | Pcassinga(a)gmail.com/
brackley(a)ensemblepourladifference.org
www.kwantechnologies.jimdosite.com <http://www.kwantechnologies.com/> |
Skype: Brackley cassinga <https://webapp.wisestamp.com/#>
Av Semliki N 43
Hi Philipp,
while reading your comments to:
https://gerrit.osmocom.org/c/osmo-bsc/+/19670https://gerrit.osmocom.org/c/osmo-mgw/+/20250
I realized that it would be better to discuss here.
My initial idea was that the absence of attributes (in the command
definition and thus in the VTY reference) implicitly indicates that a
given VTY command in the 'config' node comes into effect immediately.
This way we would only need to add attributes to commands requiring
program restart or reestablishment of some link(s) / connection(s).
However, in some applications *most* of the commands may require full
program restart. Or the opposite: most commands may apply immediately.
Adding same attributes to every command is annoying, so I came up with a
concept of default 'applies when' policy: what if we add a new field to
'struct cmd_node' indicating default attributes of all commands
belonging to it?
struct cmd_node foo_node = {
.node = FOO_NODE,
.prompt = "%s(config-net)# ",
.vtysh = 1,
.usrattr = (1 << FOO_VTY_ATTR_RESTART_FULL), // (!)
};
This way a DEFUN() command definition would inherit foo_node.usrattr,
and a DEFUN_USRATTR() command definition would override it.
dexter wrote:
> I just wonder if there could be a VTY_ATTR_RESTART_FULL predefined in
> libosmore. Almost any of the osmo program will need it. Maybe also an
> VTY_ATTR_RESTART_IMMEDIATE?
ACK. I think they could be even moved to generic attributes:
/*! Attributes (flags) for \ref cmd_element */
enum {
CMD_ATTR_DEPRECATED = (1 << 0),
CMD_ATTR_HIDDEN = (1 << 1),
CMD_ATTR_APPLY_IMMEDIATE = (1 << 2),
CMD_ATTR_APPLY_FULL_RESTART = (1 << 3),
};
dexter wrote:
> Maybe we could have some standard letters defined in libosmocore
> for standard situations:
> F = Full restart required
> I = Applied Immediately
ACK. We can also agree that generic (pre-defined) attributes use upper
case letters, while the application specific ones use lower case?
What do you think about these ideas? If you agree, and nobody has any
objections, I can quickly implement them in libosmocore. Would be also
nice to know what other developers think. Neels, Harald, Pau, Daniel?
Best regards,
Vadim.
--
- Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Possibly interesting to note this OAI announcement.
Unfortunately none of the links are direct, but all of them are ugly tracking
links. Also ads for facetwoogle. So I had to blank out a lot. Also interesting
to note how they don't self-host, but rather spread their code across *both*
hosted-gitlab and github. Also interesting how the From: address is a gmail one
vs. the contact(a)openairinterface.org further below. In a massive herd effort,
folks are fudging up the internet, no news there at least.
~N
----- Forwarded message from OpenAirInterface Software Alliance <osalliance5g(a)gmail.com> -----
Date: Fri, 25 Sep 2020 05:40:17 +0000
From: OpenAirInterface Software Alliance <osalliance5g(a)gmail.com>
To: nhofmeyr(a)sysmocom.de
Subject: OpenAirInterface releases 5G core network code
X-Mailer: MailChimp Mailer - **CIDbb030ed5232925faf6b6**
** OpenAirInterface releases 5G core network code
------------------------------------------------------------
Dear Community,
The OpenAirInterface Software Alliance is pleased to announce the release of the OAI 5G Core Network code. An initial set of features is already available and developments with a solid team are underway to build the rest of the 3GPP 5G SBA core. The project home page is here (<blanked-tracking-link>) and gives a good overview of the development phases and the roadmap.
The AMF (<blanked-tracking-link>) and the SMF (<blanked-tracking-link>) code is available on GITLAB. While working to release the UPF code, we are working with the SPGW-U (<blanked-tracking-link>) on the GITHUB.
A CI bench is already operational and in place. Any new features or developments introduced by community developers will automatically launch the CI pipeline and changes will only merge after having thoroughly been tested against third party testers and the OAI 5G RAN test benches.
We cordially invite the community to contribute to the developments of the OAI 5G core network and reach out to contact(a)openairinterface.org for any questions and contribution proposals.
The OpenAirInterface Software Alliance Team*
[removing a ton of tracking links]
----- End forwarded message -----
Hi all,
we seem to have problems with structure alignment in the new version of
the PCUIF protocol:
PCUIFv9: sizeof(struct gsm_pcu_if) -> 212; 212 % 4 == 0
PCUIFv10: sizeof(struct gsm_pcu_if) -> 1006; 1006 % 4 != 0
I think we would need to add/remove some padding. The question is
whether we should make sure that all structures are aligned, or having
the top level struct gsm_pcu_if aligned would be enough?
Even in PCUIFv9 not all structures are properly aligned:
sizeof(struct gsm_pcu_if_data_cnf_dt) -> 21; 21 % 4 -> 1,
sizeof(struct gsm_pcu_if_rts_req) -> 13; 13 % 4 -> 1,
sizeof(struct gsm_pcu_if_rach_ind) -> 15; 15 % 4 -> 3,
sizeof(struct gsm_pcu_if_pag_req) -> 11; 11 % 4 -> 3,
sizeof(struct gsm_pcu_if_susp_req) -> 11; 11 % 4 -> 3.
I devise by 4 because the widest member is uint32_t in all cases.
Kind regards,
Vadim.
--
- Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Hello!
Can anybody share a working /etc/dahdi/system.conf file? I'm trying to
bring up RBS 2000 with osmo-bsc and I'm not sure that I have correct
configuration.
1. Which signaling should be used? CAS? CCS? RBS?
2. There is the same thing with framing. hdb3?
3. parameter "dslot=1,4" pointed in RBS2000 wiki looks wrong. dahdi_cnf
does not work with it at least now.
Thank you
Ivan
Hi Xaver,
[posting this on the mailing list, as it may be of interest to others]
On Fri, Sep 11, 2020 at 04:55:35PM +0200, Xaver Zu wrote:
> This is a dynamic linking.
this is true, but the nature of the linking does not matter in terms of
what creates the derivative work.
> Is this a problem even if I do not distribute the resulting binary?
The AGPL (contrary to the GPL) conditions start when users remotely interact
with your software (See Section 13 of AGPLv3). This means even operating
a network with remote users already means you need to provide the complete
and corresponding source code to the entire work under AGPLv3, which is
impossible if you have a proprietary dependency.
So if you build the software, and you make sure that nobody but yourself
every uses the resulting GSM network, you are fine. But as soon as any
third party uses it, you would be putting yourself in the impossible position
to providing the source code to a proprietary library.
> I can simply add a warning to the file that the compiled program cannot be distributed.
One might consider this a "further restriction" which by itself is a
violation of AGPLv3:
All other non-permissive additional terms are considered "further
restrictions" within the meaning of section 10. [...] You may not impose
any further restrictions on the exercise of the rights granted or
affirmed under this License.
But even beyond that: How many users do you think willread that warning
in the source code vs. how many will simply run it (and possibly allow
others to register). Even if you added a message to start-up, and to
the user manual, I still would think many people don't look at that.
I don't think we should distribute something that "tricks" people into
committing license violations or putting them in an impossible position,
legally speaking.
> Is it a violation that someone assembles and uses it on their own machine?
It is not a violation as long as they are they only person using the
resulting GSM network (or using its VTY or its TRXC/TRXD interface).
I would compare distributing source code like that to shipping a product
that is almost impossible to use safely, but very easy to use in a
[legally] unsafe way.
> Is it a violation to even have sources and build instructions for it?
Maybe not, but see above, I don't want to make it too easy for people to
shoot themselves into their foot.
> Can we agree to leave it as a starting point until someone will have the
> time to do it using IPC?
I'm very sorry (really), but we will not merge this code to the
mainline osmo-trx code base on osmocom.org.
Kind 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)