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
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
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
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
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
Experimentally this has shown a much lower probability of
USB related overruns/underruns, at least on my system.
Change-Id: I5c73b29462a4870d3c86fd7f46e1574daae6f93f
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
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
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
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