That's probably related to https://gerrit.osmocom.org/#/c/427/3 If that's really the case than fix would be to check for is_11bit of ph_rach_ind_param and adjust length accordingly.
On 07/25/2016 12:22 PM, Neels Hofmeyr wrote:
I just came across this compiler warning:
l1sap.c: In function 'gsmtap_ph_rach': l1sap.c:291:8: warning: assignment from incompatible pointer type [enabled by default] *data = &l1sap->u.rach_ind.ra; ^
It's a uint16_t ra and used like this in common/l1sap.c:
static int gsmtap_ph_rach(struct osmo_phsap_prim *l1sap, uint8_t *chan_type, uint8_t *tn, uint8_t *ss, uint32_t *fn, uint8_t **data, int *len) { [...] *data = &l1sap->u.rach_ind.ra; *len = 1;
A cast like this would fix the compiler warning and make sense if data is interpreted to point at a 16 bit data block, probably in host byte order though:
*data = (uint8_t*)&l1sap->u.rach_ind.ra; *len = 1;But *len = 1 means that **data is an 8bit value? This is sent to gsmtap.
Is *len = 1 something we should fix?
~Neels