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.
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 c6a1fe773d.
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.
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.
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...
* 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.
Create a BSC<->MSC interface and use it for the BSC MSC IP and the
BSC NAT to reduce code duplication on handling reconnects to the MSC
and cleaning up the local state. The code is only partially tested
and will contain bugs. Currently both the BSC and the NAT will just
exit on connection loss and this way have the current behavior.
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.
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.
* gsm_04_08_utils.c will directly send the message...
* gsm_04_08.c will use the DTAP API, add a new method to pull
in the data from the transaction...
When submitting a DTAP message, the BSC API will attempt to
establish the RLL layer and then send the message or send an
SAPI n REJECT. This will be used by the SMS code.
This will take care of the auth/check/enable cipher sequence
and call a callback function when done.
Currently the negotiated Kc is saved but not re-used, so
there is an authentication each time ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Ultimately, we'll need to store both the last used tuple by a
subscriber and a list of known tuples (for unknown Ki). What's
currently implemented for AuthTuples is the former behavior, so
reflect that.
The second use case will be added as a separate table with separate
accessors later on.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Holger Hans Peter Freyther
Sylvain Munaut