It is not necessary but we also set the data_good flags explicitly to
false so lets to the same with hdr_good
Change-Id: Ic710f7e63f4b7e16a3cbc9eb8bbf9ae1c7c5cb26
Related: OS#5198
There may be situations where we want to change the timeslot type by
calling a different e1inp_ts_config_xyz function at some later point. In
those cases we must ensure that no dynamically allocated resources
remain in the type dependend union of struct e1inp_ts.
Depends: libosmocore.git I0454ffe5809f21504c1e263a781c06596d452d4b
Related: OS#5198
Change-Id: Icf84816460b8ceba43601594bcf504306606f4ed
Close file descriptor and free lapd resources, if time slot
type changes or if it is released. Also, reset local states.
Change-Id: Iab0776fce6921661b39e9e53376cf01a80bcd42c
mISDN Kernel driver uses reversed bit order for RAW (transparent)
channels. With this patch, the order is reversed. Now it uses the
same bit order as RTP payload does. Also it uses same bit order as
other drivers do, like dahdi and e1d.
Change-Id: I77b899bceacdf5484ea9a841cad55775864b4c82
Allow to configure a timeslot as type E1INP_TS_TYPE_NONE. The timeslot
is then put back in its unconfigured state
Change-Id: I073cfaba0d5073447842f22665e213135ea3f635
Related: OS#5198
The CPS field is inside the MAC block. When we are unable to decode the
CPS field a message is printed on loglevel NOTICE. However, it is pretty
normal that the CCU often receives noise (always when no MS transmits)
so we see this error very often. Lets change the level to DEBUG.
Change-Id: I1f5adbf9da6be4fec2d8c93e781c5df62ef62238
Related: OS#5198
At the moment we can only apply one pattern to synchronize on a TRAU
bitstream. This is sufficient because TRAU framing usually does not
change synchronization patterns. However there may be systems out there
that occasionally switch the synchronization pattern.
Change-Id: Id7de21b2de7d02ae5a8f3cbc003aa7974651a289
Related: OS#5198
With EGPRS Ericsson introduced an "UNKN" demodulation mode for normal
bursts. This would instruct the CCU to listen for GSMK and PSK
modulation simultaniously. For 16k there is only GSMK and there would be
no need for such a mode. Lets support it in the API anyway in order to
simplify API usage. When the caller selects it, we just use
ER_UL_CHMOD_NB_GMSK then.
Change-Id: I8492a6d042bd7354b5dc34069030305fe39a731f
Related: OS#5198
The length check bits_len - offs < 0 does not work properly with
unsigned variables. Lets rearange this so that it works.
Change-Id: I9e0cd5d36c517b9198e0dc1bec0477a2ee2fb869
Fixes: CID#307058, CID#307057
The application is responsible to send raw data in sync with the
raw data it receives. It also cares about sending data in advance,
to prevent underruns, if required
Change-Id: Ib311331fbbeff3661f6745e3474918987a8aa460
Another weird and unique gcc supported extension, clang complains:
CC input/lapd_pcap.lo
input/lapd_pcap.c:134:8: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
char buf[msg->len];
^
The kernel has been VLA-free since 2018, let's try not to make it worse.
Change-Id: I547d900ba88c60bae5b53345e1aee104bacd310d
The Ericsson RBS BTS family is using a propritary TRAU frame dialect to
communicate with the GPRS/EGPRS part of their CCU. There are essentially
two implementations available:
- GPRS over 16kbps I.460 subslots (very limited, supports only CS1 and CS4)
- GPRS/EGPRS over full 64kbps timeslots (supports CS1-4 and MCS1-9)
Change-Id: Ib2b232a76588c32cde75b987a7e5fdfddf099cd7
Related: OS#5198
For GPRS TRAU frames (Ericsson calls them GSL frames), ericsson introduces
a propritary synchronization pattern. There are different patterns used
for synchronization, data frames with coding schemes CS1-4 and MCS1-8
share a slightly different pattern than the one that is used for
synchronization but the intersection between both patterns still
provides reliable synchronization. There is also a third pattern for
MCS9 that is not included in this patch.
Change-Id: I9d62089db557d37c924cc42fc8e3b608000ef4be
Related: OS#5198
40 byte sync pattern size is fine for 16 subslots but with an E1 line we
can go up to 64kbps, which is 4 times as much. Lets increase the maximum
pattern size to 160 to be prepared for full 64k slots.
Change-Id: I5be127ed5e39cb154e949b16fb08c26a1d816357
Related: OS#5198
For GPRS TRAU frames (Ericsson calls them GSL frames), Ericsson
introduces a proprietary synchronization pattern. There are slightly different
patterns used for synchronization and data, however the intersection of both
still provides reliable synchronization. There is no need to switch the pattern
depending on the frame type.
Change-Id: I8398f8bbfc51530e37c4328f25155b774394e779
Related: OS#5198
* VTY command e1_line N connect-timeout T to set the connect() timeout
* use ipa_client_conn_open2 to connect with timeout
Related: SYS#6237
Change-Id: I7379102d19c172bed2aa00377d92bc885f54b640
ITU-T V.110 is used in GSM CSD (Circuit Switched Data). The frames
are rather similar to TRAU frames, so we can use the trau_sync code
for it. This commit adds the related definition.
Related: OS#4395
Change-Id: I3aab5c3f494f6ea2b11f3cf69fb09bc77ea941d8
Fail the compilation if TCP_KEEPIDLE, TCP_KEEPINTVL, TCP_KEEPCNT or
TCP_USER_TIMEOUT are not defined.
Harald wrote:
> What we want to prevent is the user configuring timeouts, assuming
> they would be installed into the kernel TCP stack, which then simply
> end up no-ops becaus somehow the libc didn't define them or the right
> #include file was not present at compile time.
>
> [...] Apparently TCP_KEEP{IDLE,INTVL,CNT} were introduced with kernel
> 2.4 and TCP_USER_TIMEOUT with 2.6.37. I think it's fair to say that
> using a modern/master libosmo-* on such old systems might fail for
> various other reasons (eventfd, ...) and cannot be considered a valid
> configuration anyway.
Closes: OS#5786
Change-Id: Idc0ff1ff02ce4b994692d8213c14c0b2caad756e
Set the keepalive parameters to E1INP_USE_DEFAULT initially instead
of 0. Do this independent of the driver (the only driver making use of
this is ipaccess).
Closes: OS#5785
Change-Id: Ia7659c209aea0d26eb37d31e771adc91b17ae668
Unfortunately "-std=c99" is not sufficient to make gcc ignore code that
uses constructs of earlier C standards, which were abandoned in C99.
See https://lwn.net/ml/fedora-devel/Y1kvF35WozzGBpc8@redhat.com/ for
some related discussion.
Change-Id: I5ca56d885b5ce4d4c9f91ffc083c05a48d1306e4
Unlike with classic E1 or nanoBTS, there is no reason why we would
use a delay timer when talking over a unix domain socket between
two osmocom programs. Let's remove the write-delay timer.
Change-Id: I642d2e4495a08ce45e9a4492e98255aacd0be39a
This is useful for users to abort connections which are in "connecting"
state, since the higher layer struct e1inp_sign_link is not provided to
the user until the TCP+IPA handshake in the socket becomes fully
established (sign_link_up() callback).
This is intended for osmo-bts: when something fails and may enter into
SHUTDOWN state, it is desirable to close new RSL links (sockets) which
are in progress to connect, while it waits for a while to complete
shutdown (power ramping down, etc.).
Change-Id: Ia6418321f3b6f1f7274efd414625a4b10a09a362
The problem is that we don't zero-initialize the struct pcap_rechdr +
pcap_lapdhdr before memcpy'ing them to buf, before we call write:
==20097== Syscall param write(buf) points to uninitialised byte(s)
==20097== at 0x4E48471: write (write.c:26)
==20097== by 0x4DA8DE9: osmo_pcap_lapd_write (lapd_pcap.c:168)
==20097== by 0x4DA8433: send_ph_data_req (lapd.c:628)
==20097== by 0x4C94F5C: lapd_send_rej (lapd_core.c:536)
==20097== by 0x4C9A08A: lapd_rx_i (lapd_core.c:1574)
==20097== by 0x4C9AA8F: lapd_ph_data_ind (lapd_core.c:1708)
==20097== by 0x4DA7C55: lapd_receive (lapd.c:496)
==20097== by 0x4D96B2C: e1inp_rx_ts_lapd (e1_input.c:778)
==20097== by 0x4D9C97C: handle_ts_sign_read (e1d.c:78)
==20097== by 0x4D9D908: e1d_fd_cb (e1d.c:281)
==20097== by 0x4D1281B: poll_disp_fds (select.c:361)
==20097== by 0x4D12928: _osmo_select_main (select.c:399)
==20097== Address 0x1ffefffed7 is on thread 1's stack
==20097== in frame #1, created by osmo_pcap_lapd_write (lapd_pcap.c:129)
The whole idea of first filling the two structs on the stack, and then
copying them to another buffer on the stack is somehow weird. Let's
just create a combined struct on the stack and then fill that one
directly.
Change-Id: I358c71354cc6ddad1964cc4a988ad29b7ba617f1
Closes: OS#5592
Before this patch, the logic (both for delayed tx and immediate tx)
always left the WRITE flag set, and relied on an extra call back from
the main loop (poll()) to disable the flag until it found out there was
nothing else to send.
Instead, let's disable it immediatelly at the time we submit the last
message in the queue.
Change-Id: I0e5da5d1342f352d0e2bca9ee39c768bccb2c8d5
Recent commit optimize the same function by avoiding an extra poll loop
when e1i_ts->sign.delay was zero. Upon doing so, the
osmo_fd_write_disable() was moved to some conditional paths. Hence, the
WRITE flag is left set and we don't need to set it again in the code
path modified in this commit.
Fixes: 28fea7746b
Change-Id: I84787b6de2a5ccc82bd8f19ce874e73708bc287f
Historically, before November 15, 2010 when commit
d49fc5ae24fc9d44d2b284392ab619cc7a69a876 was merged to [back then]
OpenBSC, before libosmo-abis became a separate library, we used to
have a 10us delay timer for subsequent writes to ip.access nanoBTS 900.
ts: Reduce the delay to 0 for OML and RSL
This is possible after not sending more than one OML command that
requires an extra ACK. For the RSL line we do not need any speed
limitation.
Ever since the above-mentioned commit, the BSC always sets that timeout
to zero, which makes libosmo-abis start a zero-microsecond libosmocore timer,
which in turn will make libosmocore call select/poll with zero timeout, which
makes the kernel return immediately.
Why not remove the timer completely? Because ipaccess-config.c still specifies
a non-zero signaling delay, and we cannot be sure that this is really not
needed.
So let's alter the code to only start the timer if it's non-zero
Change-Id: I9c379364e7e6afce35fc6316392b5b33748980f7
Multiple IPA units can have the same bts_id but scoping by their
site_ids will make them unique. This also clarifies the "bts"
number being communicated. It is not the bts configuration index
in osmo-bsc.cfg, it is the bts id specified in the vty line:
bts X
ipa unit-id SITE BTS
Change-Id: I3b44319fb4bc6a812800001c58dfe1a664645b43