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>
Because we poke at some of the internals we need to make
sure to maintain the internal state consistent.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I5d9397be391c60f732c89f158d25660e1f32cfac
This shows that rifo_depth is off-by-one for all but the 'empty'
case. It is intended that 'make check' will fail after this commit,
before the next commit with the fix is introduced.
Change-Id: I1be1889800c83d251d17801f31040c137c06a46d
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
Nominally this is of course 8000/s, but this patch should allow us to
verify this in monitoring. Note that the rate_ctr base of course is
"wrong" as it uses the normal system clock, which is much less precise
than the E1 clock of an icE1usb with GPS-DO.
So it really only helps us to compare Rx against Tx or against other
values/counters derived from the TDM clock.
Change-Id: I40e9fb38561410fbf0902b8a390673690a36ea5e
We updated the RIFO depth on every enqueue, let's also do so on dequeue.
Otherwise the figure might be wrong in case of no further received input
frames.
Change-Id: I175f0503e7435c362f35bd8083b785197d9d7338
We called osmo_stats_vty_add_cmds() but we didn't call
osmo_stats_init(), resulting in the user being able to configure stats
reporting, but osmo-e1d would simply never generate the related UDP
packets :(
With this commit, osmo-e1d starts to generate the related packets.
Change-Id: Ic373d3056d044af797664215b08ba0880675ae53
"Counters for each line in e1d 256" is not very useful unless you
know that it's "(intf_nr << 8) | line_nr" and 256 == I1/L0.
Let's set the name string explicitly.
Change-Id: I200e068f1bbc495fb806402877551924beea214e
osmo-e1d automatically uses SCHED_RR already, but for consistency it
actually makes sense to add this, so people can configure the scheduler
priority and/or the cpu affinity this way.
The existing call to SCHED_RR is left in place for backwards
compatibility. The new VTY commands can just override that, if needed.
Change-Id: I1b8021e6dc864af6e301fced427e24c8bb21ca2f
We don't want useless identifiers like 'E1oIP line 5518' but something
that we can understand, like the user account name, or in absence
of that, at least the IP/port.
Change-Id: Ibd98b9606a1d9d5b76d63be83eb3df9e431ab3ad
There use to be a stat_item for the depth of the E1-terminated FIFO, as
in a FIFO this is very easy to determine. When we switched to RIFO, it
was lost. Let's re-introduce it with the approximate depth of the RIFO.
Change-Id: I960cbf196ae930b1b72745b8bfe9c2a21fd53325
This tests exactly one frame before and one frame after what
should be accepted to make sure those are rejected
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I048e1b8c2b918f7ca4b4327b89bf04430a2838bc
You can't have a 'min' and 'max' FN because of the wrap
around this needs to be checked "all at once".
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ie9024f84f79b458248786bca2343a1f8bffb9994
If the line is in channelized mode, only print per-TS information.
If the line is in superchannel mode, only print SC information.
This avoids printing information that is not applicable to the line
mode.
Change-Id: I7b55ae8a5e1d352f90e14342d7f7e82e4848118a
This commit adds 2 new tests:
- too old frames (which should get dropped)
- already correct frames (which shouldn't be touched)
In addition, every test will now be run twice.
Once at frame number 0 and once very close to the wrap-around of
the internal frame counter in order to observe the behaviour.
Change-Id: I930b4361924b2e8bcb566eb7ee64f36e06bc7745
frame_rifo_in would previously return -ERANGE when a frame was written
which was at the edge of the wrap-around of the frame number (because
the maximum value was already across the boundary)
Also: fixed some typos
Change-Id: I88abfc77543d5c64b01f40944b2914e03e57d08f
In the past, we used a FIFO structure (first in, first out) - which
obviously cannot deal with packet re-ordering on the IP side.
This patch introduces a new "RIFO" as a replacement for the FIFO.
The RIFO is able to reconstruct E1 frame ordering by using the
reduced frame number from the TDMoIP messages, at least as long
as the related frame number range is within the current RIFO depth.
Change-Id: I22256870114cb85e4e10932554478be7061e086b
This introduces initial support for operation as OCTOI (Osmocom
Community TDMoIP) server and client operation.
Various features are still absent (user authentication, support for
re-ordered packets), but this version is already able to provide
services to clients with dynamic IP addresses as well as servers.
The bulk of the OCTOI / E1oIP code is implemented as a shared library,
to facilitate the development of other servers and clients in the
future, and also to minimize the impact on the existing osmo-e1d code
base.
More information is available at https://osmocom.org/projects/octoi/wiki
Change-Id: I05f5ff697ca8f7dccdcf89660f12089babfcc92e
When writing the timeslot mode, we must write it in lower-case,
as the VTY parser reading the config file only supports that.
Change-Id: Ic60449a0ba64117a5cf5e4a8e76484e9c955f09f
Sylvain Munaut
Oliver Smith
Pau Espin
Harald Welte
Manawyrm