On 17 Aug 2016, at 13:11, Keith
<keith(a)rhizomatica.org> wrote:
Initial questions:
Why does the broken unusable channel stay as such until manual intervention,
Is is just because the code has not been written to monitor and recover,
or is there some other reason?
I am thinking that nobody ever did this, probably all testing and
installation has been done using nice reliable cabled ethernet and not
ugly nasty packet dropping 3km wifi links. :-)
A RF Channel Release NACKed, or two responses or no response. With equipment like a
nanoBTS you just don't know what the state of the channel is.
/*
* The BTS didn't respond within the timeout to our channel
* release request and we have marked the channel as broken.
* Now we do receive an ACK and let's be conservative. If it
* is a sysmoBTS we know that only one RF Channel Release ACK
* will be sent. So let's "repair" the channel.
*/
if (lchan->state == LCHAN_S_BROKEN) {
int do_free = is_sysmobts_v2(lchan->ts->trx->bts);
LOGP(DRSL, LOGL_NOTICE,
"%s CHAN REL ACK for broken channel. %s.\n",
gsm_lchan_name(lchan),
do_free ? "Releasing it" : "Keeping it
broken");
if (do_free)
do_lchan_free(lchan);
return 0;
}
so I assume you want to put "type sysmobts" into the OpenBSC config. IIRC I
added that specially for Rhizomatica.
cheers
holger