> On 13 Jul 2016, at 12:21, Max <msuraev(a)sysmocom.de> wrote:
>
Hi all,
> After looking at the code, I don't think reusing table implementation
> would be easy - the approaches are too different as well as underlying
> data structures.
okay. then we will need to use the tree based version and from my point of view we should do it the following way:
* Remove osmo_t4_decode (and related routines) from libosmocore (last step)
* Make the tree based decoder ready in terms of the surrounding style
* Adopt/Clone the osmo_t4_decode tests and move them to the PCU (as part of the commit that adds the decoder to the PCU)
@Me: After the infrastructure is in the PCU I will remove osmo_t4_decode (and tests) from libosmocore
@Radisys:
I am afraid the tree based decoding is not ready yet and as it impacts the upcoming encoder (and other RLE code as far as I understand) let me put it here.
In osmo-pcu (and all other projects) we use libtalloc for memory allocations. This means the tree should use talloc with proper parent/child allocations. This way the destructor of the decoder will also free all nodes of the tree. There should be no call to malloc/free in the PCU.
Please take the tests from libosmocore and make sure they work with the new decoder. Tests are the lifeline and we need more and not less of them.
The decoder needs to be robust against invalid input. search_runlen can fail but the caller doesn't check for that. Please test with invalid/truncated or broken inputs to see we don't end in a never terminating while loop. Test using unit tests.
Similar the current osmo_t4_decode can return an error that is propagated back to the compressed bitmap decoding and we should have the same.
Reduce code duplication. With the decoder the only difference between the if/else is if the data is filled with 0x00 or 0xFF and which table/root to use. Instead of having code clones please parameterize either by having local variables in the beginning or by calling different (inline) functions.
kind regards
holger
Hi guys,
I think some of us would like to move to redmine and start using public tickets more frequently. So in case we move there are some topics to be discussed and I would like to start with a couple of them right now.
Tickets:
Redmine has a global linear sequence of ticket numbers. If we move from many tracs to a single redmine we can either:
* not import tickets
* only import from one project
* deal with changing ticket numbers
In terms of installations the GMR trac is broken in regard to tickets, there are some for SDR that are probably not being fixed anytime soon, baseband might be relevant and OpenBSC is unlikely to be relevant. I don't think we have ever used ticket reference in OpenBSC commit messages so in terms of OpenBSC having changing ticket numbers would not be a big deal. E.g. we could add a custom field with the old trac number?
Wiki:
We have external references that should be redirected to the new place. Is there any way besides maintaining a list in the apache2/nginx configuration and making redirects as we find broken references? Can we proactively manage this? Is anybody willing to come up with a script and nginx configuration for doing this?
kind regards
holger
Hi All,
A few weeks ago, I wrote to the list about a handset that was opening
and holding an lchan after doing IMSI attach.
After some investigation I see this phone is querying the network for
call forwarding status. This phone then cannot send any more USSD codes,
or make calls, although it can receive, but for some reason insists on
doing the query again after call termination.
Doing the same from other handsets, by dialling such codes as *#21# in
each case gives the same result of eternal lchan usage, although some
(more modern) phones seem to eventually timeout, releasing the channel
while others do not.
I connected numerous phones and did the same on each one and pretty soon
I have a kind of DOS situation on the network in that SDCCH is at capacity.
The last log message resulting from the request is
/openbsc/openbsc/src/libmsc/gsm_04_08.c:3586 Dispatching 04.08 message,
pdisc=11
although strangely with one phone, this is followed shortly by:
libosmocore/src/gsm/gsm0480.c:219 USSD Request is too short.
openbsc/openbsc/src/libmsc/ussd.c:55 Unhandled SS
so for that one phone, it would seem handle_rcv_ussd() is being called
from gsm0408_dispatch()
I have been going through the code, basically adding more debug output
to try to verify what is being called from where, and I also found the
functionality in libosmocore such as gsm0480_decode_ss_request(),
although this is not called at anytime from the nitb.
This is an enormous project!
I notice these lines in openbsc/openbsc/src/linmsc/gsm_04_08.c in
gsm48_rx_mm_serv_req()
/* we will send a MM message soon */
conn->expire_timer_stopped = 1;
It would seem that we don't ever send this MM message.
It's not clear to me where I might try to check again on the status of
this MM request, or if the problem is a lack of full implementation of
these supplementary service requests.
Would anybody be interested in working on this with me?
Keith.
From: Neels Hofmeyr <neels(a)hofmeyr.de>
The INSTALL file is being overwritten by autoreconf, but it is committed
as empty file. As a result, the INSTALL file always shows as modified.
Instead, remove INSTALL from git and ignore it.
---
.gitignore | 1 +
INSTALL | 0
2 files changed, 1 insertion(+)
delete mode 100644 INSTALL
diff --git a/.gitignore b/.gitignore
index e15c19b..d1a0b33 100644
--- a/.gitignore
+++ b/.gitignore
@@ -39,6 +39,7 @@ libtool
ltmain.sh
missing
stamp-h1
+INSTALL
# vim
*.sw?
diff --git a/INSTALL b/INSTALL
deleted file mode 100644
index e69de29..0000000
--
2.1.4
Hi.
I'm working on http://projects.osmocom.org/issues/1616 and wonder about
$subj.
In case of sysmobts, osmo-pcu obtain this data directly from DSP:
* RSSI (dBm)
* burst timing (in quarter of bits)
* link quality (in dB)
* BER
The first and last value seems to be easy from what I see in
src/osmo-bts-trx/scheduler_trx.c What about burst timing (necessary to
compute TA in the absence of PTCCH) and link quality (measure of C / I
where C is carrier and I is interference power) - how can I compute
those or some estimator to those values?
--
Max Suraev <msuraev(a)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
Hi,
Is there any intention / interest among current community developers to
implement the DTMF for osmo sip connector?!
Thanks,
Stefan
On Jul 27, 2016 3:33 PM, "Holger Freyther" <holger(a)freyther.de> wrote:
> On 27 Jul 2016, at 20:19, Brian Butterly <bbutterly(a)ernw.de> wrote:
>
> Hi,
Hi!
> has anyone recently put together a functional setup with OsmoNITB and
> Asterisk (+LCR)?
why asterisk? why LCR? The osmo-sip-connector is a "trivial" piece of
software that bridges MNCC to SIP (and back) and let's everyone else do the
heavy lifting. In contrast to LCR it currently lacks:
* Multi-party calls (a bit harder)
* DTMF (quite easy but not done)
holger
Hi,
has anyone recently put together a functional setup with OsmoNITB and
Asterisk (+LCR)?
I've got multiple errors while compiling LCR with Asterisk, mainly
unknown definitions and a set of missing functions.
My setup:
-NanoBTS
-current OpenBSC (running perfectly)
-Ubuntu Xenial, 64Bit, VBox VM
-current LCR from Osmocom Repos
-Asterisk (build without any issues)
--1.8.32.3 from Asterisk Page
--1.6.2.24 from Asterisk Page
--11.32.0 form Asterisk Page
--last 13.x release vie apt
I had expected the newer versions to be incompatible, still gave them a
shot anyways.
I've started fiddling with LCR, but before I go deeper into that, I just
wanted to check if there was some defined approach which would get
everything up and running.
I'd be very thankful for any hint or maybe some information on which
versions of what will actually work together.
Thanks!
Brian
Hi all,
I have some patches that probably fix some corner cases of dynamic pchan
switching. However, since I'm technically already in vacation, I will only be
able to properly test them in about 10 days' time.
If they should become interesting before that, the changes are pushed to
branches called neels/dyn_fixes in openbsc and osmo-bts.
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)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
* Geschäftsführer / Managing Directors: Harald Welte
I just came across this compiler warning:
l1sap.c: In function 'gsmtap_ph_rach':
l1sap.c:291:8: warning: assignment from incompatible pointer type [enabled by default]
*data = &l1sap->u.rach_ind.ra;
^
It's a
uint16_t ra
and used like this in common/l1sap.c:
static int gsmtap_ph_rach(struct osmo_phsap_prim *l1sap, uint8_t *chan_type,
uint8_t *tn, uint8_t *ss, uint32_t *fn, uint8_t **data, int *len)
{
[...]
*data = &l1sap->u.rach_ind.ra;
*len = 1;
A cast like this would fix the compiler warning and make sense if data is
interpreted to point at a 16 bit data block, probably in host byte order
though:
*data = (uint8_t*)&l1sap->u.rach_ind.ra;
*len = 1;
But *len = 1 means that **data is an 8bit value?
This is sent to gsmtap.
Is *len = 1 something we should fix?
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)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
* Geschäftsführer / Managing Directors: Harald Welte
Hi folks, I'm seeing some unexpected behavior from OsmoNITB. I am running from the Debian 8 nightly builds from July 25 for everything.
My OpenBSC configuration is set as follows:
network
[...]
auth policy accept-all
[...]
nitb
subscriber-create-on-demand
assign-tmsi
[...]
When a new phone tries to camp to the network, it's rejected as follows: https://gist.github.com/shaddi/7674680c329f14c0042fbeca5227962e ("Failed to find subscriber"). My full openbsc.cfg is in that gist as well.
If I create the subscriber by IMSI via the VTY though, it camps fine and everything else works as expected. When I tested this this configuration a few weeks ago with an earlier build (sorry, can't recall which one), adding the subscriber manually wasn't necessary, and with the configuration above seems like it also shouldn't be necessary. Couple questions:
- Is this the expected behavior for this configuration?
- If so, is there currently a way to achieve the prior behavior (subscriber created automatically when a new phone tries to camp, rather than being rejected)?
Thanks,
Shaddi