gprs_llc_process_xid_ind() does not echo L3_PAR, breaks PDP activation for Motorola KRZR
(at the time of writing) http://cgit.osmocom.org/osmo-sgsn/tree/src/gprs/gprs_llc.c#n227
We check if (xid_field->type != GPRS_LLC_XID_T_L3_PAR)
before echoing the XID to the MS
The Motorola KRZR responds by sending the XID list again and repeats 4 times before giving up and sending PDP deactivate context, with a cause 25 "LLC or SNDCP Failure"
Removing the check for xid_field->type != GPRS_LLC_XID_T_L3_PAR and echoing the L3 parameter back results in PDP activation success and GPRS session works.
Why this check? Why do we not echo all the xid fields back? Did it break with some other phone?
#3 Updated by keith about 1 month ago
TS 04.06 [EDIT correction TS 04.64 22.214.171.124 ] is kind of confusing here.
On the one had it says:
As an optimisation, parameters confirming the requested values may be omitted from the XID response.
The responding side may respond with parameters that were not included in the XID command. A parameter that was
not included in the XID command shall in this case be treated as if the current value of the parameter was included in
the XID command. The responding side shall include such a parameter in every XID response until the parameter has
been explicitly negotiated, either by responding to an XID command that included the parameter, or by explicitly
including the parameter the next time an XID command is transmitted.
Negotiated XID parameters shall apply to the LLE identified by the DLCI of the XID frames used, except Version,
Reset, and IOV-UI that applies to an LLME (i.e., a TLLI), and except Layer-3 Parameters that apply to the layer 3
above the LLE.
So from that I understand that while we may not actually be applying this L3 param to the LLE identified by the DLCI (to be honest, I haven't even looked up what the dlci is), we still MUST include it in the response.
Maybe this is a mis understanding that is the origin of this
if (xid_field->type != GPRS_LLC_XID_T_L3_PAR)
in the code?