Cellular Network Infrastructure » Radio Access Network » OsmoBTS

In osmo-gsm-tester setup (CN+BSC running in main unit, BTS+PCU in sysmobts).

RUnning osmo-bts-sysmo with -M (pcu direct access to PHDATA) works fine.

If run without -M, then the phdata_ind packets are printed in uplink GSMTAP (by function to_gsmtap()), but never arrive to the osmo-pcu through the unix socket, and then osmo-pcu neves sends Attach Request to osmo-sgsn.

What I debugged so far:
The packets arrive to l1sap.c:l1sap_up():

    case OSMO_PRIM(PRIM_PH_DATA, PRIM_OP_INDICATION):
        to_gsmtap(trx, l1sap);
        rc = l1sap_ph_data_ind(trx, l1sap, &l1sap->u.data);
        break;

In there the packet is sent through GSMTAP, but l1sap_ph_data_ind() is returning -22 (EINVAL).

I verified that indeed that einval comes from l1sap.c:l1sap_ph_data_ind() code path which returns early and doesn't send content of the message through the unix socket:

static int l1sap_ph_data_ind(struct gsm_bts_trx *trx,
     struct osmo_phsap_prim *l1sap, struct ph_data_param *data_ind)
{
    struct msgb *msg = l1sap->oph.msg;
    uint8_t *data = msg->l2h;
    int len = msgb_l2len(msg);
    ...
    if (ts_is_pdch(&trx->ts[tn])) {
        ...
        /* don't send bad frames to PCU */
        if (len == 0) {
            LOGP(DL1P, LOGL_ERROR, "pespin: len==0, avoid send to pcu\n");
            return -EINVAL;
        }
        ...
        pcu_tx_data_ind(...)
        ...
    }

I see several possible issues there:
- In lower layers (l1) in osmo-bts-sysmo, we are not packing the indication correctly into the msgb.
- We are not doing the correct check in l1sap_ph_data_ind() and there's good information in the packets.
- We are not doing the correct check in to_gsmtap() if the packet is actually containing non correct data. We should avoid sending it and logging a NOTICE or similar instead.