| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Generate it when creating the connection but also when
reusing an existing connection.
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
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 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.
|
|
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.
|
|
|
|
|
|
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.
|
|
This method currently prepends the IPA header and sends
the data. In the future we might be able to use SCTP for
it.
We have to remove the IPA header from the static messages
for that to work.
This code is untested.
|
|
Sending the reset right away will upset the MSC and we
need to wait for the first contact.
|
|
This allows that we can print the Nr. next to the lac
and it allows us to change the lac at runtime without
reconnecting the BSC.
|
|
Remove the code to parse port as we need to discover the
BTS behind the nat and most likely it will have a different
port than the one advertised by the BTS.
This reverts commit c6a1fe773d16eb20d4cb1d3097761419436f4537.
|
|
Cleanup all endpoints that belonged to a given BSC. This is
one part of the cleanup, the other is to bring down the SCCP
link properly.
|
|
|
|
Extract the port from the BSS's MGCP Gateway so we know
where to forward the data to.
|
|
The MGCP protocol parsing is adding '\0' to make sure we do not
parse beyond where we should parse. This does not mix with strtok
or similiar routines.
For now we will read the msg into a global array first, then copy
it to the msgb for mgcp protocol handling and if we are required
to forward it to the MGCP we have a untouched copy we will modify
into our own msgb.
|
|
Attempt to find the message by transaction id, then patch
the response and use the IP/PORT of the local network, update
the ci with the one from the BSC.
This is currently not tracking any state of the MGCP and will
not handle two bsc's... this will need to happen later.
With this in we should be feature complete and now enter the
mode of making all of this work reliable and fixing thinko's
and other bugs.
|
|
* Forward a rewritten msg to the BSS. We change the IP and port
to point to the NAT instead of the core network. We also keep
track of the BSC and the transacition id.
* Handle the case where we have not found a SCCP connection and
need to send a response ourselves.
|
|
Add code to change the ip and port for audio data inside
MGCP messages. This is needed because the BSS might be
behind the NAT and can not reach the network directly and
might be behind a nat so the announced sourceport is not
the one as we see it.
|
|
|
|
Listen on the MGCP gateway port and let our protocol stack
handle everything for now. We will need to have some more
control over things though.
|
|
When losing the SCCP connection make sure that we free all
endpoints. The disconnection of the BSC should already make
sure they are closed but this makes sure everything is
properly reset.
|
|
Make sure the MGCP attached to the BSC is resetting all
endpoints whenever the BSC is connecting to us as we assume
that all endpoints are available.
|
|
For the nat we will have NAT and MGCP in the same process
and this commit starts with that. We are linking in the MGCP
code and one can embed MGCP config snippets...
|
|
This information will be needed when we are trying to forward
MGCP connections to and from the BSC through the IPA protocol.
|
|
|
|
* Return the SCCP connection. This will be needed to store the
assigned timeslot in there.
* Update code to work with this change
* This uncovered a bug in the CC handling, at the time the BSC was
passed it was still a null pointer and the code would have failed.
|
|
|
|
Moving it here means we can more easily test this code, there is one
behaviour change with the code that we only support paging messages
with one LAC and will silently ignore the others.
|
|
On a CC message we will need to remeber where the source local
reference of the network belonged so we can properly identify
the connection when receiving UDT messages.
|
|
This way one can create the bsc_nat structure in unit tests..
|
|
Move patching and reassigning of messages to a new file which
will making testing this functionality more easy.
|
|
We are still writing to the BSC directly and don't make real
use of this feature right now but we will need to do it.
|
|
|
|
* Move to libosmocore
* Move to new debugging architecture
* Register the BTS types
* Has only been compile tested
Conflicts:
openbsc/include/openbsc/Makefile.am
openbsc/include/openbsc/gsm_data.h
openbsc/include/openbsc/ipaccess.h
openbsc/include/openbsc/mgcp.h
openbsc/include/openbsc/msgb.h
openbsc/include/openbsc/tlv.h
openbsc/src/Makefile.am
openbsc/src/abis_rsl.c
openbsc/src/bsc_init.c
openbsc/src/bsc_mgcp.c
openbsc/src/chan_alloc.c
openbsc/src/debug.c
openbsc/src/gsm_subscriber_base.c
openbsc/src/msgb.c
openbsc/src/rest_octets.c
openbsc/src/sccp/sccp.c
openbsc/src/vty/command.c
openbsc/src/vty_interface.c
openbsc/tests/Makefile.am
|
|
Based on the token the NAT/MUX is capable of figuring out
which LAC this BSC is supposed to satisfy. This will be
needed for messages like paging that can be done by LAC.
|
|
* Create struct bsc_nat and move the various lists into this structure
* Create the VTY code
* Call the VTY init and parsing code
* Create functions to create the types..
* Add some stuff into the bsc_connection to be used for the NAT with
proper config files. E.g. to close the connection if the BSC does not
respond to a given command.
|
|
This way the VTY code can use the structures to implement
the show functionality.
|
|
Do not run into the situation where we need to filter in one
direction but it should not be filtered..
|
|
Introduce a bsc_nat_parse method to parse a IP Access method
into various parts. Write out the IPA Proto, in case SCCP is used,
store the msg type, pointers to the source/dest local reference and
other information.
Use the result of bsc_nat_parse inside the bsc_nat_filter method
to decide if the message should be dropped or not.
In the future the bsc_nat_parse result will be used for patching
SCCP references and other parts of the message.
The filter language should be able to filter the msg type of SCCP
messages and gain the "NOT" word in the filter language.
|
|
The first part is to analyze the IP Access Header and only forward
SCCP messages for now. In the future we might want to do MGCP
signalling through this protocol and connection as well and need to
update this then.
|
