| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This currently shows that the LLME will remain allocated and
never be freed.
|
|
On a Detach/Re-attach cycle the Address Sanitizer detected a
use-after-free kind of problem. That is because we tried to
destroy the LLME twice. The first time it is destroyed as part
of the Detach handling ans the second time it is destroyed as
part of destroying the old MM context.
In case the GPRS GMM detach message is lost the SGSN needs
to reply besides not having a MM entry.
The alternative would have been to add NULL checks for all
usages of ctx->llme which would not have helped with the
readability.
Sponsored-by: On-Waves ehf
|
|
On detach the LLME get's unassigned (and hence destroyed) but the
GMM context will still point to that dead structure.
|
|
On an "unassignment" this code verifies that the LLME will vanish
from the list of LLMEs. We assume that this doesn't create a
memory leak.
|
|
|
|
For jitter, transit and packet loss we should count the data
that arrived and not the data we send towards the remote. This
is changing the jitter timings to what they were before the
re-factoring.
For forced timing we might willingly add jumps in the sequence
number but for jitter and packet loss we are more interested
in the data that traveled through the wire/air.
|
|
The Annex A code has a probation period but we don't have it. When
starting with seq_no==0 do not assume that the sequence numbers
have wrapped. Do it by moving the entire checking code into the
else.
|
|
mgcp_patch_and_count has grown due supporting linearizing timestamps,
ssrc and other things for equipment like the ip.access nanoBTS. Fight
back and move the Annex A code into a dedicated method.
The result is updated as we now count after all the patching and for
the Annex A code no change in SSRC can be detected.
|
|
|
|
|
|
Before the old code allowed to specify "timeout-ping bla" which
would be parsed as '0' which would trigger a flood of pings. Use
the VTY code to parse it as a number.
|
|
Fixes: CID#1240205
|
|
Many log levels were DEBUG without any good reason. Also where possible
the details of the MM or PDP context are now logged with LOGMM/PDPCTXP.
|
|
|
|
Currently when gprs_llgmm_reset() is invoked an XID reset is sent but
the local LLC parameters (e.g. V(U)) are not cleared (see GSM 04.64,
8.5.3.1). This can lead to discarded messages on the SGSN side.
This patch modifies gprs_llgmm_reset to clear vu_send, vu_recv,
oc_ui_send, oc_ui_recv.
Sponsored-by: On-Waves ehf
|
|
Currently the SGSN side message's TLLI are searched without checking
the originating SGSN. This leads to collisions if both SGSN use the
same P-TMSI for different MS.
With this patch, the SGSN NSEI is stored within the tlli_info and is
used in comparisons to separate the namespaces.
Note that this type of collision cannot happen with BSS numbers,
since the tlli_info are already separated and stored per (BSS) peer.
Sponsored-by: On-Waves ehf
|
|
This patch extends test_gbproxy_secondary_sgsn() by the establishment
of a third MS connection using a P-TMSI that has been assigned by the
other SGSN already. It is expected that the entries do not
interfere and are properly retrieved.
Note that these collisions are not handled properly yet.
Sponsored-by: On-Waves ehf
|
|
At one place, the reply to the second Ident Req contains the wrong
IMSI. That is fixed by this patch.
Sponsored-by: On-Waves ehf
|
|
Currently it is possible to create serveral entries referring to the
same P-TMSI/TLLI by using P-TMSI assigment via Attach Accept or
RA Update Accept messages. This can lead to the use of the wrong
tlli_info.
This patch adds gbproxy_remove_matching_tllis() that removes all
conflicting entries. This function is called after the P-TMSIs and
the resulting TLLIs has been set up.
Sponsored-by: On-Waves ehf
|
|
This tests P-TMSI assignment when P-TMSI patching is disabled. A test
with colliding P-TMSI in Attach Accept messages is included.
Note that P-TMSI collisions are not handled properly yet.
Sponsored-by: On-Waves ehf
|
|
Since this message puts the MS into DEREGISTERED state (like a detach
procedure), this message is parsed and the invalidate_tlli field is
set accordingly.
Sponsored-by: On-Waves ehf
|
|
This commit adds/modifies the following VTY commands:
- delete-gbproxy-tlli <NSEI> de-registered : Delete all
de-registered entries
- show gbproxy tllis : Display 'DE-REGISTERED' when appropriate
In addition, the implementation of the delete-gbproxy-tlli command
has been split into two functions (with and without TLLI/IMSI
value).
Sponsored-by: On-Waves ehf
|
|
gprs_gb_log_parse_context() uses a sequence of LOGP calls to compose
a single message line. This leads to cluttered log output.
This patch replaces all but the first LOGP applications in this
function by applications of LOGPC.
Sponsored-by: On-Waves ehf
|
|
Currently it is possible to create several tlli_info entries with the
same IMSI.
This patch disables this by adding a check before the imsi field
is updated.
Sponsored-by: On-Waves ehf
|
|
Currently a tlli_info entry is deleted when the TLLI gets invalidated
by a Detach message.
This patch introduces the possibility to keep tlli_info entries in
the list. Those entries then have cleared TLLI fields, are marked as
de-registered, and can only be retrieved by a message containing an
IMSI or a P-TMSI.
The following VTY configuration commands are added to the gbproxy
node:
- tlli-list keep-mode never : Don't keep the entries (default)
- tlli-list keep-mode re-attach : Only keep them, when a Detach
message with re-attach required has been received
- tlli-list keep-mode identified : Only keep entries which are
associated with an IMSI
- tlli-list keep-mode always : Keep all entries
Note that at least one of max-length or max-age should be set when
this feature is used to limit the number of entries.
Sponsored-by: On-Waves ehf
|
|
Currently when patching is basically enabled P-TMSI and TLLI gets
patched even when P-TMSI patching is not enabled. Albeit the result
is correct in this case (the same value is re-written), the counter
shows unexpected results.
This patch adds configuration checks for P-TMSI and TLLI patching. It
also reorders the code of gbproxy_patch_raid to return early if there
is nothing to patch.
Sponsored-by: On-Waves ehf
|
|
This test case consists of a sequence of several attach and detach
procedures. The kind of detach varies (mobile originated, mobile
terminated re-attach required, mobile terminated re-attach not
required, routing area update reject). To main focus is to check that
the tlli_info is de-registered correctly (not accessible via the
TLLI) and that can be re-used afterwards (which is not implemented
yet).
Sponsored-by: On-Waves ehf
|
|
This function is a remainder of the initial implemenation that was
not meant for TLLI patching and can be used for the BSS side only.
The SGSN side is already using a composition of more flexible
single purpose functions.
This patch changes the implementation to use a similar approach. The
function is moved to gbproxy_test.c and renamed to register_tlli to
keep the tests intact.
Sponsored-by: On-Waves ehf
|
|
If IMSI acquisition is enabled and the gbproxy receives a Detach
request from the MS, it cannot pass it to the SGSN since the
acquisition has not yet been completed.
This patch implements the generation of a Detach Accept message and
for this case and updates the TLLI state accordingly.
Sponsored-by: On-Waves ehf
|
|
Currently the RAI in the LLC part of the message is not updated if
the message has been taken from the list of stored messages. The
reason is, that old_raid_matches is update in
gbprox_process_bssgp_ul() but not in gbproxy_flush_stored_messages().
This patch moves the check to gprs_gb_parse_bssgp() which is called
at both places and where other fields like parse_ctx->tlli are set,
too.
In addition, old_raid_matches is replaced by old_raid_is_foreign
since this is clearer in the case when there is no old RAI at all.
Several RAI patch counter assertions are also added to
test_gbproxy_ra_patching().
Sponsored-by: On-Waves ehf
|
|
Add a Attach Request message to test_gbproxy_ra_patching, where the
BSSGP RAI differs from the old RAI signalled in the LLC part. This
case had not been tested explicitely yet.
Change the RAI in the first Attach Request in
test_gbproxy_imsi_acquisition from rai_unknown to rai_bss.
Add Detach Requests to test_gbproxy_imsi_acquisition, one for a
incomplete attach procedure and one for an unknown (fresh) TLLI.
In these cases, the acquisition of a IMSI is not necessary and also
doesn't work properly with an E71.
Sponsored-by: On-Waves ehf
|
|
Since at all places where mi_data/mi_data_len is used it will always
contain an IMSI. Thus the names of the identifiers have been updated
accordingly for clarity.
Sponsored-by: On-Waves ehf
|
|
This commit changes gbproxy_imsi_acquisition as follows:
tlli_info->mi_data_len is used instead of parse_ctx->imsi to check,
whether the IMSI is known already. Since the function is always
called after gbproxy_update_tlli_ul(), the two values are already
synchronized.
Messages are always flushed when the IMSI gets known, if the current
message is IDENT RESP discard it, otherwise continue processing as
usual.
The 'if' clauses are simplified for better readability.
Sponsored-by: On-Waves ehf
|
|
gbprox_process_bssgp_ul has grown quite large mainly by the addition
of IMSI acquisition.
This patch moves that code into several smaller functions. In
addition, the peer resolution which is similar to that in
gbprox_process_bssgp_dl is moved into a separate function, too.
Sponsored-by: On-Waves ehf
|
|
This allows us to know what number of messages and bytes has been
received per active osmux endpoint.
Note that an Osmux message is composed of several chunks. Each chunk
contains an osmux header plus several voice data frames.
P: PS=385, OS=11188, PR=195, OR=5655, PL=0, JI=49
X-Osmo-CP: EC TIS=0, TOS=0, TIR=0, TOR=0
X-Osmux-ST: CR=51, BR=3129
The new 'X-Osmux-ST:' notifies the received chunks and bytes.
|
|
The PCAP option doesn't seem to work for TCP/IP based BTS. Don't
mention it to not confuse people that search for a way.
|
|
Use struct mgcp_rtp_end statistics to account the RTP messages
that has been extracted from the osmux batch and transmitted.
|
|
This patch removes the patch_mode feature including the related VTY
command patch-mode. Where sensible, the other configuration flags are
queried instead.
In addition, this initial checks in gbprox_process_bssgp_dl() and
gbprox_process_bssgp_ul() have been updated.
The patch mode feature has not been used and was increasingly
difficult to maintain.
Sponsored-by: On-Waves ehf
|
|
This patch add explicit tests for
- gbproxy_peer_by_bvci
- gbproxy_peer_by_nsei
- gbproxy_cleanup_peers
- gbproxy_peer_by_rai
- gbproxy_peer_by_lai
- gbproxy_peer_by_lac
and for messages with an unknown TLLI sent by the SGSN.
Sponsored-by: On-Waves ehf
|
|
Currently the stored messages are only removed, when IMSI acquisition
has succeeded. In addition, receiving two ATTACH_REQ messages in
sequence (e.g. due to loss of a Identity Req/Resp message) will not
restart the IMSI acquisition procedure.
This patch adds gbproxy_tlli_info_discard_messages() to clean up the
message list and calls it from gbproxy_delete_tlli() fixing a
potential memory leak. It is also called when an Attach Request
message has been received. In that case the imsi_acq_pending flag is
cleared, too. This would (re-)trigger the IMSI acquisition procedure
at each of these messages. If an Ident Response has been lost,
resending the Ident Request with the same N(U) will not work.
Therefore the N(U) gets incremented on each Ident Request generated
by the gbproxy. The first N(U) used is 256 which shouldn't collide
with the V(UT) used by the SGSN given that P-TMSI patching is enabled
(since a new random TLLI is used initially on every new (no
tlli_info) connection and V(U) starts with zero then).
Ticket: OW#1261
Sponsored-by: On-Waves ehf
|
|
If the Attach Request procedure gets restarted e.g. because of a lost
message, all of these messages are stored if IMSI acquisition is in
progress.
This patch adds a test for this case and modifies the dump_peers
function to output the number of stored messages.
Note that the number of stored messages currently increases with each
(repeatedly) received Attach Request which is not the desired behaviour.
Sponsored-by: On-Waves ehf
|
|
Currently, a new P-TMSI within an Attach Accept or within an RA
Update Request is applied to the TLLI mapping (gbproxy_reassign_tlli)
_before_ patching is done. This can lead to inconsistent behaviour
when the TLLI validation has not been completed, which is the case
when subsequent RA UDP REQ are received. The new TLLI must not be
applied to the message itself yet, it should only be considered for
following messages.
This patch moves the TLLI reassignment to
gbproxy_update_tlli_state_after() to fix that.
It also separates the implementation of the feature that a new
tlli_info can be created when such a message is received from the
SGSN. This makes sense, when P-TMSI patching is not active and the
tlli_info entry has expired.
Sponsored-by: On-Waves ehf
|
|
Currently tlli_info are created for SGSN originated messages when
the SGSN TLLI cannot be found and P-TMSI patching is active. This
doesn't make much sense, since the BSS side TLLI is not known in this
case. Given that the SGSN is working properly, that can only happen
if either the tlli_info has expired or the gbproxy has been
restarted.
This patch disables the creation of a tlli_info in this case.
Note that these messages are passed unmodified to the MS so far.
Sponsored-by: On-Waves ehf
|
|
This adds a sequence of two RA update procedures to
test_gbproxy_ptmsi_patching(). Each of them assigns a new P-TMSI.
Note that the implementation fails to patch the RAI within the
message labelled 'RA UDP ACC (P-TMSI 3)' and logs 'TLLI sent by the
SGSN is unknown'.
Sponsored-by: On-Waves ehf
|
|
Since the secondary SGSN selection and APN patching can both be
enable/disabled by IMSI matching, this patch introduces a separate
match-imsi command and removes the corresponding variant of the
core-access-point-name command.
P-TMSI patching and IMSI acquisition are enabled/disabled by
match-imsi resp. secondary-sgsn. The patch-ptmsi and acquire-imsi
commands are still available for internal testing but are subject to
being removed.
Sponsored-by: On-Waves ehf
|
|
This patch extends the 'show gbproxy tllis' command to display the
number of stored messages per tlli_info if there are any.
Sponsored-by: On-Waves ehf
|
|
Currently all STATUS messages coming from the SGSN are just logged
and dropped. This prevents the PCU from recognising that the
(secondary) SGSN doesn't know about a certain BVCI and might require
a reset procedure.
This patch changes gbprox_rx_sig_from_bss() to forward STATUS
messages with cause "Invalid BVCI" containing a BVCI to the BSS.
Note that this will not forward broken "Invalid BVCI"
messages which do not include a BVCI IE.
Sponsored-by: On-Waves ehf
|
|
Currently the gbproxy sends STATUS messages that are not compliant to
GSM 08.18, 10.4.14.1: The BVCI must be included if (and only if) the
cause is either "BVCI blocked" or "BVCI unknown".
This patch adds a missing BVCI to UNKNOWN_BVCI and BVCI_BLOCKED
status messages if the BVCI is available. Otherwise, INV_MAND_INF is
used instead.
Sponsored-by: On-Waves ehf
|
|
Currently the numeric TLLI or tlli_info's enable_patching flag is
used to decide, whether a APN shall be patched or the secondary SGSN
shall be used. Using the numeric TLLI imposes a problem, when
TLLI/P-TMSI patching is used, since gbproxy_check_tlli uses the BSS
side TLLI namespace when trying to get the tlli_info.
This patch modifies the gbproxy_check_tlli() function to accept a
tlli_info pointer instead of a numeric TLLI. The tlli_info is already
available when the function is called. Since this a similar approach
has been used by accessing the enable_patching flag directly, this
commit unifies checking by always using this function instead of the
flag outside of gb_proxy_tlli.c.
This fixes the APN patching that doesn't work currently when P-TMSI
patching is enabled.
Sponsored-by: On-Waves ehf
|
|
This commit adds a single ACT PDP CTX REQ message to
test_gbproxy_ptmsi_patching() to check whether APN patching works in
this case, too.
Note that this doesn't work currently, the APN patch count is not
incremented.
Sponsored-by: On-Waves ehf
|
