- Handle received E-RAB S1AP at s1ap.cc.
- Added methods to rrc.cc, rrc_ue.cc and rrc_bearer_cfg.cc to handle erab modify request.
- Made RLC add_bearer() function capable of re-creating the RLC entity.
- Send RRC reconfiguration to the UE and reply to the EPC with S1AP
modify bearer response.
This commit also adds support to srsEPC to send S1AP modify bearer request for
testing purposes.
we've logged in warning mode bc we don't support IPv6 but its
causing unwanted noise in the epc log file.
it's quite normal that the Linux network stack sends IPv6 router
solicitation packets, etc. So we just ignore them and that's it.
this is according to 24.301 Sec 4.4.3.3 which says the receiver
should use the sequence number included in the received message
rather a local estimate
the signal handler is the same for all three apps. The "running" flag
as well as the file_logger object are in the common header in order
to allow the signal handler to flush the file if the alarm goes off.
* Remove boost string
* Make sure that int/enc algos can be specified in capital case in the MME.
* Use == instead of compare for comparing strings with const chars
Co-authored-by: Pedro Alvarez <pedro.alvarez@softwareradiosystems.com>
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."