Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
This is fixing the SIGUSR1 to really report the allocated
memory on stderr.
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
This can be done for testing purposes and to allow making
a BTS crash that can not handle paging requests properly.
|
|
defeated
When sending a MSG to the MSC try to find the to be used "src" reference
by comparing the reference on the BSC and the BSC connection. Only this
tuple needs to be unique.
Actually only when looking at the SRC REF we need to compare the BSC as the
dest reference should be unique but we are just making the check a bit stronger
to make it look symmetric.
|
|
If we find the connection of a different BSC at least log the
BSCs that had duplicated references. We should also dump the
src ref and such but i am not doing this right now.
|
|
We do not want to handle this identity. If we can not page by
lac there is no need to page anything else.
|
|
|
|
Some closed source BSC like to assign the SRC REF from a
small static pool and might reuses one we have not yet given
up on.
|
|
Second attempt to use a syntax more comparable to 'Cisco',
I have never used such a system... let us see how this is
going.
|
|
0 is a valid timeslot and we should not use it... use
a negative value to be save.
|
|
We can forget about the timeslot/multiplex when getting
the DLCX. This way we make room for the next connection
that might need to reuse this address.
|
|
Always initialize the pointer to a invalid value in case
we encounter a parsing error or such.
|
|
We will reset the multiplex in a DLCX message and then
we can reset the multiplex as well...even if the MGCP
connection is staying open. or at least this is a theory.
The MSC likes to leave a connection open during CallControl
when hanging up early enough in the process.
|
|
In case we have a stale SCCP connection with an Endpoint that
we want to reassign...use the newest (last) occurence of that
as it is most likely the one we want to handle.
|
|
|
|
By adding them to the end the VTY interface will only append
connections and not change the order on each invocation.
|
|
|
|
|
|
This might help to identify what is wrong with the config
of the BSC. Also using the result of TLVP_VAL as a char
pointer looks suspicious...
|
|
|
|
|
|
The address can still be specified on the cli and it will
overwrite the config in the config file.
|
|
|
|
Add new BSCs to the tail so we keep the sort order when writing
them out to the vty, fix the LAC command.
|
|
|