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
When we have multiple interfaces, we cannot simply use the line->id
as rate counter group index, but should use a combination of interface
id and line id.
Change-Id: I515c1f39285489845f88c3403ebf16835571e154
What we are passing is not the [underlying] size of the buffer, but
the length of the valid data in them.
Change-Id: I8ce91527351a56c103bd077c9565be2a81d175ac
This adds support for monitoring the GPS-DO that is built-in to the
icE1usb device. It assumes a very recent firmware with GPS-DO control
moved to a separate USB interface, i.e. after osmo-e1-hardware.git
Change-Id Icd6555a14896c38626fb147b78af44ff719f2254 is merged.
Change-Id: If5e2a6b2dae0290ce3186009e68f618049ebf5ff
So far, osmo-e1d automatically opened all compatible icE1usb devices
and all E1 lines on those interfaces. Let's allow for 'interface' and
'line' configuration in the VTY. USB devices can be identified by
their serial number string.
If a given device (== E1 interface) has a VTY configuration, then only
those E1 lines with VTY configuration opened.
For each Line (icE1usb or vpair), the mode (channelized/superchannel)
can also be set via VTY.
Change-Id: I89b57b688b68901f87d9683ab9294772ee747d77
Closes: OS#5400
if we don't call rate_ctr_init(), the rate counter internal timer will
not tick,a nd we will never get the per-s/per-m/per-h averages.
Change-Id: Ib5b66c72079330ac161756bcf562d27536d7ce44
We either have to bring osmo-e1d in line with other osmocom projects,
or we'd have to disable the linter in jenkins.
Change-Id: I74ab20b22118d471dcdb60d1b9681ab62eb13d51
There is non negligible time between the moment init_timeslot is
called and the moment when we get the first RX (which is when
we start sending out data at the same rate we RX it). And those
1024 byte were borderline not enough to not underflow.
By delaying the 1024 byte pre-fill until we get the first RX,
we ensure the time that pre-fill covers is more consistant and
less dependend on whatever the app/scheduling does during the
init phase.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ic1c93fd138073a75830dc16bb41c4541e68eef90
Until the remote side sends the first byte, we send fill
data since it can take it some time after the mode change
and the file descriptor is open for data to show up.
Previously due to a bug, the warning about short read was
not printed, but now that it's fixed, you get a bunch of
fairly "useless" warning at the beginning of the timeslot.
This fixes that since reported data by _e1_tx_raw is "faked"
until the pipe is active. (Fill data is actually added upstream)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Iaa6268e9b4a7bce5ea3027a29c48c147499373be
No functional changes, just making things a bit more organized
for the next patch adding an _e1_tx_raw.
The order after the patch is :
_e1_tx_hdlcfs
_e1_ts_read
_e1_line_mux_out_channelized
_e1_line_mux_out_superchan
e1_line_mux_out
_e1_rx_raw
_e1_rx_hdlcfs
_e1_ts_write
_e1_line_demux_in_channelized
_e1_line_demux_in_superchan
_e1_line_demux_in_ts0
e1_line_demux_in
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I2ced3a5ba3cf3cc1f212d8f3e46cfefa15e4af0c
A lot of them are related to signedness or type range limitation.
A lot are not actual issues and work find in practice, but a few
lead to actual bad behavior.
This makes all the conversion explicit to mark intent.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I992b9bc51659e85966651b1146091501b8f149f5
Go with -Wextra but removing some of the obnoxious options it brings with
it.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Iaafd35ba39e272d5900b31b14d2651e0ecb8a84a
Newer descriptors have the max packet size set to 3 to save on
isochronous bandwidth.
By specs, the feed back endpoints transfer are 24 bits anyway,
so no point is using anything larger.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I09e259db539e62571fd17fc16ffaa317564ba257
In osmo-e1-hardware.git Change-Id Ic4f57cf79bd32cf75f81ef3073cb8d4a2d1857d8
we added support for passing RAI (remote alarm indication) as a flag via
the USB interrupt messages; let's add support for this here.
osmo-e1d already internally parses TS0 to determine the same
information, and we have to keep this for backwards-compatibility with
older firmware builds. But maybe at some future point we can remove
our own TS0 scanning code here and rely on the USB device to inform
us about remote alarms.
Change-Id: Ie1994968e792c37f9272b9854547db95a41cab5b
Some time ago we added various error counters, but for two of them
we missed to actually ever increment them at all.
Change-Id: Ieb83a2e2e83e334c543bee83726f04f83b19227a
We just found a bug in icE1usb (likely firmware) which was hard to find
as there was zero notification from osmo-e1d that it actually never
received any data from the icE1usb hardware/firmware anymore.
Change-Id: Id22e4110b9067f50b1818eb12295b2d4eb9cdc12
This avoids truncation and the following error message when operating
in HDLC-FCS mode:
<0001> mux_demux.c:91 (I0:L0:T16) Truncated message: Client tried to send 320 bytes but our buffer is limited to 264
Change-Id: I836d8b98ce5b831b0498c4650263ec3b3d4f2c45
Harald Welte
Sylvain Munaut
Manawyrm
Oliver Smith