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 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 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
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
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
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
prior to this patch, the configured vpair interfaces would not
be saved to the config file on 'write file'.
Change-Id: Iff6551318534a3717c374060082147f17b925a21
In superchannel mode, all 31 TS are grouped together.
There is no way to enable it yet, see next patch.
Change-Id: Id340b1925471f427deb6cda7eb54e80dfc71faec
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