GitLab

Change-Id: I99d14a399786f060db26dada4721c829789161fa

Change-Id: I068194942d31d8161cc7f400cee743d7889d0724

Change-Id: Id1b893dd7356a98df233de5f65e6a527504fe370

Change-Id: I35042f73302fbfc68b3361906a5db9880a35d4bd

Change-Id: Ie9a105b33acdbd8010bbbfe7a531b00d56430919

Change-Id: I2143ed197ae0e5ab440813c79c332b3126b5384a

Change-Id: Ia335e964c2e2e090054e8897aa64b26296b82ad4

Change-Id: I992b89e67f8ba6d0252ecdb94671466a98d7eadb

Change-Id: Ifd8cfbe842486dddeab206af28049312f2429e4f

Change-Id: I697702cb9b849e3a6c914c751e0d1c8788a5d105

Change-Id: I61c976fea63604d563757add2b40e21b3d038dc5

Change-Id: Ie88ebf492e0e588aa11fa18fb9ffe95a6dda26db

Change-Id: I691cf4dc988b1f703a78d498a72656ba23a7b115

Change-Id: I2a63778ff6a9d9ddfbf78679a07c1bd1e98bd33e

Change-Id: I2c9790719b844a58c732411a365fcd6b62d35a0a

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

Change-Id: I6742e5504cfb827031031e4d8d49a616ab203a94

Related: OS#4438
Change-Id: I41603db8c1286660ad57ac1c78a8fb393a2b080b

Patch-by: ewild, osmith
Related: OS#4070
Change-Id: I30e3bd601e55355aaf738ee2f2c44c1ec2c46c6a
Depends: (libosmo-abis) Ie453fdee8bfd7fc1a3f1ed67ef0331f0abb1d59b

Change-Id: I1cff638664029ef1a592b98cd499e1d8b703ada1

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

Change-Id: I88ba83783ae1d8368990ec30cdc7ecff88884e41

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

Change-Id: I98f337f8f517b98f9b78dc173e5761687609abd8

Change-Id: I0060e2c9772eb5c0293712cb0da7cc0477eb8abd

The config.h files contains HAVE_E1D.

Change-Id: Ib7d2db6703300b7d537c78ad9285948673d8b1d3

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>

Change-Id: I447a2360757fed97ed50f9db1e2efbf2f90e46a0

Change-Id: I287e10ee49a8ac26eef903568b29a3b2abf3b43e

Change-Id: I09c56f59631828ad219a5edd7d95cac8df462c84

Change-Id: If7099f91a3610d61d16e769406ac27f54e7363f3

Change-Id: I36997b31f50fb1e051686a58dac09bc9ed391d17
Fixes: CID#206090

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

Change-Id: I1c730d6d146b365712b28e3d37e038344ea850bc

Change-Id: I83c52c9733852cfebf183819fb36bd634d84bf7d

Change-Id: Ic190daae31936959de8efb5a6de8744c016d5643

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