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