Attention is currently required from: laforge.

1 comment:

Patchset:
- Patch Set #1:
  well, it is probably simply a question of endianness of the underlying CPU, right? It's a 16 bit va […]
  These flags are applied to a `uint32_t` value in **native** endianness for the host. nanoBTS and osmo-bts report a value in network byte order, which needs to be converted to host's byte order before doing any `u32 & NM_IPAC_F_` checks.
  - osmo-bsc: see `ipacc_parse_supp_flags()` for a usage example,
  - osmo-bts: grep for `NM_IPAC_F_CHANT_`.
  The problem this patch is solving is not about endianness, it's about wrong offset values assigned to MCS related `NM_IPAC_F_` constants. We should get this merged to fix parsing of the feature reports sent by nanoBTS. As a side effect, this will change the bit-vector sent by osmo-bts, but it's not critical because we never request GPRS related features from osmo-bts and so far only using this for informative purposes.

To view, visit change 34427. To unsubscribe, or for help writing mail filters, visit settings.