Hi Fred, >>> The collision can only occur if the +CGDCONT (or +CGDSCONT) command from >>> Ofono is sent at the same time as PDP >>context activation URC from the >>> modem, and both use the same CID. >>> >>> But in that case, the modem should not reply "OK" to the PDP context >>> configuration command, but "ERROR". >>> And Ofono should not consider that the PDP configuration command as >>> successful. >>> Moreover, the "OK" for the context configuration and the context activation >>> URC are sent of the same control >>> channel so they cannot be sent in parallel but only in sequence. >>> >>> Sjur, is that a correct assumption? >> >> Yes, this sounds about right. >> But I think Denis' proposal for using ofono_gprs_set_cid_range(gprs, >> <min>, <max>) pretty much solves this issue, >> We can use this to reserve the CID used for Initial PDN, and void this >> race condition. > I have to admit that I'm not yet fully comfortable with the solution proposed > by Denis. > At least as long as we want to keep a on 1:1 mapping between the Ofono CID > and the AT CID. > If I have understood correctly, the Ofono Core is "chosing" a CID > and the modem plugin is trying to use the same CID on the AT interface. > The way to resolve the race condition as proposed by Denis is to "reserve" a > range of CIDs > for the modem and another range for ofono. > > My concern is that I don't know if this will work for all the modem > implementations. > My understanding is that an AT+CGDCONT=? should return you the list of > supported CID > and not the list of CID that the user/Ofono can use.
It is up to the driver to set the ranges appropriately based upon its much more intimate knowledge of the modem firmware. The drivers that do not support LTE / network activated contexts can ignore this magic. > > Considering that from a modem standpoint the CID race condition can be > resolved, > some modem implementation may not have reserved a range of CID for their own > purpose, > or may not provide a mechanism to reserve a range of CID. > If the CGDCONT race is guaranteed to be solved by the modem manufacturers, great. Unfortunately that is not the only race present. Hint: The gatchat implementation uses non-blocking IO, select and a command queue. So it is fully possible for oFono to reserve a CID, send out a driver activation request, but receive a network initiated context activation / default bearer activation before the CGDCONT was even sent. Having cid ranges that do not overlap seems the safest approach to me right now. Unless someone has a better idea... Regards, -Denis _______________________________________________ ofono mailing list [email protected] http://lists.ofono.org/listinfo/ofono
