The byte ordering is a bit odd: The least significant byte is ahead of
the most significant byte, different from everything else in GSM that
seems to be big-endian.
Thanks to Seungju Kim <admin@manateeshome.com> for repoerting the bug.
If, for some reason, the mobile did not receive an ATTACH ACCEPT
it resends an ATTACH REQUEST. The SGSN then would send a new
ATTACH ACCEPT. However, after sending the new ATTACH REQUEST, it
was unable to find the GMM context if the mobile uses the old
foreign tlli (as it is allowed to do). This fixes that.
During the GPRS Attach procedure, the SGSN was changing the TLLI
to the new TLLI when sending the second Identity Request. This
was caused by the sgsn_mm_ctx_by_tlli() function changing the TLLI.
It is usually bad form to have a lookup function change values.
This works around a problem that occurs if a mobile loses packet
data connectivity, e.g. moves out of coverage or switches over
to a circuit-switched call, while a data transfer is occurring.
The mobile would reset its LLC state, causing it to be
unsynchronized with the SGSN. Therefore the SGSN would drop
incoming frames until the sequence numbers matched. This
workaround resets the LLC state in the SGSN if T3350 expires,
indicating that Routing Area Updating Request, Attach Request,
or P-TMSI Realloc Command has failed.
According to TS 44.064 section 8.4.2, the LLC layer should only
drop UI frames if V(UR)-32 <= N(U) < V(UR). The code was dropping
frames whenever N(U) < V(UR). Consequently, large amounts of
packets could be dropped if, e.g., V(UR)==511 and the frame with
N(U)==511 was lost. All frames would be dropped until the next
time a frame with N(U)==511 is received.
TS 24.008 version 9.5.0 Release 9 sec 4.7.5:
In A/Gb mode, user data transmission in the MS shall be
suspended during the routing area updating procedure, except
if the routing area updating procedure is triggered by a PS
handover procedure as described in 3GPP TS 43.129 [113];
user data reception shall be possible. User data transmission
in the network may be suspended during the routing area
updating procedure.
TS 24.008 version 9.5.0 Release 9 sec 4.7.3.1.6:
If an ATTACH REQUEST message is received in state GMM-REGISTERED
the network may initiate the GMM common procedures; if it turned
out that the ATTACH REQUEST message was send by an MS that has
already been attached, the GMM context, PDP contexts and MBMS
contexts, if any, are deleted and the new ATTACH REQUEST is
progressed.
The SGSN was allowing MS Network Capability of up to 8 octets, but only allocating
storage for 4 octets.
TS 23.060 version 9.7.0 Release 9 section 6.14.2 states:
To allow for the addition of future features, the SGSN shall
store the UE Network Capability and the MS Network Capability
even if either or both is larger than specified in TS 24.008
[13]/TS 24.301 [102], up to a maximum size of 32 octets for
each IE.
Newer phones are using a MS Radio Access Capability larger than the
14 octets specified in 04.08 Release 1998 (up to 50 octets in Rel 9).
This caused the SGSN to crash since it only allocated storage for
14 octets but tried to store up to 51 octets.
TS 23.060 version 9.7.0 Release 9 section 6.14.1.1 states:
To allow for the addition of future radio technologies, frequency
bands, and other enhancements, the SGSN shall store the MS radio
access capability even if it is larger than specified in TS 24.008
[13], up to a maximum size of 255 octets.
A bug in debian/control caused "debian/rules binary" to fail with:
dpkg-gencontrol: error: source package has two conflicting values - openbsc and opensgsn
Jonathan Santos
Harald Welte
Dieter Spaar