| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* ping pong and possible crash fix.
|
|
Make sure the sccp_cc_timeout is stopped when we delete the
associated data. There is one crash report that indicates that
we have a pending timer that is inside freed memory.
A crash could have occured when the connection to the MSC was
lost while have unconfirmed connections.
|
|
We do want to send PING/PONG in both ways to have a heartbeat
on the TCP connection. When switching over to SCTP we can rely
on the builtin heartbeat functionality.
|
|
We will send a ping every 20 seconds and if we have no pong
within 5 seconds we will close down the BSC connection and
wait for a reconnect. We will start this after having
authenticated the BSC and we stop the timer when destructing
the BSC connection.
|
|
|
|
|
|
|
|
Work with a new version of libosmocore that gets rid of
additional pointers.
|
|
|
|
|
|
The nat is stable and in testing..
|
|
|
|
The code needs to be refactored but this is fixing the leak for
now. We used to forward everything to the BSC but now we handle
the DLCX locally and this means we need to clear the patched
message. We should refactor it to not generate the patched msg
until a lot later.
|
|
Remove the return from the case labels and cleanup at
the end matched array at the end of the routine.
|
|
I assume the original code crashed with a double free as we
have a cleanup at the end of the method. Return from the routine
like the case label below. This is fixing a memory leak I am
experimenting.
|
|
Stop using the global vty context for all allocations
and allow to embed the buffer into a given context, and
allocate sub buffers with the context of its parent.
|
|
|
|
|
|
|
|
|
|
When we really need a newline we need to use VTY_NEWLINE.
|
|
This can be used to clear stale connections for a given BSC
or to force a reconnect of the BSC.
|
|
|
|
|
|
Currently the nanoBTS bootstrap code requires a high delay
otherwise we are not bringing the device up properly. Changing
the init code turns out harder than it seems like. So this is
a workaround for that to allow a high speed RSL/OML connection
after the bringup.
The line driver can have a default TS delay. It is set to the
current default for the nanoBTS and the BS11. For the ipaccess
case we will set the delay lower for the RSL connection and
inside the ipaccess-config we can set it low right away to
have fast firmware flashing and such.
|
|
|
|
|
|
|
|
In case we can not find the SCCP connection we still want to
free any pending transaction ids and reset the BSC inside the
endpoint. In most cases this should be already done when the
SCCP connection or the whole BSC is gone.
|
|
When allowing to reallocate an allocated endpoint we will need
to free it first. When freeing we will free the call id and other
ids that we would have leaked otherwise.
|
|
|
|
This is fixing the SIGUSR1 to really report the allocated
memory on stderr.
|
|
Start a timeout to wait for the CC of the network and if it does
not come in time we will abort the connection and take down the
allocated lchans.
|
|
Remember that we have seen a CC and have a valid destination
local reference now and only send a fake RLC to the MSC when
we had connections in this state.
|
|
For now close the connection when having a short read. This might
be due a network issue (loss of segment) or similiar. As we are not
handling these issues well, let us close the connection.
|
|
|
|
|
|
|
|
Send a dummy packet to make sure our Gateway will discover us
and can send the ringtone to us.
|
|
|
|
This routine should operate on different packets and the
dummy load is smaller than a legitimate RTP header so it
is unlikely we will filture out genuine traffic.
The reason is the dummy load might be send more than once.
|
|
When setting a new MSC timeslot to a SCCP connection check if
any of the existing connections have this timeslot, if so we will
send a DLCX down the stream to make sure it is closed there, when
we will CRCX this new timeslot we will happily reallocate it.
When the SCCP connection goes away, or we get a DLCX from the
network, or the BSC is gone we will send a DLCX message down the
stream as well.
When we receive a CRCX from the network we will forward the CRCX
as usual and send a dummy MDCX after it.
For the DLCX and the dummy MDCX we send a custom MGCP message
that will not provoke an answer. Even if the downstream MGCP GW
will answer we will ignore it due the dummy transaction id that
is not used anywhere else.
This change should make sure that we close the dowstream endpoint
all the time, even when the DLCX arrives after the SCCP connection
is torndown.
|
|
This is required for unit tests that want to queue messages
and see if we can provoke a memleak.
|
|
It is possible that the calls from the loop would queue
more messages for the BSC and then we would have a nice
memory leak... Move it to the bottom.
|
|
For the NAT we want to send requests in a send and forget
way and we are not interested in seeing the answers, so tell
the gateway to not answer them.
|
|
|
|
This can be used by higher level code to send one dummy
message from the audio port to the network. This can be
used to make the remote discover the nated port of this
endpoint.
|
|
|
|
|
|
|
