Because we want to handle older firmwares too, we need to excepect
we might get a smaller structure !
(We can't get a larger one since the wLength we send is limited to
the structure we know)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I4222bf22267f8343abf1e97546111ceb1c299846
It is interesting from a monitoring point of view to be able to
correlate the GPSDO state with other performance counters we export.
While each GPS-DO only exists once per icE1usb, we still export the
state per line, to make it easy for external monitoring to have one set
of counters per line.
Change-Id: I1f98610b7c725146a3f016a8737440be5baae858
Nominally this is of course 8000/s, but this patch should allow us to
verify this in monitoring. Note that the rate_ctr base of course is
"wrong" as it uses the normal system clock, which is much less precise
than the E1 clock of an icE1usb with GPS-DO.
So it really only helps us to compare Rx against Tx or against other
values/counters derived from the TDM clock.
Change-Id: I40e9fb38561410fbf0902b8a390673690a36ea5e
"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
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 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
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
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
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
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
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
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
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
Sylvain Munaut
Harald Welte