this patch adds a buffer len paramter to the receive_samples() call
that protects the (also) provided buffer from overflowing.
currently each call to srslte_ue_sync_zerocopy() which then calls receive_samples()
relies on a buffer that is "big enough". But that buffer is sometimes
2 subframes, sometimes 3 or 5, sometimes has space for the maximum PRB size, sometimes
only for 6 PRBs (i.e. during cell search).
By extending the interface to pass the buffer size we can make sure that
only samples are received that actually fit inside the provided buffer.
If a process exits and has a controlling terminal, everything under
it gets a SIGHUP by the kernel. That's the case for instance when
running a srsUE over ssh with some specific parameters. As a result,
when the ssh client is killed, SIGHUP is sent to srsUE, which will be
killed immediatelly without proper release, which means in turn that log
buffers are not flushed.
Let's do proper shutdown when SIGHUP is received so that everyone can
get log files.
SIGKILL cannot be intercepted by apps, so it's useless adding a signal
handler for them. I'm pretty sure the signal() function is erroring in
this scenarios. From signal() man page:
"The signals SIGKILL and SIGSTOP cannot be caught or ignored."
this commit fixes and issue where, after receiving paging and the resulting
PRACH from the UE, the eNB would create DRB1 and already schedule DL traffic
on this bearer. However, since the UE has not received the reconfig message
yet, the DL traffic is dropped since DRB1 isn't set up yet.
the commit also does not reset the BSR state of the bearer inside MAC since
this caused to a stall of the received DL PDU. The value would initially be set to
a non-zero value (after receiving the DL PDU from EPC). But when the bearer
was (re-)introduced to MAC, it would reset the BSR to zero, and, since
MAC never polls RLC, the PDU wasn't sent down until the next PDU arrives
and sets the BSR to a non-zero value again.