| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
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 next step in the way to the BSC API. We have a clear a
new connection was opened signal now... and the MSC could
use it...
|
|
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.
|
|
|
|
|
|
|
|
|
|
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...
|
|
If there is a connection, return before paging... otherwise
we will delete the SMS twice.
|
|
|
|
|
|
Directly send a SMS using the send method, in case of an error
we will need to find the transaction and free the SMS and the
transaction.
|
|
Sometimes we need to free the SMS, sometimes also the transaction.
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
Remove further usage of lchan from the gsm 04.11 bits
|
|
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.
|
|
Prepare to split the BSC and the MSC part by putting the
MSC data for a connection into a "gsm_subscriber_connection"
struct and renaming the macros.
|
|
|
|
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
|
|
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>
|
|
This ensures that we don't re-use the same transaction ID.
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>
|
|
|
|
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.
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
the statistics will give us some idea about the network load and
performance.
|
|
TP_VPF_ENHANCED - not in TP_VPF_ABSOLUTE
|
|
'unknown' has a negative connotation for a case that's totally
normal so refer to it as 'new' so it doesn't sound like a problem.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
In SMS debug messages, we always display the transaction ID
as if we were 'sending' the message.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
|
|
While doing so, we also restructure/reorganize the vailidity period
parsing in general.
|
|
|
|
- Added function "gsm340_scts" to decode the service center time stamp
into a UTC/GMT timestamp
- in function gsm340_validity_period: can now decode validity period
format absolute.
|
|
|
|
When only one SMS is sent, the freeing of the lchan will
automatically free all transactions on the lchan.
However, if there are several SMS sent at once, the call
to gsm411_send_sms_lchan will create a new transaction
with the same caracteristics as the previous one. If
the old one is not free'd, the next call to trans_find_by_id
(triggered by the next incoming RP-ACK) will not return the good
transaction and things go haywire.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
|
