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
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
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
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
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
prior to this patch, the configured vpair interfaces would not
be saved to the config file on 'write file'.
Change-Id: Iff6551318534a3717c374060082147f17b925a21
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
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
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
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
Harald Welte
Sylvain Munaut
Pau Espin