Hi all, 2011/1/7 Denis Kenzior <[email protected]>: >> 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...
The 27.007 for release 9 (from version 9.3.0 onwards) says: NOTE 1: The <cid>s for network-initiated PDP contexts will have values outside the ranges indicated for the <cid> in the test form of the commands +CGDCONT and +CGDSCONT. The change was proposed by STE last February. This has some ramifications on how we use the CIDs within driver/core. -- Pekka.Pessi mail at nokia.com _______________________________________________ ofono mailing list [email protected] http://lists.ofono.org/listinfo/ofono
