On 17 Aug 2016, at 22:27, Keith keith@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