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
Harald Welte