Summary:
[1] some problems found in the current logging filter implementation.
[2]..[7] a long discussion on where we could take Osmocom logging.
[2] logging "lifter" instead of a filter
[3] setting logging levels for flagged objects
[4] multiple log targets and multiple flagged objects
[5] FSM instance logging
[6] setting the log context
[7] VTY logging commands
[1]
In the VLR development, I'm going to split the gsm_subscriber to a
bsc_subscriber and a vlr_subscriber. Hence I need to care about the logging
filter code, that e.g. drops all logging except that for a given subscriber.
At first I wanted to drop it altogether, but in fact filtering on a given
subscriber is an important feature. See https://gerrit.osmocom.org/1685
Looking further into adapting this to two types of subscriber struct being used
in the code, I found that in fact the logging filter code looks quite neglected
and degraded.
- One functional problem is that the constants for BSC_CTX_SUBSCR and
GPRS_CTX_BVC actually have the same value: they both resolve to 1, and both
thus access the same logging context pointer with conflicting types.
openbsc debug.c's filter_fn appears to use both BSC_CTX_SUBSCR and
GPRS_CTX_BVC, but GPRS_* are only set in libosmocore/src/gb/ code. Could be
justified by osmo-nitb and osmo-sgsn not overlapping much, but I doubt that
it's on purpose.
- A log target's filter_data[] possibly holds a subscr_get() reference. If a
log target is closed, like a VTY closing, the reference count may leak,
because there is no filter data tear down that could subscr_put() it back.
- log_set_nsvc_filter() and log_set_bvc_filter() are declared in
openbsc/debug.h, but the only implementations I can find are *static* in
libosmocore/src/gb/gprs_bssgp_vty.c and gprs_ns_vty.c, respectively.
- The openbsc/debug.h enum defining LOG_FILTER_* is never used, because it is
bascially duplicated in debug.c, where the values are called FLT_* instead.
- The BSC_CTX_BTS and BSC_CTX_LCHAN are each set once by a call to
log_set_context(), but no filter function ever reads them back out from the
context array. So they are utterly unused.
Hence in libbsc/libmsc, the *only* logging filter practically used is the IMSI
filter.
The filter code screams for attention and more safety. I would collect the
various constants in a central place in libosmocore to avoid collisions (like
ports.h does), and would use the same constant for both...
the filter ctx array index: ctx[FLT_CONSTANT]
and the bitmask: filter_map & (1 << FLT_CONSTANT)
with a static assert to ensure that the filter category constants don't outgrow
the filter_data[], ctx[], filter_map sizes. I'd drop unused definitions, add a
tear down cb.
[2]
While talking about logging, I'm thinking back to 33c3 where we had a large
active network and might want to highlight a few subscribers in the logging...
Any comments on below bold plans to overhaul the logging semantics are welcome.
Despite the long discussion, implementation of this should not be a lot of work
really.
Nevertheless, there are pressing topics in need of attention, and this mail
doesn't mean that it will be implemented now. It's a unicorn's dream of where I
would take Osmocom logging, and it _might_ be a good time to do it now...
If you will, join me on an extensive journey through our logging:
So far the logging checking goes like this:
1. If a msg's logging category is disabled, drop the msg.
2. If a msg's logging level surpasses the currently set log level of that
category, drop it. otherwise:
3. If filter_all is set (= "don't filter"), log the message; otherwise:
4. If no filter function is set, log the message (in libbsc/libmsc operation, a
filter function is always set).
If a filter function is set:
5. Ask the filter function whether to log:
5.1 If no IMSI filter is set, drop the message. (!)
5.2 If an IMSI filter is set and the ctx has a different subscriber, drop
the message.
5.3 If an IMSI filter is set and it *is* the subscriber, log the message.
The result is that in essence, we don't ever see any logging unless we say
'logging filter all 1'. And then, if filter_all is set, the IMSI filter has no
further effect. To see logging for a specific IMSI, we set 'logging filter all
0' and set the IMSI filter to the subscriber. In that situation, all logging
will cease except for those matching the selected IMSI (assuming that the
filter context is always set correctly). Any logging for this IMSI that would
be more detailed than the given category's global logging level is still
dropped, and parts of the code where the subscriber ctx is not set yet also
shows no logging. One could call it a prohibitive logging paradigm. I had a
hard time understanding the UI for it: makes sense only when reading the code.
My logging vision would be the other way around, more of a logging "lifter". In
a general logging landscape, I would like to flag certain subscribers (plural)
to stand out from this landscape with a more detailed logging level. For
example, I set all categories to level ERROR, but on top allow all MM, RSL and
RR logging on INFO level; but for subscribers 1234 and 5678 I also want to see
all DEBUG level logs across all (or specifically selected) categories.
It would look like this:
1. If there is a logging_lifter function:
1.1 If any items are flagged for more detailed logging, ask the lifter:
1.2 If the logging context is set to a subscriber, and this subscriber is
flagged for more detailed logging, log the message; see also [3].
2. If a msg's logging level is within the currently set general log level of
that category, log the message.
3. Otherwise, drop the message.
This way the general logging landscape remains freely configurable while
certain objects' logging can be made more verbose.
[3]
A problem with 1.2 is that we would always see all categories' logging in all
detail for that subscriber. We could a) set a full category mask per subscriber
for complete logging freedom; Instead I'd go for: b) define one global "raised
logging" category mask to lift flagged subscribers to, and for each subscriber
simply have a boolean flag set to true to make them log on the raised logging
levels -- but what about several logging targets? see [4].
[4]
So far so good, but there is still this clumsiness in my plan: there can be any
number of logging targets. Even if I'd like to highlight subscriber 1234 on my
VTY, I don't necessarily want stderr and other VTYs to raise logging for 1234
as well. So if we flagged raised logging in a subscriber struct, we'd basically
make it affect all logging targets in the same way.
In the current code, I can open N VTY telnets and on each of them show only
logging for a selected IMSI, because all logging flags are saved for each
logging target. But I *can't* lift more than one subscriber instance to raised
logging on *the same* log output, because for each target there is only one
IMSI; and I *can't* combine detailed logging of a given IMSI with a general
background of normal logging on the same log output, because I have to filter
all logging away before I can allow a specific IMSI ('logging filter all 0').
The easiest way to allow multiple subscribers with raised logging on the same
log target is to store the "raise-logging" flag with the subscriber instance,
but to keep the log targets separate, I would instead have in struct log_target
an llist of void* for each filter_data where we can point to N instances we'd
like to flag for raised logging. Then, if the current ctx[] matches any of
those, use the raised logging levels. (Expecting the list to remain short)
This can be filter_fn implementation specific: the filter_data can be used to
point at the first llist_head instead of just one subscriber.
[5]
There's another interesting logging topic: FSM instances. We have the
osmo_fsm_inst feature where we can set all logging emitted by an FSM instance
to a certain logging level. One "problem" with this is that the entire FSM logs
on the same level, and we can only raise or lower all of these messages as one.
The implementation is: remember a logging category and a logging level with the
FSM instance, and log all messages from the FSM on this category and level. The
state transitions and events logged from fsm.c are logged on this logging
level.
Because I wanted to specifically mark some logging as LOGL_ERROR, I've already
broken up that idea by adding the LOGPFSML() macro. It allows passing an
explicit logging level instead of using the FSM instance's. I like to think of
it like this: the FSM instance's logging level tells the fsm.c code on which
level to log state transitions and events (like Debug). The logging I write in my
FSM implementation that I want to stand out from the state transitions (read:
logging that's more than Debug) should be given more specific logging levels,
like any other code we write. We could actually make LOGPFSML() use
MAX(fsm_inst.log_level, log_level_arg) so that changing an FSM instance's log
level raises all log messaging.
One could now think, if I want raised logging for a given subscriber, I could
set its FSM instances' logging level so that it prints more logging. But, again
this implies the clumsiness like in [4]: the raised logging would be global
across all logging targets. In this case, there's no easy way to make the
feature log target specific, and neither do we need to...
FSM instance specific logging levels, while sounding very nice at first, are a
non-feature when taking multiple logging targets into account. The simpler way
to show FSM logging for a specific subscriber is to use above suggested
features: flag the subscriber for raised logging on a speicific log target and
set the raised logging level for DVLR to Debug, relying on the logging ctx to
be set correctly when the subscriber's FSMs are active [6]. No need to adjust
an FSM instance's logging level individually. So, the log level could also be
stored in the osmo_fsm definition instead of each separate osmo_fsm_inst.
[6]
Setting the log context needs to generally happen in these situations:
- message received (e.g. from the MS or HLR)
- timer callback called (e.g. state timeout, SMS queue)
Particularly for timeouts on FSM instances' states this is a bit tricky. If the
fsm.c code triggers the timeout, there isn't a general hook to set the log
context to the FSM's subscriber first. The FSM instances that have timeouts set
need to also set a specific timer_cb to update the log context and repeat the
timeout logging "Timeout of T123" that comes from fsm.c before timer_cb() is
called. (That means the timeout logging may be issued twice in some situations,
once by fsm.c and once by the FSM implementation's timer_cb after setting the
log context to make sure raised logging includes it.)
Maybe we can add a pre_timer_cb to osmo_fsm, or teach osmo_fsm to set a
specific log context whenever it logs things? Probably not that important.
[7]
In the VTY, my plan would look like this:
logging = e:RSL,RR,n:MM,CC ! replace all levels
logging + n:PAG ! set some more
logging raised = d:MM,i:CC ! applies to flagged logging contexts
logging raised + d:PAG,NM
logging raise subscriber (imsi|msisdn|...) 1234
...
logging raise subscriber (imsi|msisdn|...) 1234 not
For setting the logging levels, I would like to introduce letters f, e, n, i, d
for the log levels (Fatal, Error, Notice, Info, Debug) instead of the level
numbers that are "hidden" in logging.h, plus o for Off to disable categories.
I would prefer the format:
[l:]CAT[,[l:]CAT[,...]]
so that a level is followed by N categories to be on this level, possibly
followed by another level and another categories list. (i.e. from the current
format, swap meaning of ',' and ':', reverse the current <cat>[,<level>] order
to [<level>:]<cat> and carry the level over to following categories.)
I would also add the 'all' keyword in the logging category parsing:
logging = n:all,i:MM,CC,PAG
which would put all levels on Notice, except MM, CC and PAG on Info.
To avoid confusion with the old 'logging categories' format, I would like to go
for '=' and '+' commands (yes, the VTY can handle these). The old 'logging
categories' might even co-exist.
'logging = ...' and 'logging + ...' should imply 'logging enable'.
The 'logging raised *' sets the logging levels used for flagged subscribers;
they should default to d:all, i.e. everything on debug level.
'logging raise *' flags a given subscriber (or what else we want to add later).
To remove a raise flag from a subscriber, 'logging no raise *' makes sense, but
it is often useful to just recall a previous VTY command and append a keyword,
so I'd make it 'logging raise subscriber imsi 1234 not' for convenience.
The current 'logging level <CAT> <LVL>' can remain as-is; I would add a
'logging raised level' command.
I would completely drop the 'logging filter' commands. But it would still be
useful on a VTY to mute logging to get a usable prompt without the need to
discard the log target:
logging (mute|off)
logging (unmute|on)
These are shorter and more intuitive than 'logging filter all (0|1)'.
The current 'logging filter all everything' command is ambiguous. It sounds
like it would aggressively turn on every last logging message. But instead it
does the opposite: it can only add a general *restriction* on the logging level
for all categories of a log target. Any category that is not enabled will still
not log anything. Also, even if a log target has a more detailed level set, the
log target's global logging level potentially prevents the detailed logging. So
the command should sound more like 'logging restrict all to LEVEL'. It needs a
rename, but IMHO we could also just drop it.
Turning on every last log message could be done by 'logging = d:all'.
Restrictions can be imposed by 'logging + e:RSL,MM,...'. Going back to a
previous complex logging setup can be achieved by recalling the previous
'logging = ' commandline. The VTY could print such a paste-back-able line
showing the current logging levels, so that going back is just a copy-paste on
the VTY.
So much for the unicorn's dream. For now, I'll start off with tidying up the
things under [1] above.
~N
Hi,
Please find BTS test report, week5 2017.
BTSes which has been tested with OsmoNITB are:
- sysmoBTS1002
- octasic BTS3500
- ettus B200
- nanoBTS model:165G
sysmoBTS1002 has been tested with the following 4 channel configurations:
6 TCH/F_TCH/H_PDCH (Osmocom style dynamic timeslots)
3 TCH/F, 3 PDCH
3 TCH/H, 3 PDCH
6 TCH/F_PDCH (ip.access style dynamic timeslots)
All test cases passed.
----------------------------------------------------
octasic BTS3500 has been tested with the next 2 channel configurations:
3 TCH/F, 3 PDCH
3 TCH/H, 3 PDCH
All test cases passed.
-----------------------------------------------------
ettus B200 has been tested with below channel configurations:
6 TCH/F_TCH/H_PDCH (Osmocom style dynamic timeslots)
3 TCH/F, 3 PDCH
3 TCH/H, 3 PDCH
6 TCH/F_PDCH (ip.access style dynamic timeslots)
All test cases passed.
------------------------------------------------------
During a weekly test of nanoBTS model:165G, an issue has been
discovered. It is reported in redmine: https://osmocom.org/issues/1933
Short description: It was found that the initiated voice call drops
immediately after B subscriber accepts the call, when nanoBTS (model
165G) and NITB is configured with dynamic channels: 3 TCH/H and 3 PDCH.
Default voice codec tch-h hr has been selected.
Remaining test cases passed.
regards,
Ivaylo
--
------------------------------
- Ivaylo Kostov <ikostov(a)sysmocom.de> <mailto:ikostov@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,
I want to connect osmo-sip-connector with and freepbx server installed
into another machine.
is it possible ?
anybody have a file configuration exemple ?
Thanks
Hi
________________________________
On Wed, Feb 15, 2017 at 09:39:15AM +0000, Snehasish Kar wrote:
> A query, can it be now used with an usrp.
> Please kindly always post questions to the mailing list and not to individual developers. Thanks.
Sorry for that.
> It can be for many years ?!? That's what OsmoTRX, OsmoBTS (with osmo-bts-trx backend) are for.
I meant the version of osmo-nitb supporting 3G be used with a USRP ?
BR
Snehasish
Hi Pablo,
Resent as v2, because I forgot the net-next target. Sorry for noise,
I promise I won't forget it again.
This series lays the groundwork for removing the socket references from
the GTP netdevice by removing duplicate code and simplifying the logic on
some code paths.
It slighly changes the GTP genl API by making the socket parameters optional
(though one of them is still required).
The removal of the socket references will break the 1:1 releation between
GTP netdevice and GTP socket that prevents us to support multiple VRFs with
overlaping IP addresse spaces attached to the same GTP socket (needed for
multi APN support).
Regards
Andreas
Andreas Schultz (6):
gtp: make GTP sockets in gtp_newlink optional
gtp: merge gtp_get_net and gtp_genl_find_dev
gtp: unify genl_find_pdp and prepare for per socket lookup
gtp: consolidate pdp context destruction into helper
gtp: add socket to pdp context
gtp: consolidate gtp socket rx path
drivers/net/gtp.c | 564 +++++++++++++++++++++++++++---------------------------
1 file changed, 280 insertions(+), 284 deletions(-)
--
2.10.2
Great work Max!
I just applied your patch to the libosmocoding, and the problem was solved.
Valgrind now says, that everything is ok ;)
BTW: did the osmo-bts-trx TCH/H problem solved?
With best regards,
Vadim Yanitskiy.
> Is this also covered in gerrit review for some of your patches like 933
> or 1628?
Yeah, it's covered by https://gerrit.osmocom.org/#/c/933/ , and this is
exactly the reason, why the change isn't ready to merge yet :(
Well, some more details:
# valgrind --track-origins=yes tests/coding/.libs/lt-coding_test
==27652== Memcheck, a memory error detector
==27652== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==27652== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==27652== Command: tests/coding/.libs/lt-coding_test
==27652==
xcch_decode: n_errors=60 n_bits_total=456 ber=0.13
xcch_decode: n_errors=60 n_bits_total=456 ber=0.13
xcch_decode: n_errors=60 n_bits_total=456 ber=0.13
tch_fr_decode: n_errors=8 n_bits_total=378 ber=0.02
tch_fr_decode: n_errors=8 n_bits_total=378 ber=0.02
tch_fr_decode: n_errors=10 n_bits_total=456 ber=0.02
tch_fr_decode: n_errors=10 n_bits_total=456 ber=0.02
tch_fr_decode: n_errors=10 n_bits_total=456 ber=0.02
==27652== Conditional jump or move depends on uninitialised value(s)
==27652== at 0x400F49: ubits2sbits (coding_test.c:48)
==27652== by 0x401416: test_hr (coding_test.c:290)
==27652== by 0x400D62: main (coding_test.c:486)
==27652== Uninitialised value was created by a stack allocation
==27652== at 0x4E402ED: gsm0503_tch_hr_encode (gsm0503_coding.c:1839)
==27652==
==27652== Conditional jump or move depends on uninitialised value(s)
==27652== at 0x400F4E: ubits2sbits (coding_test.c:54)
==27652== by 0x401416: test_hr (coding_test.c:290)
==27652== by 0x400D62: main (coding_test.c:486)
==27652== Uninitialised value was created by a stack allocation
==27652== at 0x4E402ED: gsm0503_tch_hr_encode (gsm0503_coding.c:1839)
==27652==
==27652== Conditional jump or move depends on uninitialised value(s)
==27652== at 0x5422CCE: osmo_conv_decode_scan (conv.c:394)
==27652== by 0x54231E8: osmo_conv_decode (conv.c:616)
==27652== by 0x4E3D677: osmo_conv_decode_ber (gsm0503_coding.c:469)
==27652== by 0x4E3FFCD: gsm0503_tch_hr_decode (gsm0503_coding.c:1818)
==27652== by 0x40144A: test_hr (coding_test.c:336)
==27652== by 0x400D62: main (coding_test.c:486)
==27652== Uninitialised value was created by a stack allocation
==27652== at 0x4E3FF30: gsm0503_tch_hr_decode (gsm0503_coding.c:1763)
==27652==
==27652== Conditional jump or move depends on uninitialised value(s)
==27652== at 0x5422D08: osmo_conv_decode_scan (conv.c:403)
==27652== by 0x54231E8: osmo_conv_decode (conv.c:616)
==27652== by 0x4E3D677: osmo_conv_decode_ber (gsm0503_coding.c:469)
==27652== by 0x4E3FFCD: gsm0503_tch_hr_decode (gsm0503_coding.c:1818)
==27652== by 0x40144A: test_hr (coding_test.c:336)
==27652== by 0x400D62: main (coding_test.c:486)
==27652== Uninitialised value was created by a stack allocation
==27652== at 0x4E3FF30: gsm0503_tch_hr_decode (gsm0503_coding.c:1763)
==27652==
==27652== Conditional jump or move depends on uninitialised value(s)
==27652== at 0x5422F91: osmo_conv_decode_flush (conv.c:509)
==27652== by 0x5423235: osmo_conv_decode (conv.c:619)
==27652== by 0x4E3D677: osmo_conv_decode_ber (gsm0503_coding.c:469)
==27652== by 0x4E3FFCD: gsm0503_tch_hr_decode (gsm0503_coding.c:1818)
==27652== by 0x40144A: test_hr (coding_test.c:336)
==27652== by 0x400D62: main (coding_test.c:486)
==27652== Uninitialised value was created by a stack allocation
==27652== at 0x4E3FF30: gsm0503_tch_hr_decode (gsm0503_coding.c:1763)
==27652==
==27652== Conditional jump or move depends on uninitialised value(s)
==27652== at 0x4E3D72C: osmo_conv_decode_ber (gsm0503_coding.c:480)
==27652== by 0x4E3FFCD: gsm0503_tch_hr_decode (gsm0503_coding.c:1818)
==27652== by 0x40144A: test_hr (coding_test.c:336)
==27652== by 0x400D62: main (coding_test.c:486)
==27652== Uninitialised value was created by a stack allocation
==27652== at 0x4E3FF30: gsm0503_tch_hr_decode (gsm0503_coding.c:1763)
==27652==
tch_hr_decode: n_errors=11 n_bits_total=211 ber=0.05
tch_hr_decode: n_errors=10 n_bits_total=456 ber=0.02
tch_hr_decode: n_errors=10 n_bits_total=456 ber=0.02
tch_hr_decode: n_errors=10 n_bits_total=456 ber=0.02
pdtch_decode: n_errors=0 n_bits_total=456 ber=0.00
pdtch_decode: n_errors=132 n_bits_total=588 ber=0.22
pdtch_decode: n_errors=220 n_bits_total=676 ber=0.33
pdtch_decode: n_errors=0 n_bits_total=444 ber=0.00
pdtch_decode: n_errors=0 n_bits_total=456 ber=0.00
pdtch_decode: n_errors=132 n_bits_total=588 ber=0.22
pdtch_decode: n_errors=220 n_bits_total=676 ber=0.33
pdtch_decode: n_errors=0 n_bits_total=444 ber=0.00
Success
==27652==
==27652== HEAP SUMMARY:
==27652== in use at exit: 0 bytes in 0 blocks
==27652== total heap usage: 2,367 allocs, 2,367 frees, 397,488 bytes
allocated
==27652==
==27652== All heap blocks were freed -- no leaks are possible
==27652==
==27652== For counts of detected and suppressed errors, rerun with: -v
==27652== ERROR SUMMARY: 7041 errors from 6 contexts (suppressed: 0 from 0)
I paid my attention on the "Uninitialised value was created by a stack
allocation" warning, and merely used memset() to fill some arrays by 0x00
in the gsm0503_tch_hr_decode(). And... it was the first time when I got
successful build on Jenkins! This is the temporary solution:
sbit_t iB[912], cB[456], h;
ubit_t conv[98], b[112], d[112], p[3];
int i, rv, steal = 0;
/**
* Fix valgrind warnings:
* "Uninitialised value was created by a stack allocation"
* "Conditional jump or move depends on uninitialised value(s)"
*/
memset(iB, 0x00, sizeof(iB));
Then I started to dig deeper into the code, and used memset()
one more time: http://pastebin.com/jBJT3q6R
This dirty printf based debug led me closer to the problem. We are getting
different results (successes and fails) because the gsm0503_tch_burst_map()
refers to uninitialized value at iB[353].
Now we need to find out, where is the bug. There are two assumptions:
1) The gsm0503_tch_hr_interleave() doesn't initialize the iB[353];
2) The gsm0503_tch_burst_map() refers to the value which it shouldn't
refer to.
With best regards,
Vadim Yanitskiy.
Hi,
I was following the procedure "Compiling osmo-bts for sysmoBTS" and
using poky/1.5.4/sysroots/armv5te-poky-linux-gnueabi
During execution of libosmocore project it failed with:
...
GEN gsm0503_conv.c
Traceback (most recent call last):
File "../../utils/conv_gen.py", line 26, in <module>
import sys, os, math, argparse
ImportError: CC oap.lo
No module named argparse
Makefile:735: recipe for target 'gsm0503_conv.c' failed
make[2]: *** [gsm0503_conv.c] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/home/ivaylo/net/osmo/libosmocore/src/gsm'
Makefile:460: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/ivaylo/net/osmo/libosmocore'
Makefile:327: recipe for target 'all' failed
make: *** [all] Error 2
...
I am using:
Python 2.7.12+ (default, Sep 17 2016, 12:08:02)
[GCC 6.2.0 20160914] on linux2
Type "help", "copyright", "credits" or "license" for more information.
I think that something is broken.
regards,
Ivaylo
--
------------------------------
- Ivaylo Kostov <ikostov(a)sysmocom.de> <mailto:ikostov@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 and others,
It seems, I faced similar problem while working on the libosmocoding.
Despite the bursts_test in OsmoBTS always pass without any errors,
when I merely moved some parts of GSM 05.03 code into a separate
library, this test sometimes passes and fails on different machines...
Thanks to tnt, who suggested me to use valgrind. Using this great tool
and some tricks with memset(), I found, that the gsm0503_tch_burst_map()
uses one uninitialized bit from the iB within the tch_hr_encode(). The same
things happens in the tch_hr_decode().
I don't know, is it gsm0503_tch_hr_(de)interleave's bug
or gsm0503_tch_burst_(un)map's one, we need to check GSM 05.03
specifications.
With best regards,
Vadim Yanitskiy.
