Age | Commit message (Collapse) | Author | Files | Lines |
|
This is applied to all incoming BSC connections.
|
|
Allow to set the TOS field via the VTY interface. The
SO_PRIORITY was not used as it has no effect on the
packets being sent (in contrast to the documentation).
|
|
We will need to confirm the connection, then we can send the
GSM48 message, then we need to close the connection... the
embedding in the refusal method was way too easy..
|
|
Right now it was not possible to just find a connection, by returning
the connection that is created we will have direct access to it. It
will be used by the local connection handling.
|
|
The msgb needs to be around when we access the parsed structure
but that needs to be guranteed by the caller handing out the parsed
structure.
|
|
A local connection is only between the MUX and the real BSC. We will
not forward anything to the MSC. This will be needed for the IMSI
filtering as sending a CREF is not liked by every BSC...
|
|
In case of a RLC message we will destroy the SCCP connection. This means
that accessing the con and con->bsc will access old memory. Keep the status
local and move the con into an inner scope.
|
|
|
|
We will need to generate messages with a proper reason
and it is easier to do that from a dedicated method.
|
|
|
|
We are analyzing each CR message and it is nice to know the
reason these connections were created. Change the nat method.
|
|
|
|
This can be used to send a Location Updating Reject down to the
BSC when it is clear that a subscriber is not allowed.
|
|
We have tried to send a refuse for arbitary things and ended
up with a segfault... separate the exi2 and exit3 label to have
separate exits and cleanups.
|
|
This allows to chain a nat with a nat by answering to the
id get code and sending the token.
|
|
Currently there is no implementation but the refusal code is
in place and will send a refusal back to the BSC.
|
|
|
|
The MSC does not respond to a SCCP CR with Paging Response as GSM
payload, when the response comes in 'too late'. Prevent the MUX having
stale connections and start removing old connections every 20 minutes.
|
|
|
|
|
|
The adding of the innocent looking code was actually overwrote
the fd and then stupid things happened. Rename variables to avoid
that. rc,ret should be scratch variables...
|
|
We do not want to use NAGLE for the BSC connection.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
This can be used to clear stale connections for a given BSC
or to force a reconnect of the BSC.
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
Count number of SCCP connections, number of BSC reconnects,
number of calls. For most of them we have a per BSC and a
global count.
Right now all structs using the counters survive until the
end of the application so we do not need to free them.
|
|
|