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 22:27, Keith <keith at rhizomatica.org> wrote: > > > > On 17/08/2016 21:43, Holger Freyther wrote: >> Maybe not the version of osmo-bts you run but I think later versions >> mark channels as broken as well (e.g. if the DSP did something odd). >> *If* the channel release ack (or activation) is just delayed it should clean-up properly if "type sysmobts" is set in the config. > type sysmobts is set in the config. > Unfortunately, in a new installation > (https://twitter.com/ninalakhani/status/765250788046143488) with a wifi > link of some 3 KM or so > we are ending up with this kind of situation after a short time: > > OpenBSC# show lchan su > BTS 0, TRX 0, Timeslot 1, Lchan 0, Type NONE - L1 MS Power: 33 dBm type none? What OpenBSC version is that? So just the none already looks broken. > Can I ask, What triggers the eventual calling of > rsl_rx_rf_chan_rel_ack(), (I tried to trace it back but get a bit lost.) > I do not understand the logic, as it would seem that once the REL ACK is > lost, then it is lost, right? > It would seem that something in openBSC needs to check for broken > channels and release them. But then.. my understanding here is limited. the actual arrival of the REL_ACK message. holger