> 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
Dear all,
I've been asked by a number of pepole about a possible Osmocom village at the
CCC Camp 2019. I personally didn't really have any plans, but given related
e-mails and "encouragement" I went ahead and registered an "Osmocom Village",
see
https://signup.c3assemblies.de/assembly/3b8f7aa2-95d5-4c44-aadc-de8f2680e9c3
I also created a wiki page (as nobody else did, despite earlier discussion on IRC,
SCNR) for coordinating related efforts at
https://osmocom.org/projects/osmo-dev-con/wiki/CCC_Camp_2019
One of the bigger questions is about having a tent as well as some tables/benches
to sit on and work. The Camp orga team nas been negotiating rates with a tent
rental company, but to be honest I'm rather surprised by the extremely steep
pricing. The smallest possible tent (6m x 3m) would cost 825 EUR. I'm not
sure we want to raise that amount of money? Even if we'd be 10 people sharing
it, its still 82.50 EUR per person. And that excludes any tables/chairs.
I'm attaching the relevant parts of a mail from the assemblies orga team FYI.
Please note there also is some kind of fragmentation / overlap with the
team planning to run the GSM/3G networks at the camp, see Lynxis'
related post at
https://lists.osmocom.org/mailman/private/osmocom-event-orga/2019-June/0003…
It's questionable whether it makes sense to have tow distinct
'villages', but given that e.g. I don't know anyone of that singularity
city, I'm not sure if we'd either be welcome there, nor whether we'd
want to associate us with them? Also, while the GSM network operation
for sure has good reasons to mingle with the POC and whatever facilities
they have, I'm not sure if the wider Osmocom community attendees
unrelated to the GSM network operation wouldn't just be a
disturbance/nuisance.
In the end, to be honest, I personally do not feel I have the time and
mental capacity to take on any additional tasks in terms of organizing
anything. I just created the entry in c3assemblies as I was asked to,
and I similarly created the related mailing list and wiki page.
So please, anyone interested in making an Osmocom village happen one way
or another, step up [and continue this discussion on the
camp2019-village(a)lists.osmocom.org mailing list, without crossposting
everywhere else :)
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)
Hello All,
I am working on get OpenBSC connected to a 3rd party MSC, I read from the
Osmo document that I can use the bsc only mode and the osm-bsc instead of
the osmo-nitb.
Currently I had osmo-trx-uhd, osmo-bts-trx, osmo-bsc, and osmo-stp
configured and and running, but I see a lot of below error logs in the
osmo-stp console:
```````````````````````````
DLSS7 <000c> osmo_ss7.c:1468 asp-asp-dyn-0: xua_srv_conn_cb():
sctp_recvmsg() returned 56 (flags=0x80)
DLM3UA <000f> m3ua.c:722 asp-asp-dyn-0: Received M3UA Message (XFER:DATA)
DLM3UA <000f> m3ua.c:541 asp-asp-dyn-0: m3ua_rx_xfer
DLM3UA <000f> m3ua.c:580 asp-asp-dyn-0: m3ua_rx_xfer(): M3UA data header:
opc=337=0.42.1 dpc=185=0.23.1
DLSS7 <000c> osmo_ss7_hmrt.c:278 m3ua_hmdc_rx_from_l2(): dpc=185=0.23.1 not
local, message is for routing
DLSS7 <000c> osmo_ss7_hmrt.c:258 MTP-TRANSFER.req for DPC 185: no route!
````````````````````````````
On the BSC console, I am seeing a lot of:
```````````````````````````````
<0007> a_reset.c:106 A-RESET(msc-0)[0xb76ce0]{DISC}: (re)sending BSSMAP
RESET message...
<0007> osmo_bsc_sigtran.c:93 Sending RESET to MSC:
RI=SSN_PC,PC=0.23.1,SSN=BSSAP
```````````````````````````````
Can anyone identify what is the issue here?
Appreciates!
Regards,
Weiqi
Dear ML,
I'm wondering why we do not have gsmtap logging enabled for TTCN3
testsuites, and if there are any reasons against doing that.
Personally I find it very useful to have gsmtap logs in pcap files,
because then then there is no need to manually match the timestamps of
the log file and interesting parts of the pcap dump.
Especially in the TTCN3 testsuites, where we generate a separate pcap
file for each test, but have one big log file of the SUT (e.g. osmo-hlr)
for the entire testsuite run.
Thoughts?
Thanks,
Oliver
--
- Oliver Smith <osmith(a)sysmocom.de> https://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.
I just followed the step by step procedure outlined in the wiki to compile
OpenBSC on Ubuntu 16.04 LTS for the ip.access nanoBTS. My problem is that
the folder ipaccess which has the ipaccess.config is missing and so is the
abisip-find file.
Any leads on why this is happening? I had seen somewhere that the above can
be found in the osmocom-ipaccess-utils from the repo but that too is
unavailable.
Many thanks
-tyrus
Hello ML,
cloning from git.osmocom.org is sporadically failing. From one CI job
that ran today:
> Cloning into 'osmo-bsc'...
> error: garbage at end of loose object 'b5511145af6213e2d23a3e9890fd42b8aaa0dc1b'
> fatal: loose object b5511145af6213e2d23a3e9890fd42b8aaa0dc1b (stored in <https://jenkins.osmocom.org/jenkins/job/Osmocom_OBS_latest/ws/osmo-bsc/.git…)> is corrupt
> Build step 'Execute shell' marked build as failure
https://jenkins.osmocom.org/jenkins/job/Osmocom_OBS_latest/628/display/redi…
Another job failed today with:
> + git -C osmo-bts fetch
> fatal: unable to access 'https://git.osmocom.org/osmo-bts/': The requested URL returned error: 504
I've restarted the CI jobs.
Regards,
Oliver
--
- Oliver Smith <osmith(a)sysmocom.de> https://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
Hi Harald!
Unfortunately, your change [1] breaks some osmo-* projects.
I am getting the following segfault with OsmoMSC:
[1] https://git.osmocom.org/libosmocore/commit/?id=b3f94eb39e19366c3458643ee329…
[1] https://gerrit.osmocom.org/#/c/libosmocore/+/14361/
ERROR: osmo_log_info == NULL! You must call log_init() before using
logging in log_check_level()!
Assert failed osmo_log_info logging.c:184
backtrace() returned 10 addresses
/usr/local/lib/libosmocore.so.12(+0x16f6b) [0x7ffff72dff6b]
/usr/local/lib/libosmocore.so.12(osmo_panic+0xc0) [0x7ffff72dff20]
/usr/local/lib/libosmocore.so.12(+0x14487) [0x7ffff72dd487]
/usr/local/lib/libosmocore.so.12(log_check_level+0x1a) [0x7ffff72de82a]
/usr/local/lib/libosmocore.so.12(osmo_fsm_register+0xef) [0x7ffff72d81bf]
/home/wmn/osmocom/osmo-msc/tests/msc_vlr/msc_vlr_test_ss() [0x692e03]
/home/wmn/osmocom/osmo-msc/tests/msc_vlr/msc_vlr_test_ss() [0x9b6aad]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7ffff595fed5]
/home/wmn/osmocom/osmo-msc/tests/msc_vlr/msc_vlr_test_ss() [0x4215cc]
gdb-peda$ bt
#0 0x00007ffff5974c37 in __GI_raise (sig=sig@entry=0x6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff5978028 in __GI_abort () at abort.c:89
#2 0x00007ffff72dff25 in osmo_panic_default (args=0x7fffffffda48,
fmt=0x7ffff72e8cb9 "Assert failed %s %s:%d\n") at panic.c:49
#3 osmo_panic (fmt=fmt@entry=0x7ffff72e8cb9 "Assert failed %s
%s:%d\n") at panic.c:84
#4 0x00007ffff72dd487 in assert_loginfo (src=<optimized out>) at logging.c:184
#5 0x00007ffff72de82a in log_check_level
(subsys=subsys@entry=0xffffffff, level=level@entry=0x7) at
logging.c:1033
#6 0x00007ffff72d81bf in osmo_fsm_register (fsm=0xcc6c20 <msc_a_fsm>)
at fsm.c:261
#7 0x0000000000692e03 in msc_a_fsm_init () at msc_a.c:1003
#8 0x00000000009b6aad in __libc_csu_init ()
#9 0x00007ffff595fed5 in __libc_start_main (main=0x517540 <main>,
argc=0x1, argv=0x7fffffffdcb8, init=0x9b6a60 <__libc_csu_init>,
fini=<optimized out>, rtld_fini=<optimized out>,
stack_end=0x7fffffffdca8) at libc-start.c:246
#10 0x00000000004215cc in _start ()
As can be seen, this happens when we register 'msc_a' FSM,
which of course has .allstate_event_mask == 0x00, and dummy
.allstate_action == msc_a_fsm_allstate_action(), which
basically does nothing.
The registration happens even before the main() is called,
since we use '__attribute__((constructor))', and logging
is not yet initialized at that time.
We need to fix the FSM definition, but right now I think
we have no other way than reverting [1].
With best regards,
Vadim Yanitskiy.
Hi Pau,
today I cannot sign in to Gerrit for some magic reason,
so I would like to post some notes about your change [1].
[1] https://gerrit.osmocom.org/#/c/osmo-sgsn/+/14445/
> [...] it changed the default logic for remote policy to not require
> authentication, which broke TTCN3 tests because sgsn no longer
> tries to authenticate the users.
My bad, sorry for that.
> let's enable it by default when on auth-policy remote.
ACK.
> doc/manuals/vty/sgsn_vty_reference.xml
> Allow MS to attach via GERAN without authentication
> (default and only possible value for non-remote auth-policy)
Actually, no. My motivation for introducing this VTY parameter
was exactly the ability to use remote auth-policy (i.e. OsmoHLR)
to check if a subscriber is known, but not to require
authentication, just like we can do in CS-domain. In other words,
'authentication optional' should work with 'auth-policy remote'.
> src/gprs/sgsn_vty.c
> DEFUN(cfg_authentication, cfg_authentication_cmd,
> [...]
> Allow MS to attach via GERAN without authentication
> (default and only possible value for non-remote auth-policy)
Same here. It *is* possible for 'auth-policy remote' too.
> src/gprs/gprs_sgsn.c
> struct sgsn_instance *sgsn_instance_alloc(void *talloc_ctx)
> [...]
> inst->cfg.auth_policy = SGSN_AUTH_POLICY_CLOSED;
> /* only applies if auth_policy is REMOTE */
> inst->cfg.require_authentication = true;
> [...]
Are you sure this wouldn't break non-remote auth-policy use cases?
AFAIR, the GMM layer requests authentication regardless of the
'auth-policy', so then in 'gprs/sgsn_auth.c' we conditionally
perform authentication or immediately return SGSN_AUTH_ACCEPTED.
An alternative solution is to invert 'cfg.require_authentication',
e.g. to 'cfg.omit_authentication', so by default we will require
authentication since it's initialized to false.
With best regards,
Vadim Yanitskiy.
