This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Holger Freyther holger at freyther.de
> On 17 Aug 2016, at 13:11, Keith <keith at 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