Jacob pointed out that "free_endp" refers to the memory of
the endpoint being freed. What we want is actually a way to
release an endpoint (and the resource it allocated) or in
the case of the testcase/testapp initialize the data structure
correctly. Introduce two names for that.
In case the sender didn't send a couple of frames we will have
a time gap that is bigger than the accepted delta. Add a new
testcase for this and update the next_time.
Transcoding from GSM to PCMA can lead to the MGCP MGW sending
two PCMA packages with the same sequence number and timestamp.
Once with the encoded audio and once completely empty.
This is because "state->dst_packet_duration" is 0 in most cases
(unless a ptime is forced) and we attempt to encode audio even
if there are not enough samples. The encode_audio return will
return 0 in that case which is not trated as an error by the
mgcp network code.
Handle rc == 0 specially and document the semantic.
The sequence number was read from the wrong place and then
the wrong byte order conversion routine was used so we ended
up wirting 0x00, 0x00 into the patched sequence number. Add
a testcase for that.
When going from a ptime of 10 to 20 a lot of alignment errors
are reported. In fact the alignment check should be done before
and after the transcoding. As this is not possible right now
only do it _after_ the patching.
It took me a long time to figure out that errx just exits and
the test output didn't indicate that the application was exited
early. Use a printf and good old abort in case of a failure.
The GSM handle was never released. This was found using valgrind
and the leak check.
==14933== 752 bytes in 1 blocks are definitely lost in loss record 15 of 19
==14933== at 0x4028B4C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==14933== by 0x4130201: gsm_create (in /usr/lib/i386-linux-gnu/libgsm.so.1.0.12)
==14933== by 0x80517AE: mgcp_transcoding_setup (mgcp_transcode.c:199)
==14933== by 0x8049691: given_configured_endpoint.isra.1 (mgcp_transcoding_test.c:198)
==14933== by 0x8049C11: test_transcode_result (mgcp_transcoding_test.c:328)
==14933== by 0x8049418: main (mgcp_transcoding_test.c:582)
<000b> osmux.c:177 Cannot find endpoint with cid=7
!
<000b> osmux.c:253 Cannot find an endpoint for circuit_id=7
The extra newline and '!' do not provide any extra value and
make reading the output more difficult. Just remove it.
An empty log_info is not enough. We need to make sure that at least
DLGLOBAL is present. Instead of doing that make sure that we have
enough entries.
==26163== Conditional jump or move depends on uninitialised value(s)
==26163== at 0x403B289: osmo_vlogp (logging.c:290)
==26163== by 0x403B3DA: logp2 (logging.c:339)
==26163== by 0x804D027: gbprox_relay2bvci (gb_proxy.c:347)
==26163== by 0x804D3CF: gbprox_rx_sig_from_sgsn (gb_proxy.c:589)
==26163== by 0x804DBFC: gbprox_rcvmsg (gb_proxy.c:685)
==26163== by 0x4052CB0: gprs_ns_process_msg (gprs_ns.c:669)
==26163== by 0x4052F70: gprs_ns_rcvmsg (gprs_ns.c:1053)
==26163== by 0x804BB49: gprs_process_message (gbproxy_test.c:488)
==26163== by 0x804BC4C: send_ns_unitdata (gbproxy_test.c:210)
==26163== by 0x804BDE8: send_bssgp_reset_ack (gbproxy_test.c:243)
==26163== by 0x804B54F: main (gbproxy_test.c:863)
==26163==
The peers are (talloc) children of the GPRS NS. This means the
peers (and the rate counters) are currently being deleted twice.
==23446== Invalid write of size 4
==23446== at 0x403C243: rate_ctr_group_alloc (linuxlist.h:66)
==23446== by 0x4050974: gprs_nsvc_create (gprs_ns.c:209)
==23446== by 0x405320D: gprs_ns_instantiate (gprs_ns.c:1330)
==23446== by 0x804ABEB: main (gbproxy_test.c:666)
==23446== Address 0x4300694 is 52 bytes inside a block of size 784 free'd
==23446== at 0x4029DA8: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==23446== by 0x4041B9D: _talloc_free (talloc.c:609)
==23446== by 0x4043292: talloc_free (talloc.c:578)
==23446== by 0x40532D3: gprs_ns_destroy (gprs_ns.c:1363)
==23446== by 0x804ABD7: main (gbproxy_test.c:660)
Make the llc_default_params structure from which data is initialized
large enough. Otherwise address sanitizer complains with out-of-bounds
reads.
Only SAPIs 1, 2, 3, 5, 7, 8, 9, 11 are defined for GPRS but the
struct gprs_llc_llme includes NUM_SAPIS lle's and they are populated
from the llc_default_params structure.
This adds a test case with several messages to test BSSGP patching.
New messages:
- BSSGP/DTAP Attach Request
- BSSGP/DTAP Attach Accept
- BSSGP/DTAP Routing Area Update Request
- BSSGP/DTAP Routing Area Update Accept
- BSSGP/DTAP Activate PDP Context Request
- BSSGP SUSPEND
- BSSGP SUSPEND ACK
Sponsored-by: On-Waves ehf
This parameter is not used (the methods are always called with an
argument of 1 in the third position). Thus the parameter is removed
completely.
Sponsored-by: On-Waves ehf
The type in the schema is integer but we need to use ulonglong to
read it as otherwise the read will fail.
DBI: -7: The requested variable type does not match what libdbi thinks it should be
Currently the terms 'Routing area code' (RAC) and 'Location area
code' (LAC) are used in several places where 'Routing area
identification' (RAI) or 'Location area identification' (LAI) are
meant in fact.
This patch replaces RAC/LAC by RAI/LAI and 'code' by 'identification'
at these places.
Note that RAI := MCC MNC LAC RAC, and LAI := MCC MNC LAC (see GSM
03.03, sections 4.1 and 4.2).
Sponsored-by: On-Waves ehf
Currently when ftmp_extra is set, a doubled a=rtpmap line is emitted
instead of the fmtp_extra info.
This patch fixes replaces the formerly copied and pasted but not
modified snprintf parameters by the correct ones.
Fixes: Coverity CID 1220873
Sponsored-by: On-Waves ehf
Add tests setting the fmtp_extra field to check the response
generation. This triggers a bug found by Coverity.
Addresses: Coverity CID 1220873
Sponsored-by: On-Waves ehf
Holger Hans Peter Freyther
Harald Welte