| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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..
|
|
We need to simulate OML/RSL failure in an easy and fast way
and adding a command to do so seems like a good way to achieve
this. The command is a bit misplaced, in one way it is no config
and does not belong into the config node but then again it does
not belong into the VIEW_NODE either as it is manipulating content.
|
|
The refcount should drop to zero immediately and then the
msc_data would be reset automatically but it is better to
remove all traces of it right away.
|
|
|
|
We will handle sending the assignment failure inside the T10
timer but it is better to reset the secondary_lchan inside the
msc_data right away before we might accidently use it.
|
|
1.) when we do get a assignment failure from the MS. It is coming
on the old channel and not the new one. Fix the comparison. Also
always reset the msc_data to NULL before dropping the reference
2.) the LCHAN signal handler in bssap.c claims that the T10 expire
cb should free the secondary channel. It currently does not do
it and we have to do it now...
the whole thing was not tested and even after this commit this
behavior is not heavily excercised... with OsmocoreBB we would be
able to do this in the future.
|
|
Use the oppurtunity to flag errors as errors in the code
base.
|
|
|
|
It appears to be possible that we attempt to submit a DTAP
on a SCCP connection when we have a channel without the msc_data
assigned. This change should fix the crash (which is not well
understood), fix a memleak in the case of the queue being full.
|
|
data_len is wrong as well as we have reserved... specifying
it directly seems to make valgrind happy. This also means that
we might receive more than one UDP message and do not properly
forward things. I will need to investigate.
|
|
Increment the counter before we call the remove request
which is freeing the request...
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
We do not want to send a msg over the NULL lchan. Let us
return fast from here.
|
|
We are storing the bound_ip in host byteorder but when
using ntohl we need to convert it back to to network
byte order.
|
|
|
|
|
|
Sending the reset right away will upset the MSC and we
need to wait for the first contact.
|
|
|
|
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.
|
|
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.
|
|
The rest of the code should filter the reset ack msg. This should
make the MSC give up all resources it had allocated for us.
|
|
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.
|
|
|
|
|
|
|
|
* Move to the new log code and update binaries
* Catch up with lchan changes from master
Conflicts:
openbsc/include/openbsc/Makefile.am
openbsc/include/openbsc/gsm_data.h
openbsc/src/Makefile.am
openbsc/src/bsc_rll.c
openbsc/src/chan_alloc.c
openbsc/src/debug.c
openbsc/src/gsm_04_08.c
openbsc/src/gsm_04_11.c
openbsc/src/gsm_subscriber_base.c
openbsc/src/handover_logic.c
openbsc/src/silent_call.c
openbsc/src/transaction.c
openbsc/src/vty_interface.c
openbsc/src/vty_interface_cmds.c
|
|
|
|
This is fixing a segfault due calling bsc_unregsiter_fd twice
without being in the list.
|
|
Check if we do have the msc_data before invoking code in
bssap.c. We might have lost the MSC connection and asked
for the channel to be taken down but we might have received
one last message from the BTS.
|
|
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 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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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.
|
