In commit Ia082b9fddf03d02afd007825a1588a3ef0dbedae we switched
from 'uint8_t *' to 'const ubit_t *' - change the test case
accordingly.
Change-Id: I7d24b891a21e6e485738ddf4a302583579b012d5
the subchan_demux code predates ubit_t; let's use it to clarify
certain pointers refer to arrays of unpacked bits.
Change-Id: I944f05473954920d57e12d5514cf928fc78f2ea4
This command is also usable at run-time to dynamically
enable / disable e1 tracing on all active lines
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I0b4251702aecd6721b9d63c320351ef6cb513454
This will update the pcap fd in all open lines and close
the previous one (if applicable).
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I5c7dd740ba0a90b40c69a53b3dcc9d6d6a98f660
As pointed out at https://github.com/libexpat/libexpat/issues/312
libtool does not play nice with clang sanitizer builds at all.
For those builds LD shoud be set to clang too (and LDFLAGS needs the
sanitizer flags as well), because the clang compiler driver knows how
linking to the sanitizer libs works, but then at a later stage libtool
fails to actually produce the shared libraries and the build fails. This
is fixed by this patch.
Addtionally LD_LIBRARY_PATH has no effect on conftest runs during
configure time, so the rpath needs to be set to the asan library path to
ensure the configure run does not fail due to a missing asan library,
i.e.:
SANS='-fsanitize=memory -fsanitize-recover=all -shared-libsan'
export CC=clang-10
ASANPATH=$(dirname `$CC -print-file-name=libclang_rt.asan-x86_64.so`)
export LDFLAGS="-Wl,-rpath,$ASANPATH $SANS $LDFLAGS"
Change-Id: Ia3644168bfea13bda5e09b8bfe1d2c65abd32ad7
ortp >= 0.24.0 doesn't differentiate between SO_REUSEADDR and
SO_REUSEPORT, and has both enabled by default. The latter means that
we can end up with non-unique port bindings as we will not fail to
bind the same port twice.
This should have caused visible problems not only when operating multiple
osmo-bts on one machine (rare), but also with a single osmo-bts. Once the range
(default 16384-17407 ) wraps, there is a risk of new sockets (for new cals)
colliding with old ones. As two ports (RTP+RTCP) are used per call, this means
every 512 voice calls we expect the BTS to wrap. And from that point onwards
there's a risk of overlapping with previously allocated sockets.
Change-Id: I4fc9eee561c7958c70c63b4ffdc6cb700b795e28
Closes: OS#4444
So far, the e1d input driver only contained code for LAPD signaling
slots, let's extend it with support for all the other slot types, as
well as support for run-time re-configuration.
Change-Id: I53369004145681bf9178543fe407dfc75e4ae63a
Let's not print an error at program/library start time if osmo-e1d
cannot be reached. This error is confusing to everyone who may
have a libosmo-abis with e1d support compiled in, but who is not
(currently) using any lines via this driver, but others drivers.
Change-Id: If0d033f8a2ab4f0e72549a811ffccc66b91fb0a8
This way we can support more than one E1 line via osmo-e1d. As
neither mISDN nor DAHDI distinguish between mutliple cards of single
ports vs. multi-port cards, we havee to map both interface + line number
into a single uint8_t.
Change-Id: I3b6975624a0155a68d2c67bfdbc1fb751fb50b13
It's optional for an input driver to provide this function, and e.g.
mISDN doesn't provide it, either.
Change-Id: I56ed4244121f2019ece80d15bd07d5a8ce958273
The file decscriptor 'except' handling was only added in the DAHDI
input module as the DAHDI kernel side is actually using those. I
don't think we can even use this in any way over unix domain sockets.
Change-Id: I718629179181a1de3b82e23447549f593046d91f
osmo-e1d is part of the Osmocom 'software defined E1 interface,
which consists of a USB device for the actual E1 hardware interfacing,
and a daemon (osmo-e1d) implementing a libusb-based driver.
This commit adds initial support for talking to osmo-e1d using
the related libosmoe1d library. You need to use '--enable-e1d'
at configure time to enable it.
Change-Id: Ia0431c124e3b5b4108aee7b109d8c4bb0d8b45d4
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
libosmo-abis was built with DAHDI support, if the related header files
were present at built time, and without if not. This kind of automagic
enabling/disabling of features is wrong. Let's require DAHDI support by
default, and force the user to take a conscious decision by using an
explicit --disable-dahdi if he doesn't want it.
At the same time, update debian/control to list dahdi-source as build
dependency.
Change-Id: Id9f7f063e7ca9e3ab4aa96fc93f243caf50fb66a
Closes: OS#4248
It appears that opening "/dev/dahdi/channel" and using
ioctl(DAHDI_SPECIFY) is possible at least since dahdi 2.4 (from 2010),
and opening "/dev/dahdi/%u" has been deprecated ever since. One
advantage of the new interface is that you can use channel numbers
larger than 250, which is quite easily possible if you have more than
eight E1 lines on a system. It also makes libosmo-abis work on systems
where there are no udev rules for creating the legacy device nodes.
Change-Id: Id6c8f27d7ae948b50e9cf5a38f039d782ff78e1d
When closing a link which failed on open,
ipa_server_link_close() would crash it when calling osmo_fd_unregister.
Change-Id: I672d4de25464c3829b08aff26b1a6d4ad92e7684
The new and improved fsm supports multipe use cases:
1) plain old ipa server/client operation
2) ipa client/server operation with custom send callback (i.e. to bypass
the tx queue)
3) all of the above + custom timeout callback
4) fully generic operation that will pass opaque data to the callbacks
The current code will always kill the fsm and deallocate it upon
timeout, so the timeout callback will now return a value: 1 means the
fsm will be automatically terminated, 0 means no action, which allows
manually stopping/starting the fsm to reuse it.
Change-Id: Ie453fdee8bfd7fc1a3f1ed67ef0331f0abb1d59b
The patch sets TCP_USER_TIMEOUT to the same timeout value,
since keepalive only applies to idle connections, but we obviously want
to fail as fast as possible even if there is data to send and it's not
acked.
Change-Id: I5e7425958472aa5d758e09bfbefc7d7d37bf6f5f
If we receive an OSMO_IPA_KA_E_STOP in INIT state, we are trying to
re-enter INIT, which is not permitted as per the FSM definition.
Adding this permission avoids the below error message from hitting the
logs every time this happens:
<0003> input/ipa_keepalive.c:158 IPA-KEEPALIVE(server)[0x612000000520]{INIT}: transition to state INIT not permitted!
Change-Id: I8db2f2e708fc4fbb81f5019973098a80e8f540d2
We had the allstate_action function registered, and that function
implemented handling of OSMO_IPA_KA_E_STOP. However, the
allstate_event_mask was not set, rendering this functionality
inaccessible.
Change-Id: I83fd991bdacb7bab794878e47c7797fecf8b9286
The IPA keep-alive FSM code takes care of periodically transmitting
and IPA CCM PING and expecting an IPA CCM PONG in return.
Change-Id: I2763da49a74de85046ac07d53592c89973314ca6
The bound RTP socket will wait for incoming RTP packets and as soon as it
sees one, will 'connect' to it, so all replies will go to that sources and
incoming messages from other sources will be discarded. This obviously only
works once.
Change-Id: I5b54ca4296901fcf37794faf29e0b2acca27bd1b
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This ensures that the rpath of the generated binaries is set to use only
the just-compiled so-files and not any system-wide installed libraries
while avoiding the ugly shell script wrapper.
Change-Id: Idd458471069ef8912704cc7602c6e8c71c0b62be
In some situations, the user code called by the closed_cb call-back
might be tempted to call itself ipa_server_conn_destroy(), which would lead
to a double-llist_del during osmo_fd_unregister() and also a subsequent
double talloc_free(). Let's prevent such misuse by existing early in
such situations.
Change-Id: I0fef264ed5b4218906cdbca243ffa11b891025c6