> 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!
I've asked about it before but this seems to have been lost in
communication.
The question is basically how to enable multi-TRX support for
osmo-bts-trx using phy/instance infrastructure similar to other bts?
What I've tried so far is documented in
http://projects.osmocom.org/issues/1648 but it did not result in working
setup yet.
In short, I'd like to configure OpenBSC with 1 BTS with 2 TRX, each with
its own arfcn and set of channels. I'm running "osmo-bts-trx -t 2" and
correspondingly "osmo-trx -c 2" on usrp b210. Any ideas on what's
missing to make this actually work are greatly appreciated.
--
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 Max,
Thanks for your reply!
> I think extending utils/conv_gen.py is the way to go because it will
> allow us to have concise description of the convolutional codes in one
> place and as close to the description in standards as possible.
Ok, I will keep your opinion in my mind.
> Could you specify which files exactly are you referring to? Also you can
> use 'git blame' to clarify authorship.
No problem, they are:
- gsm0503_conv.c
- gsm0503_interleaving.c
- gsm0503_mapping.c
- gsm0503_parity.c
- gsm0503_tables.c
Almost all the gsm0503_*, excluding the 'gsm0503_coding.*'.
Thank you for this hint, this command is very usable! :)
> I don't think library functions should do any sort of logging by itself
> (unless it's a logging functions of course :)
> Instead they should return clearly distinguishable values and let caller
> do the logging as they see fit.
I am agree with you. It's time to use return codes.
Have a nice day!
With best regards,
Vadim Yanitskiy.
Today, I've taken a quick look at the coverity stuff, because so far I've only
seen coverity reports on the Iu code. I see now that actually all of the other
osmocom components are also tested by coverity.
So far I'm only seeing the "Osmocom" coverity project, which contains only the
iu build. In fact that's a bit of a misnomer -- I assumed that "Osmocom" would
contain all of the osmos, it should be more like 'Osmocom-3G' or 'Osmocom-Iu'.
The other osmos are in coverity projects named "libosmocore", "osmo-bts", etc:
https://scan.coverity.com/projects?utf8=%E2%9C%93&search=osmo
I see there are "add me to project" buttons e.g. here
https://scan.coverity.com/projects/libosmocore
so I'm trying that now.
Wouldn't it make sense to redirect all the coverity reports to a mailing list?
Probably best would be a new mailing list, to avoid noise on openbsc@, like the
gerrit-log@ list.
Are these coverity reports a matter of secrecy, to avoid publishing security
holes before we fixed them, in which case the coverity mailing list should be
invite-only?
~Neels
Hi,
While ruining osmo-bts and osmo-trx via VTY we tried to change parameter
like Band ,ARFCN MS max power.
We observed that once ARFCN is changed on VTY TRX does not switch to new
ARFCN.
Same behavior has been observed with Band and MS-Max-Power and RF-Locked
0/1 parameter.
Request someone who is running osmo-stack has controlled network ,please
reply or any document/pointer is appreciated.
BR
Dhananjay
Hi,
I am using osmo-nitb + osmo-sip-connector and I am sending INVITE to it, as
in the attached trace. The connector replies with 0.0.0.0 RTP IP and
0/unknown codec and then ends the call. I am seeing the following log:
"
Sep 23 09:08:00 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001>
mncc.c:334 call(1073741832) can not be found
Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0002> app.c:104
Unknown ptmsg(0). call broken
Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001>
mncc.c:312 leg(5001) rtp connect failed
Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0000> sip.c:245
Ending leg(0x91ec30) in con
Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001>
mncc.c:304 leg(1073741832) can not be found
Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0000> sip.c:186
leg(0x91ec30) got bye, releasing.
"
This issue happens *after* *recently* *updated* *packages* to:
"
ii osmocom-nitb 0.15.1.20160922 amd64
GSM Network-in-a-Box, implements BSC, MSC, SMSC, HLR, VLR
ii osmo-sip-connector 1.20160922 amd64
MNCC to SIP bridge for osmo-nitb
"
On the osmo-nitb side I am seeing logs [1].
I suspect a bug in the osmo-sip-connector code. Can someone confirm this?
[1] http://pastebin.com/giG0HHha
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.
When gerrit check the patch it only cares about "make check" result.
There's also a way to use AddressSanitizer for a given branch via
http://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/
I've just sent patch which fixes latest missing bit in libosmocore which
enables running AddressSanitizer with "make check" - see gerrit #863.
When this is merged we can enable AddressSanitizer for the "make check"
used by gerrit to verify patch submissions.
What do you think?
Note: we can't enable it yet for OpenBSC but all the libraries seems to
be fine.
--
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.
Coverity have noticed weird piece of code in libosmo-abis
osmo_rtp_socket_fdreg():
...
rs->rtp_bfd.when = rs->rtcp_bfd.when = BSC_FD_READ;
rs->rtp_bfd.when = rs->rtcp_bfd.when = 0;
...
It's on the border between 2 commits so it's likely merge artifact.
Which value is the right one? Or should it be rtcp_bfd?
--
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