Valgrind complains about a possible use after free:
==12800== Invalid read of size 4
==12800== at 0x4073DF6: osmux_tx_sched (linuxlist.h:119)
==12800== by 0x8052B0F: osmux_read_from_bsc_nat_cb (osmux.c:261)
==12800== by 0x453F967: ???
==12800== Address 0x453f710 is 48 bytes inside a block of size 145
+free'd
==12800== at 0x402750C: free (vg_replace_malloc.c:427)
==12800== by 0x4064ADE: talloc_free (talloc.c:609)
==12800== by 0x405AAAA: msgb_free (msgb.c:72)
==12800== by 0x8052492: scheduled_tx_bts_cb (osmux.c:196)
==12800== by 0x4072CF8: osmux_tx_cb (osmux.c:554)
==12800== by 0x4073F03: osmux_tx_sched (osmux.c:582)
==12800== by 0x8052B0F: osmux_read_from_bsc_nat_cb (osmux.c:261)
==12800== by 0x453F967: ???
The problem is that osmux_tx_sched may immediately call osmux_tx_cb for
the first extracted RTP message from the osmux batch, which releases the
message after that.
Remove the message from our list of messages to be transmitted before
the message is passed to the tx callback.
Reported by Mattias Lundstrom.
According to RFC3267, AMR FT upper 9 should be discarded. This patch
adds extra validation to make sure that input RTP traffic encapsulating
AMR payload and OSMUX amr_ft field are OK with regards to that
restriction.
This patch adds the testsuite infrastructure and it populates it
with one test for osmux.
The osmux tests makes sure that:
* We get the same number of RTP messages in the input and the output path.
* The payload of the RTP message is reconstructed correctly.
* The reconstructed timing is correct.
rtp.c:154:26: warning: The left operand to '/' is always 0
frame_diff = (usec_diff / 20000);
~~~~~~~~~ ^
rtp.c:157:43: warning: The left operand to '-' is always 0
long int frame_diff_excess = frame_diff - 1;
~~~~~~~~~~ ^
rtp.c:153:39: warning: The right operand to '+' is always 0
usec_diff = tv_diff.tv_sec * 1000000 + tv_diff.tv_usec;
^ ~~~~~~~~~~~~~~~
rtp.c:153:29: warning: The left operand to '*' is always 0
usec_diff = tv_diff.tv_sec * 1000000 + tv_diff.tv_usec;
~~~~~~~~~~~~~~ ^
4 warnings generated.
Reported by Holger Hans Peter Freyther.
osmux.c:622:20: warning: Value stored to 'osmuxh' during its
initialization is never read
struct osmux_hdr *osmuxh = (struct osmux_hdr *)msg->data;
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Reported by Holger Hans Peter Freyther.
If osmux notices a gap between two RTP packets, fill it with
the last RTP packet seen. Without this patch, 10% of packet loss
is enough to get garbage, with it we get glitches in the conversation
with 30%, and pretty much broken conversation with 40% of it.
CC osmux-test-input.o
osmux-test-input.c:85:2: warning: initialization from incompatible pointer type [enabled by default]
osmux-test-input.c:85:2: warning: (near initialization for ‘h_input.deliver’) [enabled by default]
Use talloc_size not talloc. Should fix:
0xb779401a in rb_erase (node=0x200200, root=0xb779c908) at rbtree.c:230
0xb779401a in rb_erase (node=0x200200, root=0xb779c908) at rbtree.c:230
0xb778ee48 in osmo_timer_del (timer=0x94aacd0) at timer.c:110
0xb778ef65 in osmo_timer_add (timer=0x94aacd0) at timer.c:72
0xb778f03c in osmo_timer_schedule (timer=0x94aacd0, seconds=0, microseconds=64000)
0xb77360ff in osmux_xfrm_input (h=0x94a4280, msg=0x94b8a50, ccid=18) at osmux.c:390
Due to uninitialization batch structures.
Remove these functions:
- osmux_xfrm_input_get_ccid
- osmux_xfrm_input_register_ccid
The ccid will be managed by the BSC and it will be stored in the
mgcp_endpoint structure.
Also adjust all tests and examples using the API.
Rework batching routine to reduce its complexity, updates:
* Now it uses a list of lists to store the messages that will be
batched.
batch list
|
`-> node SSRC=a ---> ... ---> node SSRC=b
| |
msg seq=x1 msg seq=y1
| |
msg seq=x2 msg seq=y2
| |
msg seq=x3 msg seq=y3
| |
msg seq=x4 msg seq y4
This keeps easier the creation of the final batch that is sent from that
data structure.
* We also detect duplicate messages in the batch, ie. messages with the
same sequence are skipped.
Still pending to resolve reordering, corruption and omissions (reliability
is desired).
Between two RTP messages that were extracted from a batch, the
timestamp difference should be 160.
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
Holger Hans Peter Freyther