Hi Jolly,
I have finally tracked down the LAPDm breakage we have in osmo-bts. It comes from the fact that we get a RSL message from the BSC and then forward the msgb that holds the IPA header followed by the RSL message. There is code in both lapdm.c and lapd_core.c that tries to extract the RSL_IE_L3_INFO and then updates the msgb to be of the length of that TLV and sets the l3h to the start of the L3_INFO:
Currently: msgb_pull_l2h(msg); msg->len = length; msg->tail = msg->data + length;
this kind of assumes that before the "msgb_pull_l2h", msg->l2h == msg->data but in the above case it does not hold true. You will need to use "msg->l3h + length" with this idiom.
Fixes: I have pushed some fixes to "zecke/lapd-fixes", but I would like to see the above pattern move to msgb.h, and it would be nice if we could write test cases for the other methods in lapdm.c that manipulate the msgb.h (currently only data request is tested).
One more thing: I would be somehow happy if lapdm_rslms_recvmsg would indicate if any messages were sent or queued, currently it will return 0 in more than one case.
cheers holger
Currently: msgb_pull_l2h(msg); msg->len = length; msg->tail = msg->data + length;
hi holger,
you are right. the header (between l2h and l3h) is pulled away, but this code assumes that there is nothing in front. you must use "msg->tail = msg->l3h + lenght" to correctly set the length of the L3 data, in case you have still something in front of l2h, so that l2h != data. since osmocom does not have something in front of l2h, it works, even if it is not the clean way.
regards,
andreas