Cellular Network Infrastructure » Radio Access Network » OsmoBTS

I started doing some clean up in order to sort out real need for different states variables to be able to clrearly indicate in code above when we should send or not data.

remote: https://gerrit.osmocom.org/c/osmo-bts/+/15613 struct gsm_bts: Add model_priv pointer handing bts_model specific data
remote: https://gerrit.osmocom.org/c/osmo-bts/+/15614 bts-trx: Allocate struct osmo_trx_clock_state as part of bts-trx private data
remote: https://gerrit.osmocom.org/c/osmo-bts/+/15615 bts-trx: Move transceiver_available as part of bts-trx private data

Next bunch of refactor patches to fix the issue:
remote: https://gerrit.osmocom.org/c/osmo-bts/+/15627 bts-trx: vty: Print phy link state in cmd 'show transceiver'
remote: https://gerrit.osmocom.org/c/osmo-bts/+/15628 bts-trx: trx_set_bts(): Avoid double loop by checking current trx
remote: https://gerrit.osmocom.org/c/osmo-bts/+/15629 bts-trx: Rework code handling poweron state
remote: https://gerrit.osmocom.org/c/osmo-bts/+/15630 bts-trx: Don't reset transceiver_available in scheduler_trx.c
remote: https://gerrit.osmocom.org/c/osmo-bts/+/15615 bts-trx: Get rid of messy transceiver_available state handler
remote: https://gerrit.osmocom.org/c/osmo-bts/+/15631 bts-trx: Drop unused func check_transceiver_availability()

Once merged the ticket can be closed (issue is fixed as a side-effect of last patch).

Just want to make sure - after all these patches, is `osmo-bts-trx` still monitoring that `osmo-trx` is "alive"? By monitoring CLK INDs or somehow else? I.e. will it notice if `osmo-trx` suddenly crash?

During CMD POWERON command, the TRX is expected to create all required sockets and start sending clock indications against osmo-bts-trx, and once done, asnwer with RSP POWERON 0.
At that point, "powered" bool in BTS becomes true, until CMD POWEROFF is sent (and RSP POWEROFF 0 is received).

Once TRX is "powered", osmo-bts-trx starts sending bursts to TRX:

    if (trx_if_powered(l1h)) {
         send(l1h->trx_ofd_data.fd, buf, nbits + 6, 0);    <--- I just detected we don't check return code here, I'll submit a patch.

If osmo-trx crashes, its sockets will become unavailable and trx_data_read_cb() in osmo-bts-trx will eventually fail, detecting thus that TRX is unavailable. I think thought that apart from logging the errr it doesn't report it to upper layers. That's something we may want to improve (by calling for instance bts_shutdown()).

What really stops the BTS if TRX becomes unavailable is bts_shutdown() in scheduler_trx.c. First IND CLOCK received in trx_sched_clock() triggers trx_setup_clock(), which sets up a timerfd that triggers from time to time to push frames to upper layers. if IND CLOCK stopped being receivied, wall clock vs ind clock skews too much and trx_fn_timer_cb() exists the BTS with bts_shutdown(bts, "No clock from osmo-trx");.

You can easily see it by running osmo-bts-trx and osmo-trx, then at some point killing osmo-trx. osmo-bts-trx will stop with the "No clock from osmo-trx" message.

Now the question is: What happens if TRX answers with RSP POWERON 0 and sockets are available but no CLOCK IND is ever set? Then the timerfd is never set, so trx_fn_timer_cb() is never called and probably BTS never exits and thinks everything's fine, but the scheduler is really paused (so for instance no DL bursts are sent against the TRX). So it seems we need to fix this case by adding some kind of timing in osmo-bts-trx to timeout if first CLOCK IND is not send after X seconds, then exit. (I tried the scenario by commenting out CLOCK ind write() in osmo-trx).

But this issue didn't come from last patches merged, afaiu it was already there. I'll provide patches for that shortly.

Improvement to log send/recv() errors:
https://gerrit.osmocom.org/c/osmo-bts/+/15702 bts-trx: Log TRXC and TRXD socket recv()/send() failures

I'll work on the timeout if no IND CLOCK is never received later.

Timeout after POWERON and no CLOCK IND ever received is here:
https://gerrit.osmocom.org/c/osmo-bts/+/15706 bts-trx: Time out if no clock ind recvd after RSP POWERON

Once merged I think we can close the ticket if ipse has not other concerns.