Make the llc_default_params structure from which data is initialized
large enough. Otherwise address sanitizer complains with out-of-bounds
reads.
Only SAPIs 1, 2, 3, 5, 7, 8, 9, 11 are defined for GPRS but the
struct gprs_llc_llme includes NUM_SAPIS lle's and they are populated
from the llc_default_params structure.
Currently LLC parsing is part of gprs_llc.c which needs large parts
of the SGSN code parsing to fulfill its link dependencies.
This patch moves the functions that just do plain parsing, dumping,
and FCS computation to a different file to avoid these dependencies
if LLC stateful processing is not needed. It also exposes
struct gprs_llc_hdr_parsed and enum gprs_llc_cmd publically.
Sponsored-by: On-Waves ehf
CC gprs_llc.o
gprs_llc.c: In function ‘t200_expired’:
gprs_llc.c:322:2: warning: enumeration value ‘GPRS_LLES_UNASSIGNED’ not handled in switch [-Wswitch]
switch (lle->state) {
^
gprs_llc.c:322:2: warning: enumeration value ‘GPRS_LLES_ASSIGNED_ADM’ not handled in switch [-Wswitch]
gprs_llc.c:322:2: warning: enumeration value ‘GPRS_LLES_REMOTE_EST’ not handled in switch [-Wswitch]
gprs_llc.c:322:2: warning: enumeration value ‘GPRS_LLES_ABM’ not handled in switch [-Wswitch]
gprs_llc.c:322:2: warning: enumeration value ‘GPRS_LLES_TIMER_REC’ not handled in switch [-Wswitch]
gprs_llc.c: In function ‘gprs_llc_hdr_rx’:
gprs_llc.c:564:2: warning: enumeration value ‘GPRS_LLC_NULL’ not handled in switch [-Wswitch]
switch (gph->cmd) {
^
gprs_llc.c:564:2: warning: enumeration value ‘GPRS_LLC_RR’ not handled in switch [-Wswitch]
gprs_llc.c:564:2: warning: enumeration value ‘GPRS_LLC_ACK’ not handled in switch [-Wswitch]
gprs_llc.c:564:2: warning: enumeration value ‘GPRS_LLC_RNR’ not handled in switch [-Wswitch]
gprs_llc.c:564:2: warning: enumeration value ‘GPRS_LLC_SACK’ not handled in switch [-Wswitch]
gprs_llc.c: In function ‘gprs_llc_rcvmsg’:
gprs_llc.c:791:23: warning: unused variable ‘udh’ [-Wunused-variable]
struct bssgp_ud_hdr *udh = (struct bssgp_ud_hdr *) msgb_bssgph(msg);
^
gprs_llc.c: At top level:
gprs_llc.c:311:13: warning: ‘t200_expired’ defined but not used [-Wunused-function]
static void t200_expired(void *data)
^
gprs_llc.c:337:13: warning: ‘t201_expired’ defined but not used [-Wunused-function]
static void t201_expired(void *data)
In case we have access to the context verify that the selected
msgb_tlli is either the old_tlli or the tlli in either local or
foreign format. It is wrong to use any other TLLI.
Attempt to solve what f0901f0067 tried to
solve without breaking the case of someone with a foreign TLLI from a
different network.
Lookup with the foreign TLLI converted to a local one in case we did
not find the TLLI and only then create a LLE/LLME on the fly for the
RX path.
During the GPRS Attach procedure we might have a foreign tlli and
in the RX create a LLME on the fly for this tlli. The GMM GPRS
Attach handling code will then assign a new TLLI and keep the
foreign tlli as the llme->old_tlli.
When the GMM is sending the identity request the msgb_tlli will
point to the foreign tlli. The GPRS LLC code will then try to find
that foreign tlli but due the conversion this will not be found.
Instead a new ad-hoc LLE/LLME will be created on the fly for
each message (this means there are duplicate LLE/LLMEs in the
list).
Make the code more strict and remove the tlli_foreign2local change
from the look-up routine. This will make the GPRS LLC code find
the right LLE/LLME and the N(U) will be handled correctly.
This partially reverts:
f0901f0067
Addresses:
<0012> gprs_llc.c:773 LLC RX: unknown TLLI 0xadf11820, creating LLME on the fly
...
<0012> gprs_llc.c:357 LLC TX: unknown TLLI 0xedf11820, creating LLME on the fly
Reproducable:
Use pcu_emu (gprs attach) and observe with wireshark.
In some situations (like MS reboot without prior DETACH or SGSN reboot
without prior MS detach), the LLC sequence numbers for UI mode could
be different on both sides.
The LLC spec unfortunately doesn't permit us to send something like a
FRMR in this case, but instructs us to silently discard the frame. At
that time the remote LLC entity will re-transmit the frame with the same
seqeunce number over and over again, which we will drop again and again.
The mthod used now will keep track of the last received UI sequence
number. If that number is retransmitted for three times in a row, then
we accept this sequence number and recover from that point on.
Instead of direct function calls to individual functions, we now
generate primitives (osmo_prim) and send them to one
application-provided function "bssgp_prim_cb()"
GSM 04.64 8.4.2 asks to ignore UI frames if the DLCI is not known,
or if the "(V(UR)- 32) <= N(U) < V(UR)". E.g. if we want to have
V(UR) == 511 and this frame is dropped, we would ignore N(U)'s
0 to 510. Calculate the delta.
The code is based on Jonathan Santos's "LLC UI window" fix but the
issue was discovered independly.
Using LLGMM-RESET.req, the GMM can request the LLC of the MS to reset
all its parameters, particularly the sequence numbers. We don't yet do
XID RESET retransmissions, and we don't yet generate a LLGMM-RESET.conf
primitive back to GMM.
libosmogsm is a new library that is distributed in the libosmocore.
Now, openbsc depends on it. This patch gets openbsc with this
change.
This patch also rewrites all include path to the new
osmocom/[gsm|core]
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
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.
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 FCS isn't computed yet (because of ciphering).
It _will_ be tested and reported as wrong later in the code
so we can just display it here and let the latter code report the
error if any.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Once The TLLI (or P-TMSI of which it is derived) change has been
confirmed by the MS, we need to unassign the old TLLI but keep
the new TLLI _without_ re-setting the LLC entity structure such
as VUsend /VUrecv counters.
* separate the LLME and LLE state in the LLC layer
* introduce gprs_llgmm_assign() function for LLGMM-ASSIGN.req primitive
* change QoS profile to match 'real' SGSN
* Update the new TLLI when assigning a P-TMSI
The result now is that the LLC layer is notified of TLLI changes, which in turn
means it doesn't allocate a new LLE structure every TLLI change, which again
in turn means that the UI frame sequence number does not reset to zero.
As a result, MS should no longer ignore frames based on wrong UI sequence number.
When we send a downlink unit-data request via BSSGP, there is a lot
of information that needs to be copied from the mm context, such as
the IMSI, DRX parametes, MS radio access parameters, ...
This is a quite strange layering violation, since we now need to pass
a pointer to the MM ctx from GMM through LLC into BSSGP :(
Don't allocate a LLC Entity just because BSSGP passes any random
SAPI/TLLI up to us. We can only do this for XID and UI frames
of the GMM SAPI.
Furthermore, add more comments and debug messages.
Daniel Willmann
Harald Welte
Dieter Spaar
Sylvain Munaut