From baa225ed867fa7357ad05b35b90c9ecb7192f189 Mon Sep 17 00:00:00 2001 From: Jacob Erlbeck Date: Fri, 28 Feb 2014 15:14:40 +0100 Subject: msgb: Add msgb_hexdump() function This function works like osmo_hexdump() and returns a static buffer containing hex bytes along with markers for the layers. Note that it uses osmo_hexdump() internally, thus a call to msgb_hexdump() invalidates the buffer that has been returned by an earlier call to osmo_hexdump(). In short: don't mix them in a single call printf(). Sponsored-by: On-Waves ehf --- include/osmocom/core/msgb.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/osmocom/core/msgb.h') diff --git a/include/osmocom/core/msgb.h b/include/osmocom/core/msgb.h index fe2733b7..5d4bd84b 100644 --- a/include/osmocom/core/msgb.h +++ b/include/osmocom/core/msgb.h @@ -73,6 +73,7 @@ extern void msgb_enqueue(struct llist_head *queue, struct msgb *msg); extern struct msgb *msgb_dequeue(struct llist_head *queue); extern void msgb_reset(struct msgb *m); uint16_t msgb_length(const struct msgb *msg); +extern const char *msgb_hexdump(const struct msgb *msg); #ifdef MSGB_DEBUG #include -- cgit v1.2.3 From 8dac4159adb7377f016317808e3a6b0c79df7fa1 Mon Sep 17 00:00:00 2001 From: Jacob Erlbeck Date: Tue, 28 Jan 2014 11:03:11 +0100 Subject: ladpm: Fix msgb handling and SAPI=3 establishment delay Currently it takes 3s to establish a SAPI 3 SACCH connection with osmo-bts. This is due to the fact, that a broken SABME request is sent first and and is ignored by the MS. Then, after a T200 timeout (2s) the SABME command is sent again (this time correctly) and answered by the MS. The first SABME message is broken (it has a length field of 3 and ends with 3 bytes from the tail of the original RSL message), because of it is expected throughout lapdm.c that msg buffers containing RSL have msg->l2h == msg->data. Some abis input drivers fulfill this but IPA doesn't, thus the 3 bytes of the IPA header are still part of the msg and confuse length computation. Since internal fields of the msg are modified directly, this is difficult to see. This patch adds a new function msgb_pull_to_l3() that explicitely skips over all headers prepending L3 and therefore resets l1h and l2h. This function is then used instead of msgb_pull_l2h() which only worked correctly when msg->l2h == msg->data. In addition, code manipulating msg->tail and msg->len directly has been replaced by calls to msgb_trim(). Note that this patch does not fix all issues of this case in the LADP related code. Ticket: SYS#192 Sponsored-by: On-Waves ehf --- include/osmocom/core/msgb.h | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'include/osmocom/core/msgb.h') diff --git a/include/osmocom/core/msgb.h b/include/osmocom/core/msgb.h index 5d4bd84b..33e8081f 100644 --- a/include/osmocom/core/msgb.h +++ b/include/osmocom/core/msgb.h @@ -300,6 +300,21 @@ static inline unsigned char *msgb_pull(struct msgb *msgb, unsigned int len) return msgb->data += len; } +/*! \brief remove (pull) all headers in front of l3h from the message buffer. + * \param[in] msgb message buffer with a valid l3h + * \returns pointer to new start of msgb (l3h) + * + * This function moves the \a data pointer of the \ref msgb further back + * in the message, thereby shrinking the size of the message. + * l1h and l2h will be cleared. + */ +static inline unsigned char *msgb_pull_to_l3(struct msgb *msg) +{ + unsigned char *ret = msgb_pull(msg, msg->l3h - msg->data); + msg->l1h = msg->l2h = NULL; + return ret; +} + /*! \brief remove uint8 from front of message * \param[in] msgb message buffer * \returns 8bit value taken from end of msgb -- cgit v1.2.3