| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The reason for this is quite simple: We want to make sure anyone
running a customized version of OpenBSC to operate a network will
have to release all custom modifiations to the source code.
|
|
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.
|
|
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>
|
|
|
|
|
|
In case we fail to activate the lchan set the connection to
NULL before calling the lchan release function.
|
|
|
|
|
|
If the GGSN restarts, its restart counter will increase. We can
detect that and accordingly release/delete all PDP contexts for
that GGSN.
|
|
|
|
|
|
With the old code it was possible that we first saw SMS that
we have already in the queue. In that case we had free slots
available but have not filled them. With his new loop we try
harder to find SMS we can send, it attempts (and should work)
to detect a loop to break the loop before finding SMS to deliver.
|
|
Prepare changing the loop to fill all the available slots. Set
the last subscriber based on the SMS query.
|
|
Increase the number of SMS we will try to send at a time and
decrease the failures we handle before going to the next item. With
the default timeout we will attempt to page the subscriber for 60
seconds and we can increase the queue speed by going to the next
item faster.
|
|
The sync with the database might fail. Reread the updated
subscriber after we have written it. The source of this
failure is unknown.
|
|
This is also fixing a memory and subscriber leak. Make sure to
always release the gsm_sms structure.
|
|
|
|
|
|
|
|
Make it possible to change the max pending via the vty. This
can be useful to play with the performance of the queue.
|
|
Allow to manually trigger running the queue. This can be useful
if SMS were manually added to the database or such.
|
|
|
|
The sms queue will attempt to send one SMS per subscriber
to fill all the available slots. It will handle the case
where paging has not started, timed out or if there was
any kind of other failure. It is also retransmitting SMS
in case of failures.
|
|
The SMSqueue will be responsible of sending to the user. It will
do so in a loop and will also try not to overload the BTS. This
means the throughput of SMS will be limited.
|
|
This is providing access to the paging result, the sms,
the transaction. This will allow the SMS queue to do
decisions based on the source of the failure.
|
|
This attempts to dispatch a signal whenever a MT-sms is failing. In
some cases, e.g. with freeing the transaction, this will also happen
for MO-sms.
|
|
The signal_data was inconsistent. Sometimes we passed the transaction
and sometimes we passed the sms. Change it to always pass the sms. The
S_SMS_SMMA is a bit special as it does not involve any SMS.
|
|
This will proble all queries done in the system. This can
help to identify some issues with libdbi's performance.
|
|
This is generating the query statement. It can be used to
play with database indexes and such.
|
|
This is creating 1000 subscribers and 30 SMS each. The SMS
itself is badly formatted (not a valid 7bit encoding) but
it should be enough for a stress test.
|
|
|
|
We do not want to attempt submitting SMS that has failed for
too many times. The failure could be due RF failure or due
a bug in the message handling.
|
|
|
|
If a signal handler accesses the database he will still see
the old lac. Make sure he is seeing the new one. Update the
subscriber from the database in case the query failed or other
things have changed.
|
|
|
|
Start counting the attempts of each paging request and call
the callback with the PAGING_BUSY type when the paging request
timed out but the subscriber was not paged at all. This can
only happen with a huge paging backlog.
In case the system has so many pending paging
|
|
|
|
Call the subscr_purge_inactive function and mention how many
subscribers were removed from the RAM.
|
|
|
|
Introduce a method that will remove all subscribers that have a
zero use count. This is useful if someone wants to purge subscribers
from memory or wants to disable the everything in RAM feature.
|
|
This is implemented by not freeing the subscriber when the
reference count becomes smaller than zero. We hope that this
will save many database accesses during the congres.
|
|
The existing call realated statistics counters apparently were
never used. This introduces a new set of counters, two for the
MO and MT case.
|
|
|
|
As we do not yet use the HLR from the SGSN, we allow all MS to
attach to our GPRS network. However, if this is running in a public
environment, it could cause service interruption to users of commercial
GPRS networks.
Thus, we now check if the first 5 digits of the IMSI match the MCC/MNC
of the cell that they want to register to. Thus, any subscribers with
SIM cards from real operators will no longer be accepted.
|
|
LOGL_ERROR will make this message shpw up in everey default log
config. However, as it seems, this is commonly observed in case
a MS still sends a MS STATUS (in respons to the MM INFO) at the
end of a location area update.
It might be best to actually change the channel release procedure
to make sure we can still pass such 'late' data to the MSC until
the time the Layer2 has been completely released.
|
|
|
|
|
