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
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
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
Because we want to handle older firmwares too, we need to excepect
we might get a smaller structure !
(We can't get a larger one since the wLength we send is limited to
the structure we know)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I4222bf22267f8343abf1e97546111ceb1c299846
Found by gcc (Debian 10.2.1-6) 10.2.1 20210110, which fails the build
with --enable-werror because of this.
Change-Id: Ib717df376a4b414f787168c2c632f04f0c51271b
This adds VTY commands at the 'account' level to configure those
settings. They will only become active on the next [re]connect
of the line.
Change-Id: Ic455ef0ef82867db512e2ffdff24d9dd42d47eeb
As soon as an OCTOI connection gets into ACTIVE state, send a
ECHO_REQ every 10s and compute the RTT at the time of receiving
the response.
Contrary to the initial idea, the stat item contains the RTT (round trip
time) measured in micro-seconds. Changing this is not a problem as so
far the RTT was always reported as '0', and 0ms == 0us.
Change-Id: Id331319bff1cf6896fee37acc45846a2491ca92d
If the caller specifies zero-length data or a NULL pointer, don't
attempt to call memcpy() on that.
Change-Id: I5f5ed937643162d6ef6ce0cf2908432c007943c1
Let's allow setting IP DSCP and socket priority via the VTY.
Note that you must still manually add a kernel egress QoS map from
socket priority to IEEE P802.1p PCP (Priority Code Point) like this:
ip link set dev eth0.7 type vlan egress-qos-map 0:0 1:1 5:5 6:6 7:7
This will create 1:1 mappings for socket priorities 0, 1, 5, 6 and 7 to
the respective IEEE PCP. A higher PCP typically means higher priority,
where voice is traditionally using "5".
Change-Id: Ic5a6c5a0ec67beb40be4ca95326aca5072a28958
This adds "e1oip:e1t_ts_active" and "e1oip:e1o_ts_active" to show
which timeslots are active (i.e. which are transmitting data in the
IP protocol).
Change-Id: I6858e0773a348193bb4839c247294cef5ab4df5f
This adds a new [rate] counter "e1oip:connect_accepted" that increments
every time the connection is accepted for both server and client role.
The rate is not really interesting, it's more the total absolute
quantity that's interesting. Plotting the delta will give us spikes
whenever the connection is re-established.
Change-Id: I8baac768289f7e01d943f5205afa824f367a3a61
We have to issue the OCTOI_CLNT_EV_REQUEST_SERVICE event to the FSM
only after it has switched back to INIT state.
Change-Id: I1d913a8153adaf87b2c3dadcf98382ff0b9fc2fb
If we are permanently overflowing the RIFO in IP->E1 direction, the
peer clock is consistently faster than our E1 clock. There's no smart
way to recover from this. Log an error and disconnect.
This is the opposite situation from the high RIFO UNDERFLOW situation
whose logging + disconnect handling was added in
Ie3fffa1c1c20962b40320c8cc088c140b8d64e77
Change-Id: Iecd294b0174c9a0572df3dad612cb4efbd9cde07
This typically happens if the remote IP peer is transmitting at a faster
rate than the E1 side is consuming. Let's add a way to monitor it.
Change-Id: Ie0e8bb2f5d2ae4256952f6bf69e514d5c2627a76
This indicates that this is counting an E1-originated overflow of the
OCTOI transmit FIFO, which should never happen unless your system is too
slow to periodically schedule the related timers in the code.
Change-Id: I0af6a2847c8356b011bcff5cc4f5d909c574ea21
A real _underrun_ happens if the RIFO is empty (depth == 0)
and should be counted different from a mere frame substition
due to packet loss.
Change-Id: I5448430b09ec10a16decdfd0a4a40850fe2ed1a6
We use the 'correct' math in frame_rifo_depth now so the
count is accurate down to zero.
We need to fixup the logic that drags the 'write pointer'
(last_in_fn) along when reading from an empty FIFO.
We also need proper init (which was missing alltogether
beforehand).
Change-Id: I088f181e74358eb2c96a7aab7a7c875b9276d980
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This situation is the result of the peer clock being continuously
too slow compared to the local clock, leading to RIFO underruns at
[virtually] all of the 8000/s E1 frames. As the current code doesn't
recover from this, we might as well disconnect and re-start for
recovery.
Change-Id: Ie3fffa1c1c20962b40320c8cc088c140b8d64e77
This was not an issue with the original FIFO code, which dynamically
substituted frames and always created the minimal required backlog.
The RIFO can by principle not operate this way, so we really have to
prime / pre-fill it with a number of TDM frames. That initial fill
level has to be sufficient to cover RTT jitter of the OCTOI link as
well as clock drift between (GPS synced) receiver and transmitter.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I3a4b3846d3dbd1c99989e994ad95e609f2757219
For both OCTOI client + server FSM, whenever we enter the ACCEPTED
state (we disconnect), let's reset the RIFO/FIFO state. This makes
sure no left-over frames from some earlier connection are present,
and also ensures our initial frame number expectations are correct.
Change-Id: I9e721b5dbf22728cb2361ed121d12def7016dcc2
Only frames withing a certain window are even accepted for processing
the rest is dropped since it could corrupt our state.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I25b2e150d924aa8c714b766cb92e9e23e67cfa4c
It is interesting from a monitoring point of view to be able to
correlate the GPSDO state with other performance counters we export.
While each GPS-DO only exists once per icE1usb, we still export the
state per line, to make it easy for external monitoring to have one set
of counters per line.
Change-Id: I1f98610b7c725146a3f016a8737440be5baae858
Pau Espin
Harald Welte
Philipp Maier
Christoph Lauter
Sylvain Munaut
Oliver Smith