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.
Dear all,
so far libosmo-sccp had some code with a partial SCCP implementation
that date back to the earliest day of OsmoBSC in 2009, done by Holger.
It also contained a SUA implementation which (mostly) I did last year
in the wake of the Iuh and IuCS/IuPS support for the Osmocom 3G support.
The latter code is already more 'modern' and uses the osmocom primitives
(osmo_prim) between the SCCP User (the application) and the SCCP
Provider (the library). Those primitives are modelled after the related
specifications.
What I'm now wokring on is to get those last SUA related patches finally
merged in master, and to
* add missing ASPTM and ASPSM protocol code + osmo_fsm state machines in
a generic way that they can be shared by all SIGTRAN xUA variants
* add M3UA while sharing more code between SUA and M3UA
* introduce a MTP SAP based on osmo_prim that can be used on top of M3UA
* wrap the existing sccp.c code to use the MTP SAP on the lower end and
the SCCP User SAP on the upper edge
In the above implementations, I am aiming for implementing SGW, ASP and
IPSP roles. However, primary focus is on ASP.
In the end, we will be able to stack M3UA and SCCP code using
primitives, and interact with the SCCP using the exact same primitives
and API as we interact with SUA currently.
This will give us:
* true/real IuCS/IuPS suppotr (we currently do SUA, which is not as per
spec) in OsmoCSCN, OsmoSGSN and OsmoHNBGW without any real modificatin
of their code
* a way towards 3GPP compliant AoIP, by using the SCCP User SAP from
OsmoBSC. This means that we'll also have to add that SCCP User SAP to
the SCCPlite/IPA code that OsmoBSC is using for now.
While all of the above sounds great, it somehow hurts me that we have
already some (partial?) implementations of M3UA in cellmgr-ng
(particularly the osmo-stp application). It hurts me that I'm not able
to use the code that Holger wrote in recent years, but I still think
it's worth-while to do an implementation centered around osmo_prim for
layer-boundaries and osmo_fsm for state machines.
So my apologies to Holger on this. It's not "Not Invented Here"
syndrome, but I think there are reasons to take a different route than
the existing code. I'm of course also looking forward to hearing other
opinions on that.
[... and while I'm working on this, I also think about introducing some
generic inter-layer primitive logging code, so we can enable logging of
the primitives at a given SAP without the specific SAP implementation
having to implement anything, like we do in terms of osmo_fsm logging]
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)
Will there be a separate mailing list for the accelerate3g5 "winners"? Maybe we
could just make it a general osmocom-3G@ mailing list. Alternatively, we could
use this list for 3G as well. What's the plan?
~N
[cid:9b893015-fe6c-4d05-9933-7169f767fc97]
________________________________
From: OpenBSC <openbsc-bounces(a)lists.osmocom.org> on behalf of openbsc-request(a)lists.osmocom.org <openbsc-request(a)lists.osmocom.org>
Sent: Thursday, February 9, 2017 9:00:47 AM
To: openbsc(a)lists.osmocom.org
Subject: OpenBSC Digest, Vol 28, Issue 6
Send OpenBSC mailing list submissions to
openbsc(a)lists.osmocom.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osmocom.org/mailman/listinfo/openbsc
or, via email, send a message with subject or body 'help' to
openbsc-request(a)lists.osmocom.org
You can reach the person managing the list at
openbsc-owner(a)lists.osmocom.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenBSC digest..."
Today's Topics:
1. Re: weekly test report (w5 2017) (Ivaylo Kostov)
2. Re: weekly test report (w5 2017) (Harald Welte)
3. Re: weekly test report (w5 2017) (Neels Hofmeyr)
4. Re: OpenBSC Digest, Vol 28, Issue 5 (Rajitha peiris)
----------------------------------------------------------------------
Message: 1
Date: Wed, 8 Feb 2017 16:33:26 +0100
From: Ivaylo Kostov <ikostov(a)sysmocom.de>
To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Cc: Harald Welte <laforge(a)gnumonks.org>, openbsc(a)lists.osmocom.org
Subject: Re: weekly test report (w5 2017)
Message-ID: <06726d26-d66f-d48d-cf9d-533178a13ada(a)sysmocom.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Neels,
Yes. I do have TCH/F_PDCH dynamic timeslots in the test procedure.
regards,
Ivaylo
On 08.02.2017 16:26, Neels Hofmeyr wrote:
> (found this mail stuck in my outbox, sending late)
>
> On Mon, Feb 06, 2017 at 10:09:23AM +0100, Ivaylo Kostov wrote:
>> Hi Harald,
>>
>> I see. What was communicated to me was that NITB channel configuration
>> TCH/F_TCH/H_PDCH is not supported with nanoBTS.
>>
>> I will have in mind that nanoBTS does not support HR (v1) codec.
>
> Yes, we discussed TCH/F_TCH/H_PDCH for the nanoBTS. I remember to be surprised
> because from some discussion it appeared that the nanoBTS supports HR, and I
> was expecting TCH/F only.
>
> While talking about codecs, the ip.access nanoBTS *should* in fact support the
> TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of
> your testing procedure and add it if not?
>
> ~N
>
>--
------------------------------
- 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
------------------------------
------------------------------
Message: 2
Date: Wed, 8 Feb 2017 16:45:57 +0100
From: Harald Welte <laforge(a)gnumonks.org>
To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Cc: Ivaylo Kostov <ikostov(a)sysmocom.de>, openbsc(a)lists.osmocom.org
Subject: Re: weekly test report (w5 2017)
Message-ID: <20170208154557.2rmslkrzuqlv7xc4@nataraja>
Content-Type: text/plain; charset=us-ascii
Hi all,
On Wed, Feb 08, 2017 at 04:26:11PM +0100, Neels Hofmeyr wrote:
> While talking about codecs, the ip.access nanoBTS *should* in fact support the
> TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of
> your testing procedure and add it if not?
libbsc should be extended to handle those restrictions, i.e. reject a
configuration containing HR codec or a osmocom-style dynamic channel on
a bts model 'nanobts'.
Similarly, the BS11 should reject any codec except HRv1, FR and EFR
(i.e. no AMR).
In reality there are also older nanoBTSs that don't support AMR (as far
as I remember), but that shouldn't prevent us from having at least the
most basic checks in place.
For osmo-bts, we need a more sophisticated hand-shaking mechanism, as
there are many different hardware/PHYs (and associated versions)
supported by it. This is left for further study ;)
--
- 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)
------------------------------
Message: 3
Date: Thu, 9 Feb 2017 00:43:35 +0100
From: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
To: Harald Welte <laforge(a)gnumonks.org>
Cc: Ivaylo Kostov <ikostov(a)sysmocom.de>, openbsc(a)lists.osmocom.org
Subject: Re: weekly test report (w5 2017)
Message-ID: <20170208234335.GB27422(a)my.box>
Content-Type: text/plain; charset="us-ascii"
On Wed, Feb 08, 2017 at 04:45:57PM +0100, Harald Welte wrote:
> libbsc should be extended to handle those restrictions, i.e. reject a
> configuration containing HR codec or a osmocom-style dynamic channel on
> a bts model 'nanobts'.
i.e. checks on the VTY level.
Seems like we want an issue for that: https://osmocom.org/issues/1946
~N
Hi.
There seems to be peculiar coding error with osmo-bts-trx and usrp b210:
...
<0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an
HR frame (211/211 bits) [0/0/0]
<0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550946
ts=7 for TCH/H(1)
<0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an
HR frame (211/211 bits) [1/0/0]
<0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550950
ts=7 for TCH/H(1)
<0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an
HR frame (211/211 bits) [0/0/0]
<0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550955
ts=7 for TCH/H(1)
<0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an
HR frame (211/211 bits) [1/0/0]
<0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550959
ts=7 for TCH/H(1)
<0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an
HR frame (211/211 bits) [0/0/0]
...
The error seems to:
- happen only on 2nd subslot of TCH/H
- does not prevent calls establishement
- let voice to go through
The visible effect though is extra delay for call establishment when BSC
allocates next available subslot - see
https://projects.osmocom.org/issues/1795 for details.
Have anyone else seen this?
It could be that tch_hr_decode() screw up bits somehow while trying to
decode stolen FACCH bits but the code seems rather arcane. For instance,
when calling unmap (it actually just attempts to get hu(B) and hl(B)
flags from 3GPP TS 45.003 §4.3.5 located in bits 58 and 57
correspondingly) potentially stolen bits in the beginning of function,
why bursts 0..3 are treated as even and 2..4 as odd?
--
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
Hello all
can anyone send me a openbsc.cfg file for nanobts 1900pcs....? because still i am struck with my nanobts pcs1900.....i can send sms but no voice calls.....do i need to install mISDN and LCR for single bts ? ....
thanks
regards
Rajitha Peiris
Sri lanka
________________________________
From: OpenBSC <openbsc-bounces(a)lists.osmocom.org> on behalf of openbsc-request(a)lists.osmocom.org <openbsc-request(a)lists.osmocom.org>
Sent: Wednesday, February 8, 2017 8:56:30 PM
To: openbsc(a)lists.osmocom.org
Subject: OpenBSC Digest, Vol 28, Issue 5
Send OpenBSC mailing list submissions to
openbsc(a)lists.osmocom.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osmocom.org/mailman/listinfo/openbsc
or, via email, send a message with subject or body 'help' to
openbsc-request(a)lists.osmocom.org
You can reach the person managing the list at
openbsc-owner(a)lists.osmocom.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenBSC digest..."
Today's Topics:
1. Re: MS cannot connect; Location Update Request not received
by BTS (Hossein Amini)
2. Re: [PATCH net-next v2 2/6] gtp: merge gtp_get_net and
gtp_genl_find_dev (Harald Welte)
3. Re: [PATCH net-next v2 1/6] gtp: make GTP sockets in
gtp_newlink optional (Harald Welte)
4. Re: [PATCH net-next v2 4/6] gtp: consolidate pdp context
destruction into helper (Harald Welte)
5. Re: [PATCH net-next v2 5/6] gtp: add socket to pdp context
(Harald Welte)
6. Re: [PATCH net-next v2 3/6] gtp: unify genl_find_pdp and
prepare for per socket lookup (Harald Welte)
7. Re: [PATCH net-next v2 0/6] gtp: misc improvements (Harald Welte)
8. Re: weekly test report (w5 2017) (Neels Hofmeyr)
----------------------------------------------------------------------
Message: 1
Date: Mon, 6 Feb 2017 16:45:40 +0330
From: Hossein Amini <hosseinamini2578(a)gmail.com>
To: openbsc(a)lists.osmocom.org
Subject: Re: MS cannot connect; Location Update Request not received
by BTS
Message-ID:
<CAF81cShkO+JiamxQJXhqfpbOWxi9_8aEWsd5wTDhmZ0Vd912Xw(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I installed master branch now(4/feb/2017 at 18:30) and retry, but I can not
release channel and receive error in nitb.
I do not access to a external timing source like octoClock, do you use
external timing source? do you have a easy solution to check that?
My NITB log is like your log by 20170203014240662 and repeat. I retried
connecting about 10 min but nothing happened.
NITB log that repeat is:
20170204071216381 DRLL <0000> chan_alloc.c:352
(bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4)
Allocating lchan=0 as SDCCH
20170204071216381 DRSL <0004> abis_rsl.c:1819 (bts=0,trx=0,ts=0,ss=0)
Activating ARFCN(0) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x06 ta=0
20170204071216381 DRSL <0004> abis_rsl.c:580
(bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4)
Tx RSL Channel Activate with act_type=INITIAL
20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state
NONE -> ACTIVATION REQUESTED
20170204071216381 DRSL <0004> abis_rsl.c:1546 (bts=0,trx=0,ts=0,ss=0)
CHANNEL ACTIVATE ACK
20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state
ACTIVATION REQUESTED -> ACTIVE
20170204071226381 DRSL <0004> abis_rsl.c:852 (bts=0,trx=0,ts=0,ss=0) RF
Channel Release due to error: 1
20170204071226381 DRSL <0004> abis_rsl.c:762 (bts=0,trx=0,ts=0,ss=0)
DEACTivate SACCH CMD
20170204071226381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state
ACTIVE -> RELEASE DUE ERROR
20170204071226382 DRSL <0004> abis_rsl.c:925 (bts=0,trx=0,ts=0,ss=0) RF
CHANNEL RELEASE ACK
20170204071228382 DRSL <0004> abis_rsl.c:811 (bts=0,trx=0,ts=0,ss=0) is
back in operation.
20170204071228382 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state
RELEASE DUE ERROR -> NONE
On Fri, Feb 3, 2017 at 2:28 AM, Neels Hofmeyr <neels(a)hofmeyr.de> wrote:
> Dear Hossein,
>
> the mailing list is indeed the proper place to ask. If no-one replied to
> your
> question, it either means that no-one knows the answer, or that no-one has
> found the time to look into it. Don't be discouraged by that. Indeed I
> would
> prefer if you ask again on the mailing list instead of asking single mail
> addresses. I actually saw your mail on the list and did not know what to
> answer.
>
> If you ask your question on-list again (possibly once a week), it might be
> that
> someone will come up with either an answer or with more questions that may
> lead
> you to a solution...
>
> I sincerely hope that you will find a solution. It seems to me that it's
> merely
> a minor detail.
>
> ~N
>
>
