Age | Commit message (Collapse) | Author | Files | Lines |
|
Pass the number of bytes the rest octet for si4 should
fill. We will need to include info for CBCH in our SI4.
WIP: SMSCB... this should reuse the lchan2desc if it works...
smscb: Add vty command for experimentation...
|
|
custom l3 message....
|
|
The transaction layer was stopping paging requests that might or
might not have been owned by the transaction. This makes the subscr
code get stuck delivering requests. This code is mostly a band aid
and just makes sure that we will kick the queue if it is needed.
|
|
Remember if this channel got opened due a paging response and in
that case when we close it down we will call subscr_put_channel
that will try to page the subscriber again. This highlights the
lack of a good subscriber management in the MSC code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If one paging request is timing out the others will timeout soon
as well. With the current code the next timeout would expire the
next request in the queue. We will now stop all paging requests
and then issue a next paging request. So for both paging success
and failure we will now stop all the other requests.
This is mostly a workaround, one should count on how many
BTSes we are paging and wait for all failures before we remove
the item from the queue.
|
|
Kick the queue in case the paging was timing out. No one is going
to call subscr_put_channel for us so we will do it on the subscriber.
There is also another problem with multiple BTS in the LAC and paging
timeout. We will need to remember how many BTSes we have paged.
|
|
According to the specs (GSM 04.08 Table 9.9), the only possibility
if neci=1 and this cause is used is "Originating call and TCH/F is
needed"
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
If we have a RF failure between the paging response and the auth
success we will not inform the subscriber layer of the failed paging
and instead just 'drop' the SMS. In case we have not completed the
auth and close the channel we will now send an auth failure.
|
|
|
|
|
|
|
|
The conn might be released during the loop and then conn->bts
is a null pointer and we end up crashing. Store the gsm_network
in a local variable and access this one.
|
|
The active channel might or might not be gone when the transaction
has been released. Instead of passing an invalid subscriber conn
we will pass the subscr that is ref-counted and guranteed to be
valid at this point. subscr_put_channel could search the connections
for an active connection if that is ever needed.
|
|
Improve the debugging possibilities and print the failed attempts
and the sms that was attempted to be delivered. this should help
with debugging the code.
|
|
|
|
In contrast to the previous believe we may not have a conn here
as we are still paging for the sub. Instead of printing the BTS
print the lac where we think the subscriber is located.
|
|
Follow trans->conn->lchan to the BTS instead of using the BTS that
is guranteed to be NULL in the codepath we have entered here. The
trans->conn should still be there, and the lchan should be valid as
well as we have reordered the clear statements.
|
|
|
|
When the new_lchan for handover is failing we should stop the
handover operation. This is fixing a crash that we get a timeout
on the lchan and have no conn set to it. Introduce a flag to
the bsc_clear_handover to not free the lchan. In case the ho_lchan
is failing we do not want to call lchan_release as it would
reset the state.
|
|
The SS_LCHAN signals now always include the lchan_sig_data. For
the measurement report it will optionally include the measurement
report as well. Attempt to update all handlers of this signal as well
|
|
Check the signal and only continue if it is any of the
signals we want to handle. In the case of measurement
reports we would cast some random code to a lchan.
|
|
The release might release the lchan we want to send the response
on. Reorder the code to first send the message and then give up
the security operation which might release the lchan.
|
|
If someone wants to send a message but we have no lchan anymore
we will now complain, delete the message and return.
|
|
|
|
|
|
This should make sure conn->lchan is valid throughout the release
cause, especially make trau_mux_unmap() happy that conn->lchan
still exists.
|
|
|
|
|
|
|
|
In case we get a RA UPD REQ on a new cell (both served by the same
SGSN), the LLC stack should not allocate a ne LLE/LLME, as the latter
would reset the V(u)sent / V(u)recv to zero and make the MS discard
our responses.
Instead, whenever the LLC stack sees a foreign TLLI, it should always
convert it to the local TLLI before doing any lookup for a LLE/LLME.
|
|
|
|
We create a loop by not setting trans->callref = 0 before calling
trans_free(), as the latter would again send a MNCC_REL_IND up
the stack.
Also: Fix memory leak in case we try to read from mncc_sock
but socket is just gone.
|
|
|
|
|
|
This adds mncc_sock_from_cc() as a handler function for CC messages
to be passed to the MNCC interface. If there is no MNCC socket
registered, we immediately release any CC related messages.
Together with flushing all established CC transaction at MNCC socket
close time, this ensures that all resources are released and no
new resources can be established until the MNCC applicaiton has
re-attached.
|
|
this is required as we no longer have a dequeue-handler that can take
care of free()ing the message after passing it to the MNCC handler.
|
|
|
|
|
|
|
|
The MNCC messages now again get directly handled by the net->mncc_recv()
callback. If the callee wants to put them in a queue, it' his business
to do that.
|
|
|
|
Using this code we will soon be able to use LCR or other MNCC
applications via a unix domain socket.
The code is not actually used yet after this patch.
|