The flag that stores the current alarm is not cleared periodically.
Instead it is cleared when the alarm ceases.
Change-Id: Id6cd193c71330c350c27e02b3a692d2c7e0b3fbe
The client may register a callback function to receive events.
Because there is no relation between the connected client and the
interface, all events are broadcasted to all clients that are
connected to the server.
Change-Id: I5ee3268f8349b611c3cf3fa0572dc5eab280ab2e
Whenever the RIFO buffer fill drifts away from its target, it can be
automatically reset and filled to the initial prefill_frame_count value.
The average fill is measured over several seconds. A given deviation
in percent of the prefill_frame_count is used to trigger that reset.
If the deviation is not set (0), this feature is deactivated.
There are two reasons for this to happen: The GPS clock is missing, so
the receiving interface is not in sync with the transmitting interface.
The delay changes significantly, due to congestion on the path between
both peers. (poor internet connection)
Change-Id: Id7ccbfbdb288990c01f185dec79a1022a68b4748
It seems that in some circumstances, an ISO IN transfer can be
truncated by the bus / host. In such situation we'd currently pass
a non-modulo-32 length to the mux_demux (deframer) code, and it ASSERTs
on that. Let's try to handle this more gracefully by substituting
random garbage and letting higher layers deal with massive bit errors.
Related: OS#5490
Change-Id: Ic453325b93b0e12727625a1495a948d96df4b542
This new mode (can be enabled per account) will force the E1OIP
protocol to always send all timeslots, i.e. not do any of the
suppression of timeslots that do not exhibit any change to the
previous E1 frame.
Change-Id: I6d17d3829b2c1c62e701a1d8c021d93d93593613
When the socket is closed due to a connection loss, we currently use
close(). This is not enough since this will not remove the file
descriptor from the select loop. Let's use osmo_fd_close.
Related: OS#5983
Change-Id: I702b944baf2ebbcc84b6a211e245a4a41627bde6
When osmo-e1d is terminated the socket file descriptor on the client
side will get permanent POLLHUP events. This means that the registered
callback gets called with flags OSMO_FD_READ but the received data will
be of length zero. We must detect this situations and close the file
descriptor on connection loss. Otherwise we would get called over and
over again in an endless loop, resulting in 100% CPU usage.
Related: OS#5983
Change-Id: I3e1a29a9701a9432f58ef7cfedc32c916203017a
The function prototype for osmo_e1dp_client_destroy has a different
parameter name in its signature in proto_clnt.h than in prto_clnt.c,
let's rename it so that both are coherent. (srv -> clnt)
Change-Id: I8bd4fbdf2bda332870da1b915a7898c396a85b0f
DAHDI trunkdev is a newly-introduced 'virtual trunk' character device
which is used instead of a real hardware driver. This means that an
application (such as osmo-e1d) can implement a virtual E1 trunk and
receive and transmit E1 frame data which is exposed to DAHDI users
just like the data from a real physical E1 span.
In order to build DAHDI trunkdev support into osmo-e1d, you will need
a special fork of dahdi containing the required support, currently
the laforge/trunkdev branch of the following repository:
https://gitea.osmocom.org/retronetworking/dahdi-linux
Change-Id: Ib15a7313fcd63e1ed9f2f5b349df967bc4335ec2
Fix that the file only got installed to /usr/share as example, but not
to /etc/osmocom in the rpm packaging.
Related: OS#5817
Change-Id: I4ffa23f7ab26b7ed3cba04aed4f57eeaa3edca31
Adjust OSMOCONF_FILES, so only osmo-e1d.cfg of the examples gets
installed to /etc/osmocom/. All other examples still get installed to
/usr/share, as it is intended.
Related: OS#5817
Change-Id: Ic449b7d38ed50add0164f056574d4da47530eb49
If we actually expect 3rd party applications to use libosmo-e1d to talk
to osmo-e1d, we'd better add some basic documentation on how this API
shall be used.
Change-Id: Ib4a97045bca276fbd3892f801898a436de7dc39b
This likely means it's not an e1-tracer after all, or it's an old
firmware that doesn't yet expose the e1d-compatible USB configuration.
Related: OS#5734
Change-Id: If5a9bc20084d84885d5d97b4f982e94801612d24
This exposes the existing capability of force-opening a timeslot via a
command-line argument.
Related: OS#5735
Change-Id: Ieefc89f2e48e9124ae744a587739ff3948110944
This doesn't work, as the mux_demux.c code doesn't pass the TS0 bitstream
to users anyway. So let's reject clients attempting this.
Change-Id: Idb2d20da7de72dad38ae2fccdd7630677d0f0cc8
Recent work on the e1-tracer firmware is introducing a set of USB
descriptors (as configuration 2) that are mostly compatible to how
osmo-e1d talks to icE1usb.
The main difference is that there's only one ISO IN endpoint per USB
interface, and no ISO OUT or ISU FB endpoints. So we introduce some
minor adjustments here to accommodate that.
Related: OS#5733
Closes: OS#5734
Change-Id: I855e18c0f229bd473123f96303e60ab2de90677f
If a line is not auto-created, there is no point on claiming the
matching interface and even less point setting the alt setting that
will try to use USB isoc bandwith.
With this you can no use only line 1 and not line 0 of a ice1usb
for instance. While previously it would still "enable" line 0 and
then line 1 would fail because on BW issues most of the case.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Iea5d72272f11875e7a32c78b60c188590deda831
This can happen if the specified device in the config isn't plugged
in for instance, no line is created ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I594463591f2945a04ccd708f16788034cc1dfc57
This call takes its argument in wValue rather than as payload
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ibeebe3184a4744bd0cd9f5a19db84c12fab18806
Harald Welte
Andreas Eversberg
Andreas Eversberg
Pau Espin
Oliver Smith
Philipp Maier
Sylvain Munaut