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
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
This allows us to reliably detect client disconnection at least in
the case of RAW mode channels. Even with this patch applied, e1d
still fails to reliably detect client disconnect on HDLC-FCS channels.
Change-Id: Ifb8b91d39b394f9c10c859f3adac85ea47b7653f
There was some wrong ordering in config_write_e1d() regarding
resolving the vpair 'peer' devices. We can only call
e1d_vpair_intf_peer() _after_ we have established that the
given interface actually is of type VPAIR.
Assert failed intf->drv == E1_DRIVER_VPAIR vpair.c:96
Change-Id: If494d77ed1df5cda655d3b4a60868154dc2b355e
osmo-e1gen is a program that re-uses large parts of osmo-e1d, but whose
main purpose is to generate a variety of error conditions in order to
test a remote E1 implementation.
Instead of using the automatisms of the icE1usb transmit IP core, it
switches it to transparent mode and uses a host-software based E1 framer
"osmo_e1f", over which we have more control than the firmware.
Change-Id: I53a86d6730eb76a9cff9eb3f4786139015c91230
The remaining intf_line.c really only manages the data structures.
This is useful for building other programs than osmo-e1d, such as
an upcoming E1 test utility called osmo-e1gen which will also use
the USB interface and icE1usb hardware, but not any of the mux/demux/ctl
code.
Change-Id: I1ceaea85a15e2fae1d2e041173be9d758c6d0b78
Experimentally this has shown a much lower probability of
USB related overruns/underruns, at least on my system.
Change-Id: I5c73b29462a4870d3c86fd7f46e1574daae6f93f
prior to this patch, the configured vpair interfaces would not
be saved to the config file on 'write file'.
Change-Id: Iff6551318534a3717c374060082147f17b925a21
Align the behavior of osmo-e1d with that of DAHDI: If a timeslot is
opened once, it cannot be opened again by anyone until it is closed
by the current owner. This way we'd have the same failure semantics
in DAHDI vs. osmo-e1d, which is very useful in case of misconfiguration
when osmo-bsc + osmo-mgw would "fight" over a timeslot.
Add a osmo_e1dp_client_ts_open_force() function that allows to override
and get back the original behavior.
Closes: OS#4654
Change-Id: Ib25adf827ec41e74de15e0e4fdcfc9bcc9a32e58
every so often, the USB transfer completes without data (due to
"unlucky" time alignment between E1 and USB frame clock). Don't
call the demuxer in that case.
Otherwise the user is confused by error messages like
<0001> intf_line.c:467 (I0:L0) IN ERROR: -4
Change-Id: Ia99f97c2cca44d15a83a54cebe884b343ec44f46
When opening a timeslot, the client can now specify the (from
application perspective) timeslot read buffer size. This breaks
ABI, but then we're still at a point where only prototype hardware
exists, so we can get away with it.
Change-Id: I6d603778cce14c5d72fe5f54904905ea7e66d7ff
Existing applications (such as those written for DAHDI) expect to
be reading data in buffer/chunk sizes. For example OsmoNITB: It
doesn't want to execute an expensive read/recv syscall to receive 11
bytes, if it needs at least 160 bytes.
Change-Id: I807671bc6f2acaef740ce215b8d8abcb5dce2640
This groups all HDLC-specific members together, in preparation
of adding more fields for other modes.
Change-Id: Ide0577c25836252862153b4f24da550bee013687
This adds the related code to the server and client side of the CTL
interface to switch a line between CHANNELIZED and SUPERCHANNEL.
Change-Id: I765b5c3bc9e07b2353f8647e8260ff95df3727e6
In superchannel mode, all 31 TS are grouped together.
There is no way to enable it yet, see next patch.
Change-Id: Id340b1925471f427deb6cda7eb54e80dfc71faec
We treat the superchannel as an extra, separate timeslot. Initially
I thought of simply re-using TS1, but keeping the superchannel
separate ensures that it doesn't inherit any state (like half-sent
HDLC frames) from another timeslot when we switch between the modes
at runtime.
Change-Id: I0aacf251e155de2bb6ad03ffc4181067b22f1c90
If we are not able to read more packets from the user application,
the recv/read call will return 0 and set errno = EAGAIN. In this
situation we cannot bail out but still ask the HDLC code to generate
output (sequences of flag octets). If we fail to do that, we will
transmit all-ones pattern instaed of all-flag octets.
Change-Id: Id3bc76f1956138dcd9cb7b499f7251cd94af1329
SEQPACKET is great for preserving message boundaries on signaling
channels that use HDLC. However, its semantics, particularly regarding
truncation, are sub-optimal for RAW slots containing raw user
bitstreams (typically TRAU frames or PCM audio data).
So let's use SOCK_STREAM for RAW and keep SEQPACKET for HDLCFCS.
Closes: OS#4663
Change-Id: I1767ceaa5d2a008db0009b8027667a71c0fdc0f1
In Change-Id I7d4d4ab39cb3e7e6a7eb8e738a367122eb3fbee2 I inroduced
a bug that would cause e1_usb_xfer_out() to return four bytes too
little, which in turn causes E1 Tx underflows to happen in the device
firmware.
Change-Id: I71675d4de781421286f0d1febedfdb1f7b523c38
The 0xe1e1 was a neat hack in the early days, but now 0x6145 has been
allocated within the Openmoko USB VendorID. The current device
firmware already uses the new ProductID, let's change it here, too.
Change-Id: Iea6087ce02c931c796d9c9cae89cdf5b5e0b28c5
This adds the 'osmo-e1d-pipe' utlility program, which can be
used as a command-line client to open a given E1 timeslot and
connect it to stdin/stdout. This in turn allows to rediect
file input/output via the shell.
Change-Id: Ib9d55af786c87e15465b8e73493680b35afb5913
The idea is to generate a pair of virtual E1 interfaces (each with
identical number of lines), where each line A:n is connected to line B:n
of the pair and vice-versa.
This allows to test E1 using applications back to back against each
other, without any physical E1 circuits in between.
Change-Id: If42c959556b17d543762546eb45dd69d25f715f2
'struct e1_ts' always had a back-pointer to the line it is part of,
but apparently this was never initialized so far.
Change-Id: I5e6c8189bf5aa4af26d6cd6c6d288a149ed7fa66
We always want to know as much context as possible. Which exact
timeslot on which line of which interface ha logged something?
Change-Id: I3d8909b396928ed3c023b8ac47fa9ec72c99e681
If the user application has closed the timeslot socket, we will
get error returns from read/write calls, which we must use to clean
up the daemon-side state for this timeslot.
Change-Id: I2e3e5010f36e916b4c8908af91447b3d3661123f
This way clients and daemon don't have to be manually configured
to use the same default socket path.
Change-Id: Ibc5bc1bc59056ebaf0f6072de0ff08c2f3bb5457
It is possible that fd=0 (stdin) is closed in a daemon scenario, and
subsequently fd=0 is reused for other files/sockets.
Change-Id: Id8279f04373e891009224bab34a4d1d886520fea
By using llist_add_tail(), we add new elements at the end of the list,
rather than inserting at front. Among other things, this has the added
benefit that when the VTY prints information on lines, they are printed
in numerically ascending orrder (0,1,2, ...) and not the reverse.
Change-Id: I07a6ba706f855a29b4e33b1a6b008e0d2f11b6f3
Let's add a VTY interface on TCP port 4269. The purpose is - for now -
not for configuration storage, but for state introspection.
Change-Id: I47b6e4efaad52e68e2b50a7993076f3706f86628
libosmousb, recently introduced to libosmocore.git, is taking care
of main loop integration of libusb into osmo_select_main(). This
means we don't need to do any polling here anymore.
Change-Id: I3f3b61dfa217d6ef8c17970b2cf1cc627bb13bbe
Harald Welte
Sylvain Munaut
Pau Espin