When the MNCC socket breaks down we would release all callds but when
there is no remote call the call would be released before
if (call->remote)
...
is being executed leading to a use after free. Fix it by copying the
legs first and assuming the call will be gone after that.
==3618== Invalid read of size 4
==3618== at 0x804A18A: app_mncc_disconnected (app.c:49)
==3618== by 0x804B52D: close_connection (mncc.c:255)
==3618== by 0x804BCFA: mncc_rtp_send.constprop.13 (mncc.c:145)
==3618== by 0x804CC86: check_setup (mncc.c:435)
==3618== by 0x804CC86: mncc_data (mncc.c:795)
==3618== by 0x42FCF94: osmo_fd_disp_fds (select.c:167)
==3618== by 0x804D1F2: evpoll (evpoll.c:92)
==3618== by 0x4205053: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.4200.1)
==3618== by 0x4205478: g_main_loop_run (in /lib/i386-linux-gnu/libglib-2.0.so.0.4200.1)
==3618== by 0x8049AA6: main (main.c:171)
==3618== Address 0x47f3258 is 64 bytes inside a block of size 76 free'd
==3618== at 0x402A3A8: free (vg_replace_malloc.c:473)
==3618== by 0x42E7FD1: ??? (in /usr/lib/i386-linux-gnu/libtalloc.so.2.1.5)
==3618== by 0x804A3FD: call_leg_release (call.c:87)
==3618== by 0x804A186: app_mncc_disconnected (app.c:48)
==3618== by 0x804B52D: close_connection (mncc.c:255)
==3618== by 0x804BCFA: mncc_rtp_send.constprop.13 (mncc.c:145)
==3618== by 0x804CC86: check_setup (mncc.c:435)
==3618== by 0x804CC86: mncc_data (mncc.c:795)
==3618== by 0x42FCF94: osmo_fd_disp_fds (select.c:167)
==3618== by 0x804D1F2: evpoll (evpoll.c:92)
==3618== by 0x4205053: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.4200.1)
==3618== by 0x4205478: g_main_loop_run (in /lib/i386-linux-gnu/libglib-2.0.so.0.4200.1)
==3618== by 0x8049AA6: main (main.c:171)
==3618==
Change-Id: I1889013ed315f896e4295358f6daf76ce523dc2a
The app_mncc_disconnected will be called when the MNCC socket is down
and lead to all calls being released. It directly released the call but
did not stop the MNCC CMD timer. Go through the call release callback.
==3618== at 0x804A18A: app_mncc_disconnected (app.c:49)
==3618== by 0x804B52D: close_connection (mncc.c:255)
This lead to the timer not being removed:
==3593== Invalid read of size 4
==3593== at 0x4305D42: rb_first (rbtree.c:294)
==3593== by 0x42FCB37: osmo_timers_update (timer.c:220)
==3593== by 0x804D1D5: evpoll (evpoll.c:89)
==3593== by 0x4205053: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.4200.1)
==3593== by 0x4205478: g_main_loop_run (in /lib/i386-linux-gnu/libglib-2.0.so.0.4200.1)
==3593== by 0x8049AA6: main (main.c:171)
==3593== Address 0x47f3380 is 232 bytes inside a block of size 272 free'd
==3593== at 0x402A3A8: free (vg_replace_malloc.c:473)
==3593== by 0x42E7FD1: ??? (in /usr/lib/i386-linux-gnu/libtalloc.so.2.1.5)
==3593== by 0x804A3C4: call_leg_release (call.c:83)
==3593== by 0x804A188: app_mncc_disconnected (app.c:48)
==3593== by 0x804B52D: close_connection (mncc.c:255)
==3593== by 0x804BCFA: mncc_rtp_send.constprop.13 (mncc.c:145)
==3593== by 0x804CC86: check_setup (mncc.c:435)
==3593== by 0x804CC86: mncc_data (mncc.c:795)
==3593== by 0x42FCF94: osmo_fd_disp_fds (select.c:167)
==3593== by 0x804D1F2: evpoll (evpoll.c:92)
==3593== by 0x4205053: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.4200.1)
==3593== by 0x4205478: g_main_loop_run (in /lib/i386-linux-gnu/libglib-2.0.so.0.4200.1)
==3593== by 0x8049AA6: main (main.c:171)
Change-Id: I2e8e14b3983f84c9be046bbd96bbcd1e5766993e
Rhizomatica is using FreeSWITCH and we should have an easy way to
test against it. A docker container with exposed ports seems like
the easiest. FreeSWITCH by default is giving us some exmaple numbers:
* 5000 a menu... that allows DTMF
* 9195 an echo test
* 9198 tetris.
The config is copied on top of the default/big config that is
installed. If this PBX should be reached from the outside one needs
to change 127.0.0.1 to the external address and maybe configure the
acl as well to add more CIDRs.
Besides that
make container
make run
Will build it and start the container. Takes a bit of time and requires
docker. With it configure one can see things like:
2017-03-05 15:32:49.913912 [INFO] switch_channel.c:515 RECV DTMF 3:2000
2017-03-05 15:32:50.952752 [INFO] switch_channel.c:515 RECV DTMF 2:2000
Now to test DTMF in the system.
Change-Id: I7f3aa8c81b9e8698df090a05d2e41a41b67d8e3c
gpoll.c:g_poll maps G_IO_PRI (which is POLLPRI) to the errorfds of
the select call. Let's do the same.
Change-Id: I8c9163f7495e0b237bde2d48beffea3b0776a1dd
Related: OS#1934
Even if we have not selected the fd (e.g. fd < 0), initialize revents
to 0. This seems to match gpoll.c:g_poll of glib.
Change-Id: I9e16a6d5a74a204c85808ba67a8f0f7af3045059
It doesn't fix early media yet but brings us one step
closer to it:
The 183 (Session Progress) response is used to convey information
about the progress of the call that is not otherwise classified. The
Reason-Phrase, header fields, or message body MAY be used to convey
more details about the call progress.
Change-Id: Ibf264f251e41c06a7b4839acc0d0853e6400291c
Explicitly set AC_CONFIG_AUX_DIR.
To reproduce the error avoided by this patch:
rm install-sh # in case it was already generated.
touch ../install-sh # yes, outside this source tree
autoreconf -fi
This will produce an error like
...
configure.ac:16: error: required file '../ltmain.sh' not found
configure.ac:5: installing '../missing'
src/Makefile.am: installing '../depcomp'
autoreconf: automake failed with exit status: 1
See also automake (vim `which automake`) and look for 'sub locate_aux_dir'.
Change-Id: I9c96c087bffb41533ef6fb9b1d00bd903d71693e
After libosmocore 55dc2edc89c1a85187ef8aafc09f7d922383231f which outputs
'telnet at <ip> <port>' from telnet_init_dynif(), there's no need to log the
telnet VTY bind here anymore.
Change-Id: I7db7f7a2e61ba676c2712bcc149a5fd5a69b80b2
In case of solely managing the application through the VTY we
want/need to have the application running besides a wrong config
has been entered. SIP will be broken but a user will be able to
see the log message and can fix it.
In preparation of a better show calls VTY command it is of interest
to know which number has been dialed by whom. For that store the
source/dest in there.
MNCC: Change the talloc root context to the call and don't try to
free the strings after calling the routing code
SIP: Use talloc_strdup to duplicate them.
Call: Add null check because the talloc_strdup of the SIP layer
could have failed.
Start with a show call summary that lists simple data about the
current set of calls:
Call(5002) initial(type=SIP,state=CONFIRMED) remote(type=MNCC,state=INITIAL)
Call(5001) initial(type=MNCC,state=PROCEEDING) remote(type=SIP,state=CONFIRMED)
Related: OS#1680
I was focusing so much on the length that I didn't notice the
wrong usage of snprintf. Correct it.
Warning on Ubuntu:
mncc.c:679:3: warning: format not a string literal and no format arguments [-Wformat-security]
snprintf(mncc.imsi, 15, called);
MNCC hold to sip has not been implemented, so let me reject the
request right now. A ticket (OS#1686) has been filed to track
implementing call holding.
Have all release go through a local method first. This way we can
make sure to stop the timer. I have seen something odd (a busy loop
in the RB tree of the timer code) and we can easily avoid having a
timer run on a page of memory that has been "freed".
In case one is using a PBX it might be the easiest just to
call based on IMSI. Add a VTY option to enable/disable this
feature. It can be used to keep the number assignment outside
of the HLR database.
Add NULL check in the case of MNCC disconnect that was missing and
add an assert to show that at this point the other leg must exist.
Fixes: CID#80799, CID#80800, 80801
This will go through the stage of:
* MNCC_CALL_CONF_IND (to which we create a RTP socket)
* then we might receive a MNCC_ALERT_IND
* and finally the MNCC_SETUP_CNF
For the last two we inform the other leg about the progress.
For releasing a MT-Call we will need to send a release request
and then wait for the release confirmation. Add if/else to it.
If this turns out to be too ugly we will be able to create one
MO and one MT leg.
Initiate the setup request that should result in the call getting
all the way to the connected state at some point in time. The device
I test with sadly rejects the call too soon.
The codec negotiation is still a huge todo and the initial version
will be far from perfect. We will use whatever MNCC has decided on
and then see if it is compatible in the end.
Fix releasing of the leg in case it is not routable and make the
differentation if we initiated the invite (send CANCEL) or send
a final error. The error code was randomly picked and once we have
an enum of causes we can decide where to map it to.
Check if the SDP file has any codec potentially supported by GSM.
The topic of codec selection is a complicated one and we will not
support it correctly in the beginning.