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