Hi all,
Just wanted to share an issue and a quick workaround I found for it in case
anyone else has the same problem. I believe a cmd2 update is causing
pySim-shell to fail. After installing it on a fresh install of Ubuntu
Server 20.04 and getting the following error when I run "python3
pySim-shell -p0":
>Using PC/SC reader interface
>Autodetected card type: sysmoUSIM-SJS1
>AIDs on card:
> USIM: a0000000871002ffffffff8907090000
>Traceback (most recent call last):
> File "pySim-shell.py", line 512, in <module>
> app = PysimApp(card, rs, opts.script)
> File "pySim-shell.py", line 59, in __init__
> super().__init__(persistent_history_file='~/.pysim_shell_history',
allow_cli_args=False, use_ipython=True, auto_load_commands=False,
command_sets=basic_commands, >startup_script=script)
>TypeError: __init__() got an unexpected keyword argument 'use_ipython'
If you run into this you can fix it by uninstalling cmd2 and reinstalling
cmd2 with "pip3 install cmd2==1.5".
Best,
Bryan
> 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,
I had a problem placing MO GSM calls from a Siemens S11E: The calls
were dropped immediately; Osmo-MSC reports "Cannot compose Channel
Type from bearer capabilities"
After investigating the SETUP request from the S11E, the phone does
not use octet 3a (no extension bit set in IE 3). Wireshark decodes the
radio channel requirement as "Full rate support only MS/fullrate
speech version 1 supported", so I added a condition to the gsm48_ie.c
function of libosmocore to include at least GSM FR in the list of
available speech_ver in case octet 3 has no extension.
Attached to this message are the Abis-IP PCAP traces of MO calls, and
the patch for gsm48_ie.c.
Regards,
Lennart
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
Dear Osmocom Community,
I have noticed that the wiki page for OpenBSC GPRS at
https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS has
not been updated for four years, and since then, there have been
significant updates to the software. As a result, the information on the
GPRS/EDGE Setup page may be outdated, and I am struggling to configure GPRS
on my system.
I have attached my configuration files below for your review.
ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel
state DOWN group default qlen 1000
link/ether ec:8e:b5:41:cb:90 brd ff:ff:ff:ff:ff:ff
3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP group default qlen 1000
link/ether b8:8a:60:4f:59:02 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.109/24 brd 192.168.1.255 scope global dynamic
noprefixroute wlp1s0
valid_lft 7152sec preferred_lft 7152sec
inet6 fe80::649b:2ab5:6dd3:8779/64 scope link noprefixroute
valid_lft forever preferred_lft forever
Hello Osmocom,
I have written a new specification, in the style of 3GPP specs, for
enhanced RTP transport of FR and EFR codec frames in an IP-based GSM
RAN, addressing problem areas where the general standard RTP format
for these codecs creates functional regressions relative to the
original T1/E1 Abis architecture with TRAU frames. The new spec has
its official home here:
https://www.freecalypso.org/specs/tw-ts-001-v010001.txt
and here is a pair of patches adding OsmoBTS support for accepting
this TW-TS-001 format in RTP input and optionally (per vty config)
emitting it in RTP output:
https://cgit.osmocom.org/osmo-bts/log/?h=falconia/rtp_traulike
The code patches are just for better context - they will go to Gerrit
for review later - but right now I am soliciting a review of the
specification, rather than code implementation. I am not aware of any
established process in Osmocom for reviewing new specifications
(different from code review), as writing new 3GPP-style specs is not
something this community does often. But in the present case I am
genuinely convinced that the Internet standard RTP format for GSM-FR
and GSM-EFR (written with VoIP rather than GSM RAN in mind) is truly
deficient for GSM RAN purposes, especially for those who wish to
deploy their GSM networks in a retronetworking fashion, and the only
way to bring back the full set of E1 Abis bells and whistles over IP
is to invent our own (completely optional) pseudostandard format that
will likely only be used within {Osmocom+Themyscira} community.
With this context in mind, I cordially invite all of you, esteemed GSM
FOSS developers, to review the new specification linked above.
Sincerely,
Mother Mychaela
Hi Harald,
I tested and can confirm that the Nokia code cannot handle a situation
when the first TRX is not the first physical TRX in the cabinet. This
affects MetroSite and UltraSite and all other variants that can handle
more than one TRX. Given the fact these units are getting 20+ years
old, backplane or other HW issues can force a user to not start with
the first physical TRX and in that case the RSL bootstrap fails as the
BTS receives a config starting with trx1 while the unit may has trx2
or trx3 etc.
Question is how to handle this?
One option is that on Nokia, each TRX has its own RSL TEI, and that is
a 1:1 match as much as I know. Physical TRX1 has TEI1, TRX2 has TEI2
etc. So we can make a check during fu_config to first determine the
first physical TRX based on the RSL TEI, and then check at each
iteration which is the next one. For example you can have trx2 and
trx4 as well, so we cannot expect that the TRX-es are in a continuous
order nor that they always start with trx1.
Another option is to introduce a new Nokia specific TRX variable that
describes the physical location of the TRX inside the cabinet and do
the above mentioned checks with that.
Or there is a 3rd option I am not thinking about :-)
Any and all opinions are welcome.
Regards,
Csaba
Dear Harald,
Sorry for the delay, the UltraSite cabinet has some massive
backplane/interconnect issues, I tried to sort those out in the last
couple days (with not much success).
I had some time to further investigate the Nokia UltraSite situation,
and here are the outstanding issues I faced:
1. 2-3 seconds after BTS_RESET the OML LAPD link is reestablished
(coming from the BTS itself), and the signalling logic tries to
bootstrap OML (sometimes RSL as well) during the BTS performing the
reset. This tries do fail of course. Not sure if this causes any
practical error, although it does not look nice. Maybe adding some
logic state checks can help?
2. Sometimes on the OML LAPD link (and only on that one) I can see
these error messages:
DLLAPD lapd_core.c:1315 (0:1-T1-S62) S frame response with F=1 error
DLLAPD lapd_core.c:421 (0:1-T1-S62) sending MDL-ERROR-IND cause 6 from
state LAPD_STATE_MF_EST
Sometimes they arrive in batches, sometimes only a few. FYI the BTS
and the TRE both runs the latest SW ever released for UltraSite
(CX8.2).
3. Moving the RSL bootstrap to after "NOKIA_BTS_CONF_COMPL" received
seems to be working fine, this way we don't need to add another timer,
and Osmo-BSC can wait long enough to make sure all the TRXes loaded
the SW, configured and waiting for LAPD. In case more than one TRX is
used, the TRXes reach the "waiting LAPD" state in different order.
Did you had time to maybe try with InSite? I dont think my patch can
brake it, but I remember InSite was an odd ball within the Site
family.
I also started to re-introduce RF/BB hopping control for Nokia, if you
- or anyone -
can review it that would be lovely:
https://github.com/dchard/osmo-bsc/commit/41f6cd4723961700c5e5eceab4c92e7ce…
I was not able to try it out yet, as due to my backplane issues with
the cabinet, only TRX1 and TRX3 and TRX4 slots are working. And for
some reason if I try to use TRX3 and 4, the RSL bootstrap fails. I
wonder if the Nokia code has some limitation if the first TRX is not
actually the first? I tried to configure Osmo-BSC to start with "trx
2" but it does not want to start anything other than "trx 0". Of
course the question is what OsmoBSC sends during OML bootstrap. As
much as I can see, the Nokia code does not take into account if the
first TRX is not the first physically in the unit, but I am not a 100%
sure yet. Some help or hint here would be very welcome.
This is where I am now. The HW issues with the unit makes it pretty
time consuming to focus on the SW side, for now.
If you or anyone has any ideas or comments, please let me know.
Regards,
Csaba
Hi! I just purchased a used Ericsson RBS 6000 chassis with a DUS 31 module in it. From what I have read, this module should be compatible with Open5GS for the LTE side, but I wanted to inquire about the status of support for it on the GSM side under OsmoBSC. As far as I know, it should work the same as the DUG series which is supported, with the only difference being it's use of Ericsson packetAbis/IP rather than hardware T1 lines for the voice backhaul connectivity. Will these units work with osmocom for GSM, or will I have to purchase a DUG unit for my enclosure? Is there anything else I should be aware of?
Thank you,
Enzo D'Amato
