<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
Currently, if there is no SDP data in the MGCP message received from
the net, the fields containing audio encoding information are not set
in net_end. So in recvonly mode transcoding would not be set up
correctly.
This patch changes the implementation of the code handling CRCX and
MDCX to use the codec signalled in the MGCP local connection options
(field 'a:') if there isn't any SDP data. This is only halfway
negotiation, because the codec is used blindly and not matched
against the supported ones.
Sponsored-by: On-Waves ehf
This patch moves the files relevant to transcoding from
src/osmo-bsc_mgcp to src/libmgcp and src/include/openbsc. Makefiles
and include directives are being updated accordingly.
Sponsored-by: On-Waves ehf
The current transcoder implemenation always does a 1:1 recoding
concerning the duration of a packet. So RTP timestamps and sequence
numbers are not modified.
This is not sufficient in some cases, e.g. when the BTS does only
allow for a single fixed ptime.
This patch decouples encoding from decoding and moves the decoded
samples to the state structure so that samples can be combined or
drain according to the packaging of incoming and outgoing packets.
This patch incorporates parts of Holger's experimental fixes in
0e669e05^..9eba68f9.
Ticket: OW#1111
Sponsored-by: On-Waves ehf
This patch implements audio transcoding between the formats GSM,
PCMA, L16, and optionally G.729.
The feature needs to be enabled by using the autoconf option
'--enable-mgcp-transcoding'. In this case mgcp_transcode.c will
be compiled and linked to osmo-bsc_mgcp, and the transcoding
functions provided will be registered as processing callbacks.
If G.729 support is required, libcg729 needs to be installed and
'--with-g729' must be passed to ./configure.
Ticket: OW#1111
Sponsored-by: On-Waves ehf
Don't show media related lines if the payload type has not been set.
Don't show a 'a=rtpmap' line if the audio_name has not been set.
This patch unifies the SDP generation of create_response_with_sdp()
and send_msg().
Sponsored-by: On-Waves ehf
This patch adds the get_net_downlink_format_cb() callback to provide
payload_type, subtype_name, and fmtp_extra suitable for use in a MGCP
response sent to the network. Per default, the BTS side values are
returned since these must be honoured by the net peer when sending
audio to the media gateway (unless transcoding is done).
Sponsored-by: On-Waves ehf
This patch adds the fields channels, subtype_name, and audio_name to
the struct. The field audio_name contains the full string that has
been used for the last part of a SDP a=rtpmap line. The others contain
decoded parts of that string. If no a=rtpmap line has been given
(e.g. because dynamic payload types are not used), values are
assigned when the payload type matches one of the predefined ones
(GSM, G729, PCMA).
The patch also moves the audio_name parsing code to a dedicated
set_audio_info() function.
Sponsored-by: On-Waves ehf
This patch adds the callbacks rtp_processing_cb and
setup_rtp_processing_cb to mgcp_config to support arbitrary RTP
payload processing.
Sponsored-by: On-Waves ehf
Currently LLC parsing is part of gprs_llc.c which needs large parts
of the SGSN code parsing to fulfill its link dependencies.
This patch moves the functions that just do plain parsing, dumping,
and FCS computation to a different file to avoid these dependencies
if LLC stateful processing is not needed. It also exposes
struct gprs_llc_hdr_parsed and enum gprs_llc_cmd publically.
Sponsored-by: On-Waves ehf
The code currently uses an encoded sequence of (hex) 10 20 30 40 50
60 as RAI, for which no bijective mapping to the set of
representations MCC-MNC-LAC-RAC exists.
This patch changes the hard-coded RAI to 11 22 33 40 50 60 which maps
to 112-332-16464-96 (and vice-versa).
Sponsored-by: On-Waves ehf
The patches were posted to the ML but didn't receive review
there. At the time I merge the change I did a Location Updating
Request and the channel was released in a successful way.
In case we receive ERROR INDICATION and CONNECTION FAILURE we only
want to RF Channel Release the lchan once. This code is more simple
and should work as reliable as the previous commit.
When we receive an ERROR INDICATION and CONNECTION FAILURE we
might call rsl_rf_chan_release multiple times. The channel release
handling is still a bit messy and there too many paths that lead
to the call.
1.) In case we receive an ERROR INDICATION for SAPI=3. A RLL
error signal will be emitted that leads to the release of the
channel through the SMS code in case of the NITB. The call to
rsl_rf_chan_release might be a double release.
2.) In case a CONNECTION FAILURE is received when the release
process has already been started we would unconditionally
call rsl_rf_chan_release as well.
Because the lchan state is changed by the callers of the
rsl_rf_chan_release we can not move the state checking into this
code but need to do it in the caller. The issue was seen in a trace
from Rhizomatica and I created the DoubleRelease.st to re-produce
the issue and verified that we have no duplicate RF Channel Releses.
The other option would be to introduce a new state to track
the release process and see if we have already released SAPIs
deactivated the SACCH or such. We can not simply look at these
as for a channel that fails to activate they will be null already.
Looking at the code it seemed possible that a channel would
transition from BROKEN to NONE. Or worse from NONE to BROKEN.
Start the timer _after_ the channel has been released.
Make it possible to inform local CTRL connections about some state.
The TRAP will be only sent to local connections. The notification
text may not contain spaces.
Use the right size for scanf.
=================================================================
==6106== ERROR: AddressSanitizer: unknown-crash on address 0xbffff4b0 at pc 0xb69d87fd bp 0xbffff248 sp 0xbffff21c
WRITE of size 65 at 0xbffff4b0 thread T0
#0 0xb69d87fc (/usr/lib/i386-linux-gnu/libasan.so.0.0.0+0xa7fc)
#1 0xb69d9239 (/usr/lib/i386-linux-gnu/libasan.so.0.0.0+0xb239)
#2 0xb69d92d6 (/usr/lib/i386-linux-gnu/libasan.so.0.0.0+0xb2d6)
#3 0x804f151 (/home/ich/source/gsm/openbsc/openbsc/tests/mgcp/mgcp_test+0x804f151)
#4 0x80531e8 (/home/ich/source/gsm/openbsc/openbsc/tests/mgcp/mgcp_test+0x80531e8)
#5 0x8051e6f (/home/ich/source/gsm/openbsc/openbsc/tests/mgcp/mgcp_test+0x8051e6f)
#6 0x8049b0a (/home/ich/source/gsm/openbsc/openbsc/tests/mgcp/mgcp_test+0x8049b0a)
#7 0x804bd9e (/home/ich/source/gsm/openbsc/openbsc/tests/mgcp/mgcp_test+0x804bd9e)
#8 0xb6778a62 (/lib/i386-linux-gnu/i686/cmov/libc-2.18.so+0x19a62)
#9 0x8049330 (/home/ich/source/gsm/openbsc/openbsc/tests/mgcp/mgcp_test+0x8049330)
Address 0xbffff4b0 is located at offset 416 in frame <parse_sdp_data> of T0's stack:
This frame has 8 object(s):
[32, 36) 'audio_payload'
[96, 100) 'payload'
[160, 164) 'channels'
[224, 228) 'ptime'
[288, 292) 'port'
[352, 368) 'ipv4'
[416, 480) 'audio_name'
[512, 576) 'audio_codec'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are*
This addresses an ASAN issue where the request was already deleted
by our callback function.
(gdb) where
#0 0xb69e7810 in __asan_report_error () from /usr/lib/i386-linux-gnu/libasan.so.0
#1 0xb69e0aff in __asan_report_store4 () from /usr/lib/i386-linux-gnu/libasan.so.0
#2 0x0804ea64 in subscr_send_paging_request (subscr=subscr@entry=0xb5103cb0)
at gsm_subscriber.c:212
#3 0x0804edac in subscr_get_channel (subscr=subscr@entry=0xb5103cb0, type=type@entry=2,
cbfn=cbfn@entry=0x804969d <subscr_cb>, param=param@entry=0x2342) at gsm_subscriber.c:246
#4 0x080498f7 in main (argc=1, argv=0xbffff804) at channel_test.c:77
Breakpoint 3, subscr_paging_dispatch (hooknum=hooknum@entry=101, event=event@entry=200,
msg=msg@entry=0x1323, data=<optimized out>, data@entry=0x8063900 <s_conn>,
param=<optimized out>, param@entry=0xb5103cb0) at gsm_subscriber.c:126
126 llist_del(&request->entry);
(gdb) b llist_del
(gdb) bt
#0 subscr_paging_dispatch (hooknum=hooknum@entry=101, event=event@entry=200,
msg=msg@entry=0x1323, data=<optimized out>, data@entry=0x8063900 <s_conn>,
param=<optimized out>, param@entry=0xb5103cb0) at gsm_subscriber.c:126
#1 0x0804e8a9 in subscr_paging_cb (hooknum=101, event=200, msg=0x1323,
data=0x8063900 <s_conn>, param=0xb5103cb0) at gsm_subscriber.c:187
#2 0x080497e9 in paging_request (bts=0xb5b03e70, subscriber=subscriber@entry=0xb5103cb0,
type=2, cbfn=cbfn@entry=0x804e881 <subscr_paging_cb>, data=data@entry=0xb5103cb0)
at channel_test.c:51
#3 0x0804ea39 in subscr_send_paging_request (subscr=subscr@entry=0xb5103cb0)
at gsm_subscriber.c:207
#4 0x0804edac in subscr_get_channel (subscr=subscr@entry=0xb5103cb0, type=type@entry=2,
cbfn=cbfn@entry=0x804969d <subscr_cb>, param=param@entry=0x2342) at gsm_subscriber.c:246
#5 0x080498f7 in main (argc=1, argv=0xbffff804) at channel_test.c:77
(gdb) q
In ae1997248c the handwritten tokenizer
was replaced with strtok_r. As part of this change the structural
checking of MGCP parameters was stopped. This means that a code like
"line + 3" might access beyond the first NUL and be possibly behind
the msgb. Manually add size checking again. Manually jumping to the
error label is not possible anymore as it has been removed. The result
is that invalid lines will be skipped. This is matching the general
approach by the IETF RFCs to be permissive in data being received.
Holger Hans Peter Freyther
Harald Welte