This way we avoid seeing many warnings that we will not forward
data to the MSC. For the con_local connections that is actually
the idea, we will not forward them to the MSC.
Attempt to disconnect the connection and make both sides happy
about this. Right now it only handles the LU and should be extended
to the CM Service Request.
Return early in case the IMSI was already checked, if not we need
to look at the connection and check if the message could contain a
imsi we want/need to filter.
Return -1 if the IMSI should be filtered, 0 if the IMSI could not
be checked and 1 if the IMSI was checked and allowed to pass. In
the future this will be used to inspect every message coming by.
Add some code to count TCH/H and TCH/F and also handle
the neci bit of the network. Our channel allocator will
allocate a TCH/F if we request a TCH/H but can not allocate it.
Only page if we have a load that is acceptable for paging. This
option is off by default, and can be enabled per bts. The idea
is that when we have no resources right now we will not page as
it will only create more RACHs and increase the load.
By default we are keeping the old behavior to always page and
only by changing a setting one is using the new behavior.
Instead of throwing a huge pile of paging commands to the BTS
we will submit one paging command every half second. This way
we can have different messages between the paging commands.
This is done to avoid crashes of the nanoBTS when too much
paging messages are send.
It might be that we run down to zero available slots but the BTS
might not send us a load indication. This can happen if we think
we send paging requests and the BTS disagrees and considers them
as errors and does not count the paging message.
When we drop to zero we will start a credit timer to give us extra
credit after six seconds, if we get a CCCH load indication before
we will stop the timer.
It is possible that the MSC is not sending the channel type it
needs for the operations it wants to do. Add a configuration option
to assign a TCH in case of paging any requests. It can be a good
idea to leave SDCCHs free for location updating requests and use
the TCH for SMS-MT and CC-MT.
Store the mapping from request to channel type in the GSM Network
struct as there is some policy involved with handling the request.
E.g. in a half rate network we don't want emergy calls to be getting
a TCH/F, or we want to have a different policy for early/late assignment
of phone calls. Update the table when creating the network and when
the neci is changed.
Allow the MS to use uplink discontinous transmission by
setting the right bit in the SystemInformation and set
DTXd/DTXu on the RSL channel commands.
This is configurable via dtx-used (0|1) on the network
level and still considered as experimental.
When the cell becomes visible we will be bombed with location
updating requests and to reduce the load on the network we should
assign as many channels for it as possible. During load peek it
is even more important than to have a spare voice channel and in
general the LU procedure is pretty fast.
Assume that if the MSC has assigned a timeslot/multiplex it will
also be used for the MGCP. So we just assume that it was allocated
on the BSC as well... in the worse case we will send a DLCX downstream
but it should be fine.
We are going to have more than one trunk, so all code hardcoding the
multiplex to zero must go. Avoid this kind of problem by saving the
MGCP endpoint number and comparing that.
This uses the osmo_daemonize() function of libosmocore >= 0.1.18,
and is now implemented for bac_nat, osmo-bsc, bsc_hack, osmo-gbproxy
and bsc_mgcp. This means only osmo-sgsn is missing, which currently
has no option parsing at all.
When gprs_ns_sendmsg() succeeds in sending the message, we free()d the
msgb after transmitting it on the socket. However, if the NS-VC is
blocked or some other error condition exists, we returned an error
code but didn't free the msgb.
This resulted in an error leak which is now being addressed.
If the CRCX is failing, we will send a DLCX downstream and the next
time the callagent tries to do a CRCX we will be more lucky. This is
for the case where we have an endp allocated.
Do not use the CI_UNUSED to decide if an endpoint is allocated
but introduce a new flag. This way only the CRCX and free_endp
play with the allocated field.
If we have found the BTS and we receive data on the RTCP port
from the IP of the BTS we will set our RTCP port and forward it
to the network and hope it will be useful.
Remove wrong code that is luckily not called. We would end up
in a reconnect and attempt to bsc_fd_register the same socket
again. I am removing this part of the code as it is not used
and it would need to know if the fd has ever been registered
or not...
For debugging it is useful to forward (tee) UDP packets to another
system and use gstreamer to inspect the rtp stream. This is untested
code and might contain bugs.... and of course only tap your own calls.
Once we have discovered the bts we will not accept data from
anything else. The call will drop if the BTS is changing the
ip address of the nat anyway.
Allow to switch to a dynamic port allocator and not reuse
the ports for a long time... This should help with a crazy
network sending two streams at the same time.
This allows a more strict check on the source of RTP messages
and we can more easily reject those. For the BTS without an ip
address we will also update the ip address.
We plan to have two different ports for the network and for the
BTS to avoid detecting the BTS and to dynamically allocate the
port to have old data not go to a new socket.
common_vty.c was including bsc_nat.h which tried to
get the sccp/sccp_types.h which is not required to be
installed. Move all structs using/embedding SCCP structures
into the bsc_nat_sccp.h and include. This should fix
the compilation.
Currently every SAPI release indication will trigger the channel. It
was possible that we had SAPI=3 and SAPI=0 allocated and we tried to
release the channel by sending a RF Channel Release, the BTS answered
with a RF Channel Release ACK but also sent the SAPI Release Indication
which triggered a channel release here. So it was possible that we
would have released a newly allocated channel because of the SAPI
release of the old connection.
This code now works by releasing all SAPIs from highest to lowest,
then sending a SACH Deactivate and finally releasing the channel. This
approach is in use on the on-waves/bsc-master.
Add --enable-nat and --enable-osmo-bsc to build applications
requiring the Osmo SCCP library to be installed. We are not
using autodiscover as this is out of fashion.
This code compares the UDP sequence numbers of two RTP messages
and guesses if packets are missing. It is guessing in two ways:
1.) by default the sequence number is 0, so on the first
value we ignore the jump... we might ignore a real issue
in case of a wrap around which is easily possible as the
sequence should be a random number.
2.) the UDP stream might have been reordered on the network
and we would see the jump...
In any case these two shortcomings are acceptable for the feature
that is meant to provide some basic analysis..
We need to release the USSD unit, otherwise it is staying blocked
and will stop to function (even across LUs on my a1200). This code
should encode the transaction and the direction depending on the
network state but this is omitted right now.
... while asking the BTS to perform tests for us. The length of the
ARFCN whitelist is the actual length in bytes, not the number of 16bit
ARFCN numbers.
Also, implement a limit, either by rxlevel or by number of ARFCN
that should end up in the whitelist.
Also, we now re-start the network listen test after it has finished,
so if you run a test from ipaccess-find, the test will get re-started
and re-started all the time.
* We should create the transaction for SMS, CC on the CM Service Request
but for now we will use a band aid and create a dummy operarion to wait
five seconds for the transaction to be opened.
* Return msg'es to the right MSC Con. Right now it is nat->msc_con.
* When forwarding from BSC to MSC, use the msc_con inside the
sccp_connections. This means we will only forward data with a
connection to the BSC.
The FCS isn't computed yet (because of ciphering).
It _will_ be tested and reported as wrong later in the code
so we can just display it here and let the latter code report the
error if any.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This was causing weird crashes when running in 32 bit linux.
Thanks to horiz0n for taking the time to debug this with me on IRC.
Written-by: horiz0n <cscan@gmx.net>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
The LLC layer tells us the PDU length, and we have to use it
in SNDCP rather than to re-calculate it if we want to avoid copying
the CRC24 into the defrag elements.
When we defragment the segments from the defrage queue, we have
to iterate all the way up to (and including) the last segment number
that we have received.
sgsn_rx_sndcp_ud_ind() can no longer make the assumption that msgb_bcid() is
valid, as this is only true for an un-fragmented SN-PDU. So instead,
we now store the RAID in the SNDCP Entity and pass it as an explicit
argument to sgsn_rx_sndcp_ud_ind().
Once The TLLI (or P-TMSI of which it is derived) change has been
confirmed by the MS, we need to unassign the old TLLI but keep
the new TLLI _without_ re-setting the LLC entity structure such
as VUsend /VUrecv counters.
The problem is that sms_from_text returns NULL in case the
subscriber is not attached which a) leaks memory of the
previously allocated sms and b) runs into a null ptr
dereference in _send_sms_str().
There may be a better solution than this but this is the
easiest way of noticing and taking action I could find
without changing return values of sms_from_text.
lchan_free only free's the local resource of the BSC but
does not release the channel at the BTS. Use lchan_release
to properly release the channel. This code assumes that the
timeout happens after a CHAN ACT ACK/NACK otherwise we have
some problems. The comment indicates that this is the case.
The transaction should not know on which lchan we are operating
as this can change due handover. Add untested code to share the
subscriber connection of the new and old lchan and move the pointer
in case of success/failure. Also on a clear command we will free
any resources allocated...
This code is not tested and needs to be debugged, but it should
have the right structure. I am going to fix a potential memleak
in the next commit.
1.) memset the gsm48_chan_desc to avoid sending dummy data
2.) According to the GSM08.58 9.3.5 the Mobile Allocation
shall be included but the empty (by setting the length
to zero).
3.) use msgb_tlv_put and calculate the length via the l3h
msgb_l3len and assign it.
On expired paging we might access a GSM Subscriber that has already
been deleted. To avoid this we will add a subscr_get/subscr_put for
the subscriber to the allocation and release path of the request.
Reported-by: Richard Zahoransky
there are now human-readable names so you can do something like
ipaccess-config -U dhcp-enabled -S static-ip -S static-gw 192.168.100.120
to unset DHCP and to set static IP and gateway attributes.
This looks so much better than the *cur++ type code.
Also, we now terminate ipaccess-config once the NV flags or Unit ID have
been set, not just for the OML IP address.
A channel will be released in case of
* Errors via the clear_request callback...
* no more transactions and operations are going on.
This means that if we do something without a transaction
the channel might be closed down right away. The bug fix
will be to create a transaction/operation.
This is a big change to the way we use the subscriber
connection. From now on it is is dynamically allocated
and we will slowly move from a 1:1 lchan to conn to
having more than one lchan per connection.
This is the first commit, the subscr_con* methods will
move to gsm_data once the use_count is removed from the
connection, the freeing of the connection will also change.
The Channel Activate might be sent to a different TRX than the
Immediate Assignment. So we need to make sure that the channel
is activated before we send the immediate assignment for the RACH.
Another reason for that is according to GSM 08.58 we should take
the frame number from the activate and use it for the starting
time inside the immediate assignment message. We obviously do not
do this yet.
The code assumes that the BTS will either respond with a CHAN ACK
or a CHAN NACK if not the lchan will remain in the request state.
gmtime(NULL) returns NULL at least in glibc and *can not* be used as
time(NULL). Since we compare two time_t values when checking the validity
period this can be replaced by time(NULL)
The value of the in_addr might not be 32 bit aligned and reading
it can generate an alignment error on ARM. Fix it by using memcpy
to copy the data into a local variable.
There are many more potential alignment issues that we will fix
when we hit them.
For Siemens BS-11, the 'length' value of the ARFCN_LIST IE is interpreted in
violation of the spec. The spec says it is a length in octets, while Siemens
treats it as 'count of 16bit ARFCN values'.
Also, make sure the bit ordering in the pre-computed MA is correct,
as well as the cell channel description of the target cell being
present in the HO CMD.
We now compute the Cell Channel Description for SI 1 by bit-wise
OR of the ARFCN bitmask of each timeslot on all the TRX of the BTS.
Also, support generating a GSM 04.08 Channel Description IE for
the hopping case (with HSN/MAIO instead of ARFCN).
What's still missing now: Sending the 04.08 Mobile Allocation IE
In some cases, we get a DL_INFORMATION_IND with a wrong channel
number, and only in the DL_ESTABLISH_IND we will see the real
channel number that is to be used for this (TEI, SAPI) tuple.
Now it properly parses message types and IEs that are defined different
depending on the BTS vendor / A-bis implementor. This fixes a lot of
decoding bugs with Siemens BS-11 traces.
Do not use the lchan for the paging but operate on the
subscriber_connection, change the signals too to not carry
the lchan but the subscriber connection... the silent call
and vty code still assume there is a lchan inside the
subscriber connection.
The lowlevel BSC paging API is a simple wrapper around
the RSL command. The BTS will automatically repeat these
messages but if we end up with two MSC inputs we will
need to count these messages somewhere...
With handover and late/early assignment there might be two channels
for one subscriber and only the BSC knows which one to use, so use
the gsm_subscriber_connection everywhere...
The GSM04.08 Section 10.5.2.19 specifies the L2 Pseudo Length
and the length does not include rest octets, so we will need
to use a zero for the length.
The patch is coming from Dieter Spaar.
Inside the access-list we have a list of entries that have
either one allow or one deny rule... we do not allow to remove
a single rule but one has to remove the whole list, in that case
talloc will handle cleaning all entries.
Right now the matching is O(n*m) as we traverse the list
(multiple times) and run the regexp multiple times. One
way to make it faster would be to concat all regexps into
one.
One can set one access-list to one BSC and one
access-list to one NAT. The matching of IMSIs
remains the same for now, also applying the
white/blacklist. Access lists can not be deleted
for now and no perf opt is done (e.g. one could
cache the result of the last lookup in the bsc
struct).
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.
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.
Now we are parsing a CM Service Request, Location Updating Request
and the Paging Response. For all other messages we claim to not
support it and force a refuse.
The code should be shared among the GSM0408 implementation
and this one, and like the LU we are not handling a TMSI
properly as we have no idea where it is coming from.
For now we have:
1.) bsc imsi deny to deny at the BSC level
2.) bsc imsi allow to allow a SIM at the BSC level
3.) nat imsi deny to deny at the global level
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.
First we have the Complete Layer3 Information, then we have
the IE for the Layer3 information, then the GSM48 hdr, then
the actual content with data. Right now we are parsing the
LU but we are not filtering anything yet.
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 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.
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.
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.
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 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.
Create the GSM network at the end of the init, send the
GSM reset on each reconnection and close a small window
when we would send a SCCP msg before being authenticated.
For that we have introduced an authenticated into the bsc_msc
struct and will manage it inside the bsc_msc_ip.c
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.
It was possible that the nat detected the core network
gateway as the bts just due being the first to send data
to the port. Fix it by setting a dummy bts_ip to force
the mgcp_network code to compare the in_addr.
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.
E.g. when the MGCP on the BSS is not responding we could block
all of our endpoints. As we are mostly in the middle and forward
bits we will happily reallocate the endpoints.
When not being able to allocate the msgb for the forwarded data
there is no point in keeping and preparing the transaction. So
we can move the msg creation a bit up and only do the allocations
after having done the msgb allocation.
When receiving a DLCX we will now delete the endpoint right away. This
means when a BSS does not respond to the DLCX our endpoint will not
be blocked. E.g. this could happen when the MGCP is restarting or
in similiar conditions. When the BSS is not responding we move the
burden up the chain to the CallAgent. We have to still keep track
of the transaction id and the bsc pointer to keep the mgcp forward
routine working.
Sending a RLSD with SCCP failure makes the MSC free all the resources
(MGCP, audio channels), right now we are ignoring the RLC we get from
the network and print a unhandled message.
This value is copied into the bts_audio_payload when allocating
a BTS MGCP endpoint. For the nat we have actually no interest in
patching MGCP messages. We will patch them to the network because
the code will do it anyway, we will not patch things back to the
BTS.
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.
Fix the test to search for the original message instead
of the already patched one that should not find any items
anyway.
The remove is called on already patched connections so we
need to match it with the patch reference count.
Instead of checking the token for NULL we need to check if running
was set to null. Look at the data of the token and check if the line
was ending with a \r\n or \n and then when rewriting a line use that
line ending as well. Add a new test for that.
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.
This test case tests connectiont tracking by sending
a CR, getting a CC, sending a DTAP, receiving a DTAP,
receiving a RLSD, sending a RLC. It verifies that the
messages are properly patched specially the references
at the BSC.
When sending a message to the MSC in the case of DT1
messages we only have the address of the MSC, so we
need to go with that, otherwise (e.g. in case of a CR, RLC)
we do have the source address and need to patch it.
When forwarding a message to the BSC we do receive
a msg that should contain the patched address, we need
to unpatch it...
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.
When we disconnect from the MSC handle it by pushing the problem
to our connected clients. We will simply close all connections,
reject all new BSC connections and attempt to reconnect to the MSC.
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.
The latency of setting up of the TCP connection can be quite high,
it is better to connect in a non blocking way. This code is working
by setting the socket nonblocking and temporarily replacing the
bfd callback with the connect handling.
Once the OS has connected our socket we switch back to normal operation.
In case we disconnect with some pending operations we will need to
signal the MSC that something is wrong. This could be by sending a
RLSD directly, or a clear command. Another part of the fix is to
respond with a RLC on unknown RLSD messages.
* Provide access to the GSM0808 TLV attributes so we can use it in
the nat code.
* Read the PAGING message, if it is paged by LAC we go through each
LAC and then attempt to find the proper BSC connection and then
send the message to that BSC.
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.
For the one MSC and n BSC case we need to patch the SCCP source
local reference on connection orientated links to avoid a clash.
For simple UDT packages we just let them pass and for SCCP connection
we have to:
1.) Create an entry on Connection Request
2.) Patch the entry on Connection Confirm, Connection Refuse,
Connection Release, DT1, Connect Release Complete
3.) Remove the entry on Connection Release Complete
The current code is blocking CRs, Release Complete from the MSC, and
creates the connection state only from the BSC side. The code to
assign a source reference is taken from sccp.c and handles wrap
arounds and such properly. We rely on the SCCP parser to fill out the
place to the source reference correctly so we can easily fix it.
The whole code is young and might contain bugs we need to resolve..
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.
Harald actually pointed out that this feature is just NAT. We want
to connect n-real BSCs to one BSC Mux. We will talk the ip.access
protocol and SCCP over of this link.
The mux will drop certain GSM messages (like the reset), it will
replace source local reference (NAT functionality) and it will handle
some GSM08.08 specially.
Get the thing started...
* 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>
According to the GPRS NS spec the maximum framesize
is 1600 octets for FrameRelay, it can be bigger if
configured to be so. Make it 2048 octets to have some
space available...
We now have a function that generates BSSGP PS and CS paging request.
It is called from the libgtp code when we receive a GTP packet from
the GGSN for a MM context that is in SUSPEND state. We then issue
a PS paging request to the Cell with the BVCI where the last RA update
was being performed.
TODO: We still don't enqueue the GTP packet (and transmit it on paging
complete), and we don't rate-limit the paging requests, i.e. every GTP packet
will trigger another paging request.
We probably also need some kind of logic that marks the phone as UNREGISTERED
if it doesn't respond to paging requests for some time.
The paging message should not be called directly and the GSM Subscriber
can handle multiple requests at the same time... Now a subscr_put_channel
should be called after the message sending. But it is not very clear when
this can be called. The current code works by luck that the SAPI=0 will
be released...
The MT-SMS was tested via the VTY interface and a N900.
We will tell the BTS where we are listening, but the ACK
will return the original settings... this should make it
possible to intercept the GPRS stream..
As we don't support compressed SMS, we have to properly reject it.
In the existing code, we segfaulted at some later point since the error
handling was incomplete.
This was triggered by some obscure STK SIM card that insisted on sending a
compressed SMS after registering to the OpenBSC network.
Some phones (notably a Ericsson Mobile Platform based E-TEN M800)
insist on sending PDP CTX DEACT messages for contexts that have already
been deactivated. The spec doesn't really say what we should do in
this case. But since there is no "reject", we simply acknowledge it.
This is a good interim solution for messages not handled by us,
right now this would include the NVRAM attributes that I do not
feel like caching right now.
Right now the memcpy with the data will copy data to itself as
the new_msg->data and msg->data are the same due the previous
copying of the header which included copying the list entry..
We allocate a message as big as the current one, then we have to
set all pointers by looking of how far they are away from the
msg->_data and add that to the new pointers.
Also copy the OpenBSC/GPRS specific CB data, also do the same
for calculating the offset to the data... At the end we should
end up with a copy...
Do not use RSL to release the SAPI/Channel from within the code,
the normal channel release procedure will take care of releasing
the SAPIs and there should be no issue in keeping the SAPI=3
established until the end of the session.
If we send the IDENTITY REQUEST for IMEI before sending the IDENTITY
REQUEST for IMSI, the probability is higher that we receive the IMEI
response and associate it with the respective subscriber.
Using the code of this commit, it was possible to provision GPRS
services and access a website from a G1 phone (Qualcomm MSM7k baseband chipset)
using a nanoBTS, Osmo-SGSN and OpenGGSN.
There is still no fragment re-assembly in the uplink path yet,
despite the (untested) code present in the gprs_sndcp.c file
This only works for packets that are small enough to not need
fragmentation at the SNDCP layer (dns queries, ntp and the like).
It requires libgtp built from OpenGGSN dc3744fda045f9fca83de6881176987335a309a8
or later. Plain 0.90 will NOT work.
Using this version, I could see bi-directional traffic from various
phones going all the way through BTS, OsmoSGSN, OpenGGSN and being routed
to and from the real internet. Time to celebrate...
We have to copy the sin_addr.s_addr, rather than the entire sin_addr. The
latter results in the destination interpreting it as an IPv6 address, as
the only differentiator between IPv4 and IPv6 is the size of the payload
of this IE.
* separate the LLME and LLE state in the LLC layer
* introduce gprs_llgmm_assign() function for LLGMM-ASSIGN.req primitive
* change QoS profile to match 'real' SGSN
* Update the new TLLI when assigning a P-TMSI
The result now is that the LLC layer is notified of TLLI changes, which in turn
means it doesn't allocate a new LLE structure every TLLI change, which again
in turn means that the UI frame sequence number does not reset to zero.
As a result, MS should no longer ignore frames based on wrong UI sequence number.
When we send a downlink unit-data request via BSSGP, there is a lot
of information that needs to be copied from the mm context, such as
the IMSI, DRX parametes, MS radio access parameters, ...
This is a quite strange layering violation, since we now need to pass
a pointer to the MM ctx from GMM through LLC into BSSGP :(
Our state transitions and timers now reflect 04.08 for GMM much
better than before. Also, we allocate a new P-TMSI on every ATTACH
and RA UPDATE, as some phones seem to get confused if they don't
get a P-TMSI.
When we issue a RF Channel Release in case of a failure we receive
RLL release indications after the channel was tearn down and we
issue another RF Channel Release as a result. The channel allocator
might have already allocated this channel and we release the channel
again with another MS on it.
Make rsl_rf_chan_release take an error argument and make it set
a new state in case of an error and change the RF Channel Release
ack to not set the state back to none in case of an error but wait
for a timeout that is a bit higher than T3111.
I tested this with removing the battery during a phonecall and
waiting for the channel failure. With this test we only send the
release once.
We assume that the lchan_free will initiate the release and
that when we handle the RLL release indication or the release
request as part of the shutdown sequence.
The current channel release has a couple of issues we will
need to fix in a set of upcoming commits.
The issues include:
1.) sending release twice
2.) reassigning the channel inbetween the relase..
This is of course not the correct way of dealing with it, but for
now it should make the Ericsson Mobile Plafrom based phones happy
(they insist to do a suspend/resume cycle before pdp ctx act)
GRE has the strange notion of keepalive messages being encapsulated IPv4
packets adressed back to the sender. Since we actually really only care
about frame relay, this is a bit strange. However, we'll do some sanity
checks and send it back through our GRE socket...
0 Reserved for ANSI Annex D and CCITT Annex A link management
1 - 15 Reserved
16 - 1007 Any PVC
1008 - 1018 Reserved
1019 - 1022 Reserved for LMI multicast
1023 Reserved for LMI link management
According to the spec, after an incoming RESET or RESET_ACK, we shall start the
TEST procedure, not the ALIVE procedure.
Also, when we start the TEST procedure, we have to always send a NS_ALIVE
packet at the same time (we didn't in the case of incoming RESET).
Furthermore, we now only start TIMER_TNS_ALIVE from within the
TIMER_TNS_RESET callback code, where we also make sure that the
alive_retries counter is reset to zero.
We previuosly had a 'subscriber node' under the 'configure node'
which is strange, since subscriber data is not part of the config file.
The relevant operations have now all been moved to the ENABLE node
of the VTY.
Furthermore, 'show subscriber' does no longer require the IMSI but
can also identify the subscriber by ID, TMSI or other identifier.
Change gprs_nsvc_reset to return void instead of a int
as the gb_proxy.c currently ignores the reutnr value anyway.
Change the caller inside gprs_ns to return the newly allocated
nsvc instead of the return of gprs_nsvc_reset.
Almost all parameters about the SGSNs NS-VC can be specified in the NS
protocol node. All that needs to remain in the gbproxy config node
is "nsip sgsn nsei XXX".
* store LLC SAPI as part of PDP ctx
* store NSEI + BVCI as part of MM ctx
* export gsm48_tx_gsm_act_pdp_acc() and call it from sgsn_libgtp.c
* create and use gsm48_tx_gsm_act_pdp_rej for error cases
* print SAPI as part of VTY show pdp
libgtp of the OpenGGSN project will allow us to speak the GTPv0/v1
protocol of the interface between SGSN and GGSN.
This commit includes code for the main libgtp integration (file
descriptor, select loop, timer) as well as code to encode/send
a CREATE PDP CONTEXT request.
We want the VTY and telnet code to be independent from the BSC
application(s). As a side note, we also like to eliminate static
global variables for 'struct gsm_network' all over the code.
As such, telnet_init() is now passed along a "private" pointer,
which getst stored in telnet_connection.priv. This telnet_connection
is then stored in vty->priv, which in turn gets dereferenced if
anyone needs a reference to 'struct gsm_network' from the BSC vty
code.
Also:
* vty_init() now calls cmd_init()
* the ugliness that telnet_init() calls back into the application by means of
bsc_vty_init() function has been removed.
* telnet_init() now returns any errors, so the main program can exit
e.g. if the port is already in use.
This enables us to make the VTY completely independent of any
compile-time program-specific information, i.e. one step closer
to using VTY as a shared library from multiple programs.
Rather than deleting the NSE from memory, we simply mark it as non-persistent.
This makes sure that there are no invalid references (e.g. from gbprox_peer)
to the gprs_nsvc structure, but at the same time ensures it will no longer
be stored as part of writing the config file.
So far, we only started the ALIVE procedure on RESET-ACK if the
remote end was the SGSN. This resulted in the BSS->Proxy connections
only being tested for alive-status from the BSS side, but not from
our side.
Also: export nsvc_by_nsvci() function as a public API function.
This is a generic MI extraction for the MI if it is followed
after a classmark. For the Phase1 Phones the classmark2 is not
four bytes but it might be different. This code can be used
by the CM Service Request handling as well.
We go from no size checks to some content checking. We should
refactor the whole classmark2 + mi parsing that is used throughout
the code into one place with proper size checking. This is the
start and requires a new libosmocore as well.
Using "end" you can always return to the "enable" level, and from
there the "show" commands are available. So no more need for
exit/exit/exit/exit/disable.
Some BSS that connect to the proxy do not continue to perform the
RESET procedure after a timeout. In order to resurrect them, we
simply start a RESET procedure.
We now actually are much more in line with what the specification
says. We track the blocked/unblocked state, we don't accept
signalling messages on PTP functional entities (and vice versa),
and we don't simply create a BVC context with messages other than
BVC-RESET.
Don't allocate a LLC Entity just because BSSGP passes any random
SAPI/TLLI up to us. We can only do this for XID and UI frames
of the GMM SAPI.
Furthermore, add more comments and debug messages.
I want to have a shorter lchan summary but with the same
config parameters. Change the current code to be a method
that takes a dump routine as parameter.
Add the rach emergency call allowed (0|1) setting and implement
it by directly manipulating the t2 value. It is the third bit which
is set to 0 when emergency calls are enabled and to one if it is
only enabled for access classes 11 to 15.
Add the rach emergency call allowed (0|1) setting and implement
it by directly manipulating the t2 value. It is the third bit which
is set to 0 when emergency calls are enabled and to one if it is
only enabled for access classes 11 to 15.
In the previous code we used a static fake_nsvc structure in
case we needed to send a message to an unknown NSVC for which
we don't have a real 'struct nsvc'. However, since we now have
a rate_ctr_group hanging off the nsvc, the fake structure didn't
have that.
So now we keep a nsi->unknown_nsvc around to be used whenever
we need a nsvc but don't have a real one. The gprs_ns_vty.c
code explicitly does not list that NSVC in 'show ns'
If a second ends, we add the number of events in that just-ended second
to the number of events in the currently running minute. The same happens
at the end of a minute: We add the number of events in that just-ended
minute into the number of events of the still-running hour, etc.
This gives a much more meaningful numbers and we don't end up with
"12 events per second, but 0 events per minute" kind of situations
anymore.
Every NS-VC now has a set of counters for incoming and outgoing
number of packets and bytes.
We also split the VTY part of the gprs_ns.c implementation into gprs_ns_vty.c
to make sure the protocol can actually be used without the VTY code being
present.
A 'rate counter' is a counter that counts events but also keeps
track of the rate of events (per second, minute, hour and day).
'rate counters' are generally abstracted in 'rate counter groups',
which are instances of a 'rate counter group description'. This
way we can have e.g. a description describing what kind of counters
a BTS (or TRX) has - and we can then create one instance of that
group for every BTS or TRX that exists.
As only NS-UNITDATA messages are ever passed into the Gb Proxy,
we need to do the msgb_free() at a much higher point in the calling
stack, i.e. inside the NS protocol layer. This means it is now
the same logic as in OpenBSC itself.
The old idea was to take a msgb from gbprox_rcvmsg() and then
modify it and finally send it all the way down to nsip_sendmsg()
to the remote peer.
However, this introduces memory management difficulties, as we then
have to distinguish three cases:
* msgb was sent to a remote peer
* we sent some error message and need to free the msgb
* we need to make n-1 copies in case of a BSSVC-RESET from the SGSN
So instead we now simply always copy the message if we pass it on.
All messages received by gbprox_rcvmsg() are msgb_free()d in the very
same routine
All messages allocated by tx2peer() or tx2sgsn() are freed after
nsip_sendmsg()
For the multi TRX setup we will need to specify the right trx->nr
to be able to flash the BTS. For the BS11 case we are ignoring the
additional argument.
Send the IPA Restart to a given BTS/TRX, change the signal callbacks
to carry the trx instead of the BTS so we have an easy access to the
right TRX and change the ipaccess-config to use that TRX. This is
fixing the restart with a multi TRX setup.
Even if we have the msg->trx, use the gsm_bts_trx_by_nr and get
the TRX from the fom header. This is because the OpenBSC and the
BTS numbering might not match for the multi TRX case.
Currently we are connecting to the BTS and once the OML is established
we are bootstrapping the OML. This does not work for a multi TRX setup
as we will need to use a trx_nr != 0 for it.
Change the code to wait for a message (in this case NM OC_BASEBAND_TRANSC)
to detect the trx_nr used by the BTS and then use that TRX to bootstrap
the network.
I have tested setting the unit id on a single and multi trx system for
the first and second trx.
With persistent NS-VC configuration (configured through VTY),
we can respond properly to BSS with a somewhat strange NS
implementation Such as the BSplus. It enables us to respond
with a proper NS-RESET (including NSVCI/NSEI) when receiving
a NS-ALIVE or other PDU for a BLOCKED/DEAD NS-VC after our
end of the connection is rebooted.
If a PTP BVC is BVC-RESET by the BSS, the PDU contains the
Cell Identifier. We can snoop this into our gbprox_peer structure
for better visualization of each peer in they vty.
As the logging config is getting more and more complex, it is good
if it can be displayed interactively.
WARNING: This needs libosmocore 0.1.6 or later!
'logging level' can already parse a human-readable level such as
'debug' or 'notice'. By setting the global mask within the same
command we can also parse it there.
In order to reuse the existing bssgp_tx_* functions without pulling
in the dependencies of gprs_bssgp.c, we have to move those functions
to gprs_bssgp_util.c
Furthermore, we can remove gbprox_nsi and replace it with bssgp_nsi,
and we can do proper processing of BVC-RESET messages coming from
the SGSN on the signalling BVC. In that case we need to send RESET
messages to all the BSS.
In order to finish PDP context activation and start the transfer
of SNDCP N-PDUs, we simply confirm to the MS whatever XID parameters
it requests. This of course has to be implemented with a proper
XID handshake at some other point.
The message looks now fine (from wireshark point of view). However,
we cannot simply echo back the QoS parameters, as the meaning in
uplink and downlink connection is not the same.
BSSGP stores a pointer to the Cell Identifier IE in msgb->cb, which
is later used by the GMM layer to identify the cell that has sent a
given message.
This now also means that the gsm_04_08_gprs.c code is free of any
legacy references to msg->trx or struct gsm_bts.
We now expect the highest level (actual SGSN GMM code) to know
all identifiers for every element in the protocol stack, i.e.
TLLI, SAPI, BVCI and NSEI. The layer-inetrnal state is looked
up based on those identifiers.
The reason for this is to ensure only the highest level state
needs to be persistent, while everything else can be regenerated
dynamically (e.g. in a SGSN restart)
In the old code
l3h = BSSGP, l4h = LLC, cb[gmmh] = 04.08
Now, this has been changed to
cb[bssgph] = BSSGP, cb[llch] = LLC, l3h = 04.08
This way, GSM general 04.08 and GPRS 04.08 code can expect a
GSM 04.08 header at msgb->l3h
Instead of continuing to add more and more functionality to the
bsc_hack binary, we should have the new SGSN code run as a separate
executable.
After this commit we now build a 'osmo_sgsn' executable, using its
own osmo_sgsn.cfg config file.
However, the SGSN is not yet functional, mainly due to the fact that
the BSSGP and GMM code are written with the assumption that there
is a msgb->trx->bts and the according 'sturct gsm_bts' data model
around - which clearly is no longer the case outside of bsc_hack.
The ida of the Gb proxy is to aggregate Gb links with a number of BSS
and then present all the BSSGP-VC's together inside one NS-VC to the
actual SGSN.
The code is not yet expected to be complete.
According to TS 08.16, the BSSGP layer needs to specify NSEI and BVCI when
executing the NS UNITDATA REQUEST primitive of the underlying NS layer.
Rather than passing around a pointer to the 'struct gprs_nsvc', we now
have NSEI and BVCI as members of 'struct obsc_msgb_cb' and set them
when BSSGP hands a message down to NS.
NS then does a lookup of the 'gprs_nsvc' based on the NSEI parameter.
* move UDP listener code for NSIP from input/ipaccess.c and into gprs_ns.c
* add PDU type, IE and CAUSE values for later IP based 3GPP TS 48.016
* support multiple NS-VCs and their lookup based on NSVC and sockaddr_in
* maintain the remote_state (blocked/alive) for each NSVC
* introduce the concept of GPRS_NS instances, move all global vars to instance
* remove hardcoded calls to gprs_bssgp_rcvmsg() and replace it by callback
WARNING: This is not finished code. While it will compile, it will not work
yet, as BSSGP needs to be converted to properly indicate the NSVC to which it
needs to send data.
The explicit 'tlli, gmmh' members of struct msgb are gone from
current libosmocore and have been replaced by the more generic
'control buffer' mechanism.
While doing 'nm' on a VTY-using object file I noticed that all
cmd_elements are global symbols, which is not good.
Unfortuantely there are some vty-internal cmd_elements that need
to span across object files, so I had to introduce gDEFUN()
and gALIAS(). The old macros now all declare static structures.
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.
The previous code just hardcoded RSL_BCCH_CCCH_CONF_1_C, but
we need to inspect the timeslot config to know what to use.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This breaks the ARM build in osmocom-bb. Besides uint??_t seems to
be the preferred type in osmocore. (coming from stdint.h vs sys/types.h)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Stop the tx_timer when deleting the link on top of that ts. Otherwise
bad things might happen. E.g. when scheduling a write on OML and then
the OML link vanishes...
This is a slight layering violation as there could be more than
one signalling link on the timeslot (at least in theory) so the
queue and the timer should move to the e1inp_sign_link.
Be able to tune the RACH settings of the BTS via the vty interface,
by default they are initialized to -1 which means we will use the
content of the static array (BTS default) and can be changed via
the VTY interface. I have verified the setting on the nanoBTS with
wireshark and I have tested writing the config file.
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 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.
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.
My previous attempt to only add the hunks I changed broke the
format of the patch and this time I am just dumping my current
patch on top of these patches.
This is an ip.access specific 08.58 oddity. It reports 0xffff
available paging buffers if the paging load is below the 12.21
CCCH LOAD INDICATION THRESHOLD.
We use 50, since that is what it reports if the threshold == 0.
The actual 'Extension Length' field in the 'GPRS Cell Options' IE
is coded the length - 1, not the full length. Without this fix,
the code has an off-by-one error.
Extension Information is part of the GPRS Cell Options IE, as
specified in Chapter 12.24 of TS 04.60. It is needed for
indicating EDGE capabilities of the BTS to the MS.
This simply adds the code to encode this IE as part of SI13,
but does not actually use the code yet.
According to TS 08.18, BVCI=0 is for the SIGNALLING entity,
and BVCI=1 is for the PTM entity. Both should not be used
by the PTP entity that we're configuring here.
The current setting was not properly written out, this commit is
fixing it. This includes indention, empty bts ip, wrong command
for endpoints and the wrong number (+1 as zero is allocated but
unused).
Free all allocated channels on the TRX that failed, go through
lchan_free to signal higher layers and then force a reset of
the channel. Make the TRX and TS unusable by setting the operational
set to 0 (not really defined) which should be reset once the
RSL is coming up again.
This is addressing multiple issues regarding the loss of the
OML/RSL link to the BTS.
1.) When we lose the OML link, close down all RSL connections
on all TRXs (only tested with one TRX) and free the e1inp_line
allocated for the OML connection.
2.) When we lose the RSL link on any TRX and we know to which
lines this connection belongs, we will close down the OML connection
as we have a problem to just reactivate one RSL link.
3.) When we lose the RSL link on any TRX and we do not know
where it belongs to we will free the bfd we have allocated in the
rsl listen/accept method and we properly close the socket (i could
not test this one properly). This is made under the assumption
the BTS has not responded to the ID request.
4.) When we already have a bts->oml_link we will throw it away
and use the new link (it should not happen) and the same applies
to the rsl link.
For GSM V1 FR, the payload type is fixed to 3 in the RFC.
But for the other codecs, the payload type is dynamically assigned
between 96 and 127. Here, we use a static mapping internal to OpenBSC.
This patch is needed to make a rather old 139 unit (with sw version
120a002_v149b42d0) work with something else than FR codec. I also tested
this patch on a newer 139 (with sw version 120a352_v267b22d0) to make
sure it didn't add a regression. More testing with newer EDGE units
should be done by whoever has some of theses.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
The previous code only sent the FILE_ID tag data part,
but according to the GSM 12.21 spec, section 8.3.6, the
full SW Description 'object' must be sent so that includes
the NM_ATT_SW_DESCR tag, the whole FILE_ID and the whole
FILE_VERSION (including tags & length fields).
Note that functionnaly on a nanoBTS 139 I couldn't see any
difference ... whatever I send in there it works ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Right now I'm seeing crashes when removing a link and deleting
it and I need this hack to make it not crash. We will have to
understand if llist_for_each_entry_safe has a bug or if we are
doing something bad with the list (anchors not properly initialized).
Reducing the throttling to this value created a regression with
bringing up RSL on the nanoBTS 900. We do seem to have a bug/issue
in the bsc_init code and might send a command too early without this
longer wait period and then the state transition does not happen.
For now it is agreed that reverting is the best thing to do.
Debugged-by: Sylvain Munaut <246tnt@gmail.com>
This reverts commit f5284ae1cf.
Set the state to activation to avoid a warning about the
getting a CHAN ACK without waiting for it. We set it in
the code to make sure it is set after all error checking
to avoid inconsistent state as the state is only set back
to NONE/ACT due replies from the BTS.
Currently our GSM04.11 code is closing the link for SAPI=3
and this would mean that the whole channel would be scheduled
for close... where we only want to close everything when freeing
the lchan or handling an error.
The current code was overly complex. It tried to iterate over
the list in a round robin and we had to keep track of the last
element, see if we remove that one, check if the list becomes
empty... This can all replaced by treating the double linked
list as a queue. We take the item at the front, do something
on it and then and then put it back to the list at the end.
On the nanoBTS we do not receive any load indication for the
paging channel and we just decrement our available slots and
the unsigned int wraps to the maximum value. Together with a
not yet understood bug this makes us go amock.
For the nanoBTS and even the Siemens BS11 resetting the load
to 20 after two seconds should be just fine. For the nanoBTS
we would need to reset the 20 a lot more earlier but we need
to take a look at how often we run low.
Send a Paging Request to the BTS every two seconds. This way it is
unlikely that a phone will try to respond to two paging requests as
it is currently happening.
The length field of the IPA header allows to have 16bit numbers
and I just ran into the 300 byte limit with MGCP messages. Make it
three times the size and see how long this is going to be enough.
For some mode of operation it can be acceptable to reallocate
an already allocated endpoint. This can be the case when we
only deal with one call agent that is keeping track of the
endpoint but slightly confused.
Currently vty_interface.c is used for the BSC config, in case of
the MGCP Gateway or the BSC Nat process these logging commands are
not available. Move the commands to a new vty_interface_cmds.c file
to allow to share basic commands across different programs.
we will need the call identifier for the MDCX and DLCX message
for now we were just assuming it would increment, use som python
to extract the CI from a possible response, also switch back to
a blocking read to test the BSC nat.
Move the conversion of GSM0808 timeslot and multiplex from
the bssap.c into the mgcp.h so it can be reused by multiple
users. The weird math comes from the mapping of the MSC...
E.g. when the underlying connection transport medium is gone
one needs to force to close SCCP connections, add this helper.
It will remove the connection from the list of connections and
it will free the data.
Make the source address mandantory and complain about
complain when it is missing. The address is mandantory
as it needs to be put into the MGCP messages...
When we have assigned the cn we will use mempcy to copy the one
byte into the target. Use a static assert to assure that the type
have the same size.
warning: dereferencing type-punned pointer will break strict-aliasing rules
This code simply enables the channel allocator to understand the
dynamic TCH/F / PDCH channel type as used by ip.access nanoBTS.
It does not actually try to switch the dynamic mode, but instead
sends signals to a (not yet present) dynamic switching algorithm.
Before this patch, there was a bug in the code caused by a memcpy
from one data structure to another. unfortuantely the data structures
were not the same, so we have to explicitly iterate over the array
and assign the structure members manually.
The logging/debugging code is generic enough to move it into libosmocore
while keeping OpenBSC specific definitions in openbsc itself.
This commit uses the logging support present in libosmocore-0.1.2,
you will have to update your library to this version.
As the debug subsystem number is used as index into the debug_info_cat
array, there is no need to store the number explicitly inside the
structure again.
Instead of deleting the msgb within the SCCP library the implementor
of the write callback needs to free it. This is required for non
blocking io with the server.
The "sms send pending" VTY command did not work due a mismatch
of types. We are specifying a unsigned long long in the query
and provided DBI with a signed integer type. The result was a
failure do find any information.
Change the API to operate on unsigned long long that is matching
the id of the SMS and the Subscriber and the mismatch with the
query string is gone and pending SMS are sent.
The 08.08 API will interface with the internal BSC code and it is
the boundary between MSC and BSC. So nothing that calls the BSC
functionality should know about lchan or such.
Change the MSC transaction code to operate on a GSM Subscriber Connection
instead of the lchan. This will help us to separate the two commands properly.
Together with the previos -e Number option one can easily turn on
debugging without needing to remember the category masks for a quick
check on what is going on.
When we are on a TCH/H or TCH/F always use the SACH for SAPI!=0
for the establishment otherwise it will never be answered. This
can be tested by starting to page with a traffic channel and then
trying to submit the SMS.
The code in 354ef81d80 checked
for fd >= 0 but on startup the struct is memset to 0 so this
test is true. Initialize the fds to -1 to make the code work
and be able to handle all ranges of the fd.
Attempt to read the three byte IPA header. If we read 0 then
the socket can be closed otherwise we need to read three bytes, if
we don't we do have a failure.
After having parsed the header we need to evaluate the length,
if the length is bigger than would fit into our buffer we will
ignore that and print an error.
This is fixing a crash when the BTS is crashing...
This code used to be a sleep, it was changed to be a timer by Andreas
but this timer does not seem to have any use. When doing the sw load
this timer is increasing the upload time dramatically, reduce it to
make it work faster.
Currently one has to put -w in front of -f to really write the
firmware file to disk. Change the config handling to first take
all parameters and then execute on them. This means -f can now
be used with any other parameter.
Fix a infinite loop when establishing a new RSL connection and the
BSC is identifying itself with a unit id of an already established
RSL connection. The infinite loops happens because we are corrupting
the the linuxlist inside the bsc_fd when registering the bfd twice.
Due the lack of proper authentication favor the new RSL connection
as the real one and close the previous one.
Even when removing AC_CONFIG_MACRO_DIR aclocal insisted that it
needs to have a m4 directory. Make it happy by providing one. As git
is not tracking directories I needed to add a dummy file.
This new gprs-conf branch is intended to contain everything needed
to configure GPRS in the nanoBTS, but without implementing the SGSN/GGSN
functionality.
The SGSN/GGSN development will happen in a branch based on this branch
called "gprs-sgsn"
Use the start address inside the header entry, the start is relative
to the surrounding SDP record which is located in our base offset, when
writing it out also ignore four bytes of something (crc?).
* The length of the table is not at a fixed position. We will need
to read the offset, seek there, read the data, convert it to the
host endianes.
* Prepare the code to work with offsets of 0...
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/bin/ld:
Warning: size of symbol `rsl_rlm_cause_strs' changed from 8 in ./openbsc/src/libbsc.a(abis_rsl.o)
to 120 in /usr/local/lib/libosmocore.so
spotted and sent to the list by Andreas
* I'm doing a nonblocking connect and for this I need to select
on writable and the first thing I need to do is to check the
SOL_SOCKET SO_ERROR state. I realize this by setting a different
cb on the embedded bfd during setup and then go back to the real
implementation.
The write queue can be a dropin replacement for the bsc_fd. It
is featuring two callbacks. One for ready read and one for ready
write. Whenever there is a message in the queue the write_queue
will set the BSC_FD_WRITE flag and then call the write callback.
It will make sure to delete the msgb after the write function
has been called. This class is intended to be be used in the
osmocom, layer2, bsc_msc_ip, bsc_hack and other applications.
The are three policies. Accept, Reject and Defer. This will
allow to handle network connections and such from the policy
callback instead of directly acting on it.
In case of a wrongly formatted AUEP, CRCX, DLCX, MDCX the
transaction id pointer was a dangling pointer... Initialize
the transaction id to a static string..
Also fix a off by one bug. We want to extract four elements
from the MGCP message and not only 3... So a short AUEP message
made it us read too many things.
This change separates the protocol from the actual network code
(bind, forward data). This will allow to more easily hook up the
RTP code from OpenBSC and to not use local sockets at all.
The send_ methods stopped to send the MGCP messages but was
changed to actually just create a msgb_ that can be sent to
a mediagateway. Rename the methods now.
In separation of using the MGCP parsing in another context, refactor
the code to operate on a struct mgcp_config, split out the vty code
from the mgcp_protocol.c, and move the callbacks into the mgcp code.
There should be no functional changes.
From now on, you will have to obtain, build and install libosmocore
before being able to build openbsc. Sorry for that. But I hope
it's a small price to pay for having no code duplication with our
work on the phone side GSM stack!
* use pkg-config from openbsc to find header and library
* move sms and timer tests to libosmocore itself
* ensure "make distcheck" works on both packages
This library is intended to collect all generic/common funcitionality
of all Osmocom.org projects, including OpenBSC but also OsmocomBB
The library currently includes the following modules:
bitvec, comp128, gsm_utils, msgb, select, signal, statistics, talloc, timer,
tlv_parse, linuxlist
msgb allocation error debugging had to be temporarily disabled as it depends on
'debug.c' functionality which at the moment remains in OpenBSC
Using msgb->data only works as long as msgb->data == msgb->l2h.. In
the case of receiving a MSU unit from a E1 link, or even receiving
the IPA header we will have some non SCCP data at msgb->data and then
cast garbage to what we think is making sense..
Use msgb->l2h and everything is fine.
* Close the socket when the bind is failing.
* Close the socket when the listen is failing.
* Close the socket then the bsc_register_fd is failing.
* Return an error when the socket call is not returning a socket.
The msgb class is using the debug framework and needs to be able
to output data. We would need a way to add custom areas or to have
the struct of areas outside of the default debug.c... but this can
happen at a later point.
* include <sys/types.h> to have a definition of the u_intX_t types
* include "linuxlist.h" via local includes so it can be found from
the liblaf0rge directory where <openbsc/ does not exit.
Do not directly send data from inside the mgcp_protocol.c
implementation. Instead allocate and return a struct msgb*. The
caller can then either wrap that into the IPA protcol or directly
send it over the UDP socket.
* Call a callback when the endpoint was created, modified or deleted. This
can be used by the BSC MUX to send a MGCP packet over TCP to the right
the BSC to allocate the endpoint there with the right data, or it can be
used in the BSC to send the right commands to the BTS.
* Separate main process and protocol handling into two parts.
* Change the protocol handling to work with UDP and TCP connection
* This will allow to speak MGCP over TCP between the BSC MUX and
the real BSC.
In plain forward mode we don't have DLCX which will clean
and reset the configuration. We will need to remember the
last GSM BTS port and send data to it.
* Do not only check the IP but also the port to figure out
where to send the data
* Do not memset the endp->remote inside the bind_rtp but from
inside the crcx as this will be modified by the MDCX
Rename the variables to refer to the fact that they are
the ports of the remote.
So we have:
rtp_port as the local address we are binding to
net_rtp for the network rtp
bsc_rtp for the bsc rtp
I want to reuse the SCCP code for header parsing in the BSC
NAT to identify data and patch the source local reference. To do
this the current handle_* methods will be changed into two parts
one is strictly parsing the other is handling the parsed data.
If the lchan has AMR as speech codec we also need to send the
multirate config IE in the channel activation. This is already
done for the RSL Channel Modify message.
the unix select function returns a set of file descriptors to be
handled. the result-loop (the loop after the select()) is called again,
if more than one descriptor is removed by the callback funtion. this may
lead to a another call to the callback function, because the bits of the
FD_SETs do not change and still set.
i think we must clear these bits, if they are handled, so the handler
will not be called twice in case of a "restart" of that loop.
The way the VTY configuration sytem works is that it first registers a
BTS of type GSM_BTS_TYPE_UNKNOWN and then sets the type correctly (after
encountering the type statement). This makes sure that registering a BTS
of type UNKNOWN succeeds.
In 39315c4798 we introduced
per-bts OML attribute parser definitions and disallowed
a BTS of type unknown.
However, the VTY code first allocates a BTS with unknown type.
With forward IP in the config and early bind on we will
simply forward RTP data on the endpoints from BTS to the
forward IP address.
This is implemented by disabling MGCP functionality when
a forward IP address was specified, setting the forward IP
in the endp->remote and assigning a ci != CI_UNUSED.
Early bind will make sure the sockets are created, the BSC FD's
are registered and then the normal dispatch code will
do the forwarding.
Some NM attributes are defined differently depending on
the BTS type. Having one big nm_att_tlvdef[] table for
all BTS types is no longer sufficient. This patch
* introduces 'struct gsm_bts_model' to describe a BTS model
* adds definitions of gsm_bts_model for BS-11 and nanoBTS
* changes the abis_nm_tlv_parse() function: include a bts pointer
Currently starting with the opencfg.cfg.nanobts and writing it out
and then trying to start again will not work. The network reject_cause
is initialized to 0 which is not a valid reject reason and when writing
this to the config file and trying to parse it will fail.
Pick roaming not allowed as a harmless option to those phones
accidently trying to connect to the BTS.
These commands let you change the PLL set and work values. Many thanks
to Dieter Spaar for figuring out how to do this!
Now you can just reset your PLL work value if it drifts away due to your
E1 card.
Use it like this: bs11_config pll-workvalue 1000
Whether this function changes the set or the work value depends on your
type of login. In FACTORY login it changes the set value, in FIELD login
it changes the work value (which is what is used by the BS11 to tune the
frequency).
This is useful information to know and actually fixes a segfault
in rllp.c where lchan is accessed even tough it could be NULL in
case of failure.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
At least some nanoBTS 139 send the last even (going online) as
'enabled' 'unlocked' but no avail status IE (which I guess mean an empty
set, the doc 12.21 isn't that clear about that).
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
- One is just to improve the debug prints
- The other fixes a problem in PER encoding found by Dieter Spaar.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Follow up on 424c4f0e29. As pointed out
by Sylvain on the mailinglist I need to remove this here as well.
Do not call db.c code from code that is located in libbsc.a
vty_interface.c is part of libbsc.a but it started to use code
which is found in db.c recently. Fork the subscriber dumping and
provide more information on the layer3+ (MSC) commands. This
is restoring the separation again.
Theses will be useful to know if we can reuse the tuples or if
we should renew. The 'issued' is currently purely informative.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This returns true if the gsm_nm_state can be considered 'running'.
Note that we also accept availability==0xff (which is a code for
no value) because according to 12.21 it is perfectly valid.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
The exact sequence the states the BTS goes through is slightly
different for one of the nanoBTS 139 I have and it needs this
to start.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Thise two functions are interfacing with the 04.08 layer 3 to
determine if a particular message should be handled inside
the OpenBSC layer 3, or if it should be handled in the silent call
handler.
* On start the vty code will call the abis_nm method and this
will set the administrative state to unlock/lock
* During startup the BTS will report its state as well and would
possible overwrite the set administrative. We are only going
to update the administrative if it was 0 before. This appears
to work on all of my tests. In case this will not be the case
for others we will have to split the administrative into two
sets one for the BTS and one for the BSC.
* This is used in sw_load_init and sw_load_end and both needs
to be touche for every BTS. Move it into a common method.
* This was only verified on the nanoBTS.
* Do not issue the restart right aways if we have OML IP or
software load in the queue (hint, we need a real queue of operations
to carry out... with one big state machine)
* Change the signal_data of ipacc ACK/NACK to contain the msg type
and the bts pointer.
* Issue a restart for software load and OML and use the BTS pointer
we got out of the new signal data.
We are filling sw_load1 with the information found with type
0x1000 and sw_load2 with type 0x2001. It appears from the protocol
traces that these information is not extracted from them. We also
need to include the \0 from the string.
With this firmware flashing seems to work.
* text3 seems to be a version as the text content starts
with a 'v'
* move the sdp_firmware into the ipaccess.h and declare
the function. The headers are returned through a list.
* The second magic number is only a short and it is
the same for all of my cases
* This also means that the first and second header
are the same which means the unknown 8 byte are
header and file size... and the 122 bytes are
actually multiple strings (just all empty on the
outermost SDP). Adding the strings left us with 120
bytes so we have two bytes of unknown usage..
* This is now capable of parsing outer and inner SDP
files and print their header.
* The internal SDP appears to have a different magic number
than the first entry and a slightly different packet format
* There are 8 byte of binary for at the beginning and the header
ends with a table pointing to some strings and then the actual
firmware follows.
* We currently only parse the strings of that header.
The something3 points to the next start of the SDP
entry. The four bytes in front of the " SDP" are not
known and just discarded. Prepare to be able to
recursively parse the SDP header...
I must have picked in the wrong section of these
files... There are some kind of header entries
that are all 138 byte long and this is the total
length...
In many cases we actually want a name / unique ID for the lchan,
not just for the on-air timeslot... especially in SDCCH/8 case,
where 8 SDCCHs share one timeslot...
When we allocate a channel, we send the RSL CHAN ACT REQ and wait until we get
a CHAN ACT ACK. Only the ACK will change the state, so there is a race where
we allocate that same channel to a different channel request before we get
the ACT ACK.
Introducing a new ACT_REQ state resolves this issue.
When we have received the End Ack we are just doing nothing as we
are done. This means rc remains -1 and we will print a warning but
there is no need to have a warning...
* The FOM header needs to be different. We need to address the
base station transceiver, bts, trx set to 0 and ts to 255
* We need to transfer the the \0 of 'id' and 'version'
* We need to issue a NM_ATT_SW_DESCR (just the value)
* We need to use 16bit length for the other two ids..
* After this our Software Load Init is getting an Ack.
Strictly speaking we would only need to start the Site Manager
and could probably start flashing afterwards but it is more easy
to have one config path...
This will mostly work like the downloading in bs11_config
and is based on the bs11_config state machine as well. Once
it is working we can see how to unite both implementations.
See GSM 04.11 Chapter 5.4 for details. The idea is that when
multi-SMS are mobile originated, it's possible the CP-ACK of
the previous transaction to be lost and the reception of a
new CP-DATA for a new transaction should close previous transaction
"as-if" we had received the CP-ACK ...
Note that testing is hard since it's an exceptional condition that's
hard to create. I tested by temporarly disabling CP-ACK processing
and checked it worked as expected.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
The current code used the variable bitmap format, but
that's not possible since in this format the base ARFCN is
part of the set. That lead to a neighbor list containing ARFCN 0.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
We need transaction_id to be a int (as returned by trans_assign_trans_id)
to detect the error condition -1.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
The idea is to find the highest used id and try to get the
next. This way when there are transactions back to back with
an overlap, we go 0 1 2 3 4 5 6 0 1 2 ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This marks the departure from printing all the debug messages to the console by
default. We only print NOTICE and WARNING level messages by default
If you're interested in more details, you need to enable it via command
line options or the VTY
The VTY code makes so many allocations that a full report is
simply too long to provide any useful information. So we sub-divide
it in multiple contexts, and report only one level deep at SIGURS1.
We also introduce SIGUSR2 for the full detailed VTY report.
In case we have multiple TRX configured, but not all of them are
actually active/operational, we should not try to allocate channels
from such transceivers.
This proxy allows us to restart OpenBSC while the BTS's are kept
running with their CCCH/BCCH alive. This is very useful to
make sure the phones don't roam to other networks while restarting
OpenBSC.
The proxy also intrduces UDP sockets for injecting UDP packets
into the A-bis data stream.
So far I have not much idea about the format. It is starting with
the magic byte and the header is spanning until the next occurence
of the " SDP" marker.
The magic " SDP" is occuring twice in the file. The first time
seems to be the file header and the second time it is with the
payload. We will need to parse this somehow...
* The two version strings are not in an easy to parse header
and from my trace it appears like the whole file is sent
to the BTS. So just open the firmware file..
Change the counters_store_db function to be a generic for_each
function taking a function pointer and data. Use that in bsc_hack
to store it to the DB.
This is removing the DB requirement and will allow to handle
the counter values in different ways without making the counter
list public.
I verified that the syncing is still taking place.
This is the new logging architecture, including
* support for multiuple logging targets like stderr and vty
* log levels in addition to categories/subsystems
* filtering based on imsi, i.e. only see events for one subscriber
* dynamically change log level for each category for each vty
This has the advantage that counters can be added all over the code
very easily, while having only one routine that stores all of the
current counter values to the database. The counters are synced
every 60 seconds, providing relatively fine grained statistics
about the network usage as time passes by.
Tweaking theses can be useful especially tx-integer that influence
both the spread of rach attemps and the delay between two attemps.
Looking up GSM 04.08 3.3.1.1.2 & 10.5.2.29 can help determine good
values. The default are choosed with a wide spacing between attemps
(tx integer = 9 -> T=12 & S=217 (non-combined CCCH/SDCCH) or 115 (for
combined CCCH/SDCCH)). This alleviates the problem of responding to
several RACH attempts by a same MS, allocating several RF channels when
only 1 is needed.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
The previous implementation had some shortcomings:
- If the MIN ID given was not the exact id of the first unsent SMS,
it would try to submit the same sms several time until id++ finally
made id go to the next one.
- If a subscriber had several SMS pending it would try to submit
them individually (only to get rejected because a paging for that
subscriber was already in progress)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
