Closed
Bug 1125720
Opened 9 years ago
Closed 9 years ago
[FFOS2.0][Woodduck][CB]MS can receive 1/2/3 when plmn and SIM card file not include these cb channels.
Categories
(Firefox OS Graveyard :: Vendcom, defect, P2)
Firefox OS Graveyard
Vendcom
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: sync-1, Unassigned)
References
Details
(Whiteboard: [POVB])
Attachments
(5 files)
Created an attachment (id=1129935) CB频道读取多余频道问题的adb logcat.rar DEFECT DESCRIPTION: 频道1/2/3能收到CB消息. REPRODUCING PROCEDURES: 1.插入SIM的PLMN=00101（定义频道0，1,2,3能接收） CBMIR=0004-0005的3G白卡，手机可以正常收到0-5的CB，并且关机后，读SIM卡文件，CBMIR未改变. 2.更改SIM的PLMN=26002（定义频道0，9，19，28，112），卡文件（CBMI&CBMIR）为空的3G白卡，手机能正常收到0，9，19，28，112，并且也能收到1/2/3（此3个频道不包涵在此PLMN所包涵的CB列表）的消息。关机读SIM卡，SIM卡中的卡文件没有被改变.--KO. EXPECTED BEHAVIOUR: 手机更新CB频道应该只读取来自PLMN以及CBMI&CBMIR. >备注：附件是两次插卡开机过程的log.
|
||
Comment 1•9 years ago
|
||
Hi, The support of CBS settings in DSDS is not complete yet in v2.0. Related bugs are bug 921326, bug 1068978 and bug 1015054 which were landed in v2.1 instead.
(In reply to comment #3) > Comment from Mozilla:CB is gaia::System matter. Thanks!
|
Reporter | |
Comment 10•9 years ago
|
||
Created an attachment (id=1134244) mtklog CB.part01.rar
|
|
Reporter | |
Comment 11•9 years ago
|
||
Created an attachment (id=1134245) mtklog CB.part02.rar
|
|
Reporter | |
Comment 12•9 years ago
|
||
Created an attachment (id=1134245) mtklog CB.part02.rar
|
|
Reporter | |
Comment 13•9 years ago
|
||
Created an attachment (id=1134245) mtklog CB.part02.rar
|
|
Reporter | |
Comment 14•9 years ago
|
||
Dear Mozilla,
按MTK的要求重新抓了份log，对应MTK eService ID:ALPS01926924
针对于PLMN Range问题，之前Mozilla在bug 1113017上做了修复，但从log中看，貌似还存在问题，烦请Mozilla再看看.
I/Gecko ( 165): -*- RadioInterface[0]: 'ril.cellbroadcast.searchlist' is now "0,1,2,3"
I/Gecko ( 165): RIL Worker: [0] Received chrome message {"searchList":"0,1,2,3","rilMessageClientId":0,"rilMessageToken":14,"rilMessageType":"setCellBroadcastSearchList"}
I/Gecko ( 165): RIL Worker: [0] Cell Broadcast search lists: {"MMI":[0,1,1,2,2,3,3,4],"CBMI":[100,101],"CBMID":[],"CBMIR":[4,6]}
I/Gecko ( 165): RIL Worker: [0] Cell Broadcast search lists(merged): [0,6,100,101]
I/Gecko ( 168): -*- RadioInterface[0]: 'ril.cellbroadcast.searchlist' is now "0,9,19,28,112"
I/Gecko ( 168): RIL Worker: [0] Received chrome message {"searchList":"0,9,19,28,112","rilMessageClientId":0,"rilMessageToken":14,"rilMessageType":"setCellBroadcastSearchList"}
I/Gecko ( 168): RIL Worker: [0] Cell Broadcast search lists: {"MMI":[0,1,9,10,19,20,28,29,112,113],"CBMI":[],"CBMID":[],"CBMIR":[]}
I/Gecko ( 168): RIL Worker: [0] Cell Broadcast search lists(merged): [0,1,9,10,19,20,28,29,112,113]|
|
||
Comment 15•9 years ago
|
||
Hi, It seems not related to what I mentioned in comment 1 for the support of CBS settings in DSDS device but is more related to bug 1113017. From the new logs in comment 10 and comment 12, the problem mentioned in comment 0 was fixed. In addition, for the logs mentioned in comment 14, it is normal that in ril_worker, an array of half-closed ranges: [[from, to), [from, to), ...] is used to collect all the message ids from CBMI/CBMIR/CBMID/MMI and each element will be changed to [from, to-1] at [1] when sending the RIL request to RILD. Hence, problems in comment 0 and comment 14 are no-issue to me for now. Would you please help to double confirm this? [1] https://hg.mozilla.org/releases/mozilla-b2g32_v2_0m/file/6d7fae9f7821/dom/system/gonk/ril_worker.js#l2242
Flags: needinfo?(sync-1)
|
|
||
Comment 16•9 years ago
|
||
(In reply to Bevis Tseng[:bevistseng][:btseng] from comment #15) > element will be changed to [from, to-1] at [1] when sending the RIL request Sorry for typo, it will be changed from [from, to) to [from, to] instead.
|
|
Reporter | |
Comment 17•9 years ago
|
||
(In reply to Bevis Tseng[:bevistseng][:btseng] from comment #15) > From the new logs in comment 10 and comment 12, the problem mentioned in > comment 0 was fixed. The problem mentioned in comment 0 is that the step 2 also could receive the CB message from channel 1,2,3. That not right. > In addition, for the logs mentioned in comment 14, it is normal that in > ril_worker, an array of half-closed ranges: [[from, to), [from, to), ...] is > used to collect all the message ids from CBMI/CBMIR/CBMID/MMI and each > element will be changed to [from, to-1] at [1] when sending the RIL request > to RILD. >Sorry for typo, it will be changed from [from, to) to [from, to] instead. You means that the "Cell Broadcast search lists(merged): [0,1,9,10,19,20,28,29,112,113]" is more like:[0,1),[9,10),[19,20),[28,29),[112,113), and will changed to [0,0],[9,9],[19,19],[28,28],[112,112]?
|
|
||
Comment 18•9 years ago
|
||
(In reply to sync-1 from comment #17) > (In reply to Bevis Tseng[:bevistseng][:btseng] from comment #15) > > From the new logs in comment 10 and comment 12, the problem mentioned in > > comment 0 was fixed. > > The problem mentioned in comment 0 is that the step 2 also could receive > the CB message from channel 1,2,3. That not right. > > > In addition, for the logs mentioned in comment 14, it is normal that in > > ril_worker, an array of half-closed ranges: [[from, to), [from, to), ...] > is > > used to collect all the message ids from CBMI/CBMIR/CBMID/MMI and each > > element will be changed to [from, to-1] at [1] when sending the RIL > request > > to RILD. > > >Sorry for typo, it will be changed from [from, to) to [from, to] instead. > > You means that the "Cell Broadcast search lists(merged): > [0,1,9,10,19,20,28,29,112,113]" is more > like:[0,1),[9,10),[19,20),[28,29),[112,113), and will changed to > [0,0],[9,9],[19,19],[28,28],[112,112]? Exactly. BTW, I found something suspicious in modem side. It seems that the modem try to get CBS search list set previously (0-3) and merge it with the list newly requested. This seems to be the root cause of what we have seen in comment 0. Please have chip vendor's help to check this instead. Thanks! -- 01-21 04:01:16.836 647 660 I use-Rlog/RLOG-RILC: RIL(1) SOCKET REQUEST:90, GSM_SET_BROADCAST_SMS_CONFIG, token:72, length:112 01-21 04:01:16.836 647 660 I use-Rlog/RLOG-RILC: 5A 00 00 00 48 00 00 00 05 00 00 00 00 00 00 00 01-21 04:01:16.836 647 660 I use-Rlog/RLOG-RILC: 00 00 00 00 00 00 00 00 FF 00 00 00 01 00 00 00 01-21 04:01:16.836 647 660 I use-Rlog/RLOG-RILC: 09 00 00 00 09 00 00 00 00 00 00 00 FF 00 00 00 01-21 04:01:16.836 647 660 I use-Rlog/RLOG-RILC: 01 00 00 00 13 00 00 00 13 00 00 00 00 00 00 00 01-21 04:01:16.836 647 660 I use-Rlog/RLOG-RILC: FF 00 00 00 01 00 00 00 1C 00 00 00 1C 00 00 00 01-21 04:01:16.836 647 660 I use-Rlog/RLOG-RILC: 00 00 00 00 FF 00 00 00 01 00 00 00 70 00 00 00 01-21 04:01:16.836 647 660 I use-Rlog/RLOG-RILC: 70 00 00 00 00 00 00 00 FF 00 00 00 01 00 00 00 01-21 04:01:16.836 647 651 D use-Rlog/RLOG-RIL: onRequest: 90, GSM_SET_BROADCAST_SMS_CONFIG, datalen = 20 01-21 04:01:16.836 647 651 D use-Rlog/RLOG-AT: AT> AT+CSCB? 01-21 04:01:16.838 647 665 D use-Rlog/RLOG-AT: AT< +CSCB: 0,"0-3","0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,32,33,34,35,36,15",1 01-21 04:01:16.839 647 651 D use-Rlog/RLOG-AT: AT> AT+CSCB=1, "0-3", "0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,32,33,34,35,36,15" 01-21 04:01:16.839 647 651 D use-Rlog/RLOG-AT: AT+CSCB=1, "0-3", "0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,32,33,34,35,36,15" 01-21 04:01:16.843 647 651 D use-Rlog/RLOG-RIL: New dcs Setting: 0-255 21 01-21 04:01:16.843 647 651 D use-Rlog/RLOG-RIL: New ch Setting: 0-3,9,19,28,112 01-21 04:01:16.843 647 651 D use-Rlog/RLOG-AT: AT> AT+CSCB=0, "0-3,9,19,28,112"
Component: Gaia::System → Vendcom
|
|
Reporter | |
Comment 19•9 years ago
|
||
(In reply to Bevis Tseng[:bevistseng][:btseng] from comment #18) Thanks! The comment #16 comfuse me after I review it. Could you explain it again. Thanks! P.S. All I get about the CB range at comment #17 is base on comment #15.
|
|
||
Comment 20•9 years ago
|
||
(In reply to sync-1 from comment #19) > The comment #16 comfuse me after I review it. Could you explain it again. > Thanks! > > P.S. All I get about the CB range at comment #17 is base on comment #15. Sure, what I'd like to explain is the same as what you understood in comment 17. The ril.cellbroadcast.searchlist' of "0,9,19,28,112" will be merged with CBMI/CBMIR/CBMID by ril_worker.js as [0,1,9,10,19,20,28,29,112,113] and will be set to RILD as [0,0],[9,9],[19,19],[28,28],[112,112] according to the structure of RIL_GSM_BroadcastSmsConfigInfo in ril.h in AOSP. Then, if you decode the raw parcel of GSM_SET_BROADCAST_SMS_CONFIG in comment 18, you will realize that the search list set from gecko is as expected: 5A 00 00 00 RIL_RQUEST_TYPE: 90 - RIL_REQUEST_GSM_SET_BROADCAST_SMS_CONFIG 48 00 00 00 TOKEN: 72 05 00 00 00 sizeof(RIL_GSM_BroadcastSmsConfigInfo *): 5 00 00 00 00 From: 0 00 00 00 00 To: 0 00 00 00 00 FromDCS: 0 FF 00 00 00 ToDCS: 255 01 00 00 00 Selected: Yes 09 00 00 00 From: 9 09 00 00 00 To: 9 00 00 00 00 FromDCS: 0 FF 00 00 00 ToDCS: 255 01 00 00 00 Selected: Yes 13 00 00 00 From: 19 13 00 00 00 To: 19 00 00 00 00 FromDCS: 0 FF 00 00 00 ToDCS: 255 01 00 00 00 Selected: Yes 1C 00 00 00 From: 28 1C 00 00 00 To: 28 00 00 00 00 FromDCS: 0 FF 00 00 00 ToDCS: 255 01 00 00 00 Selected: Yes 70 00 00 00 From: 112 70 00 00 00 To: 112 00 00 00 00 FromDCS: 0 FF 00 00 00 ToDCS: 255 01 00 00 00 Selected: Yes
|
|
Reporter | |
Comment 21•9 years ago
|
||
(In reply to Bevis Tseng[:bevistseng][:btseng] from comment #20) Thans you very mush!
|
||
Comment 22•9 years ago
|
||
Hi Jason, Can you help to check this issue per comment 18? Thanks!
Flags: needinfo?(chien-hao.li)
|
||
Comment 23•9 years ago
|
||
Hi Lexel, Please check Comment 18. Thanks.
Flags: needinfo?(chien-hao.li) → needinfo?(lexel.yu)
|
|
Reporter | |
Comment 24•9 years ago
|
||
Dear Mozilla, What log will recorded in the file main_log.boot"? I search the "ril.cellbroadcast.searchlist" from mtklog: mtklog CB\mobilelog\APLog_2015_0121_040106\main_log RadioInterface[0]: 'ril.cellbroadcast.searchlist' is now "0,1,2,3" mtklog CB\mobilelog\APLog_2015_0121_040106\main_log.boot RadioInterface[0]: 'ril.cellbroadcast.searchlist' is now "" mtklog CB\mobilelog\APLog_2015_0121_040107\main_log RadioInterface[0]: 'ril.cellbroadcast.searchlist' is now "0,9,19,28,112" mtklog CB\mobilelog\APLog_2015_0121_040107\main_log.boot RadioInterface[0]: 'ril.cellbroadcast.searchlist' is now "0,1,2,3" The log in "APLog_2015_0121_040107" is created at step 2. And the value of 'ril.cellbroadcast.searchlist' in "main_log.boot" is "0,1,2,3". Where is this value come from?
|
|
||
Comment 25•9 years ago
|
||
(In reply to sync-1 from comment #24) > Dear Mozilla, > > What log will recorded in the file main_log.boot"? > Hi, I think this has to be answer by the logging tools owner instead of Mozilla. > > I search the "ril.cellbroadcast.searchlist" from mtklog: > > > mtklog CB\mobilelog\APLog_2015_0121_040106\main_log > RadioInterface[0]: 'ril.cellbroadcast.searchlist' is now "0,1,2,3" > > mtklog CB\mobilelog\APLog_2015_0121_040106\main_log.boot > RadioInterface[0]: 'ril.cellbroadcast.searchlist' is now "" > > > > mtklog CB\mobilelog\APLog_2015_0121_040107\main_log > RadioInterface[0]: 'ril.cellbroadcast.searchlist' is now "0,9,19,28,112" > > mtklog CB\mobilelog\APLog_2015_0121_040107\main_log.boot > RadioInterface[0]: 'ril.cellbroadcast.searchlist' is now "0,1,2,3" > > > > The log in "APLog_2015_0121_040107" is created at step 2. And the value of > 'ril.cellbroadcast.searchlist' in "main_log.boot" is "0,1,2,3". Where is > this value come from? Hi, "0,1,2,3" is the preference that was stored during step 1. In current design, When device boot up, we will get the search list from settings first. However, this value will be changed after app detected that the SIM card is changed to apply a new search list according to the inserted SIM. We expect GSM_SET_BROADCAST_SMS_CONFIG to override with the latest search list we provided instead of merging them with the previous one. If this is not the case, then we have to know what's the correct flow for the configuration of CBS Search List.
|
|
Reporter | |
Comment 26•9 years ago
|
||
Dear Mozilla, Comment From MTK: Dear Customer， 您好！请看这份Log（\mtklogCB\mtklog CB\mdlog\MDLog_2015_0121_040117）。 里面有： Local Time: 00:00:30:751 2010/01/01 Message: [AT_I p46, s10]AT+CSCB? Local Time: 00:00:30:751 2010/01/01 Message: [AT_R p46, s10]+CSCB: 0,"0,4-5","0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,32,33,34,35,36,15",1 Local Time: 00:00:30:751 2010/01/01 Message: [AT_R p46, s10]OK Local Time: 00:00:30:755 2010/01/01 Message: [AT_I p46, s10]AT+CSCB=1, "0,4-5", "0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,32,33,34,35,36,15" Local Time: 00:00:30:755 2010/01/01 Message: [AT_R p46, s10]OK Local Time: 00:00:30:765 2010/01/01 Message: [AT_I p46, s10]AT+CSCB=0, "0-5" Local Time: 00:00:30:792 2010/01/01 Message: [AT_R p46, s10]OK 为何AP会下 AT+CSCB=0, "0-5" ? MTK Support
|
|
Reporter | |
Comment 27•9 years ago
|
||
Dear Mozilla, Ignore last comment, MTK need to double check it.
|
|
Reporter | |
Comment 28•9 years ago
|
||
Dear Mozilla,
Comment From MTK:
Dear Customer，
您好！请提供一下 APP Framework中的，小区广播数据库文件。
我们确认一下，数据库中是否保存下来了。
MTK Support
Is there hava a CB database?|
|
||
Comment 29•9 years ago
|
||
(In reply to sync-1 from comment #28) > Dear Mozilla, > > > Comment From MTK: > > Dear Customer， > 您好！请提供一下 APP Framework中的，小区广播数据库文件。 > 我们确认一下，数据库中是否保存下来了。 > MTK Support > > > Is there hava a CB database? No, as mentioned in comment 25, there is no database for searchlist but a simple setting to store the search list in settings. [1] [1] https://hg.mozilla.org/releases/mozilla-b2g32_v2_0m/file/8bdac875f08a/dom/system/gonk/RadioInterfaceLayer.js#l3429
|
|
Reporter | |
Comment 30•9 years ago
|
||
Created an attachment (id=1147408) Comment From MTK and the last mtklog
|
|
Reporter | |
Comment 31•9 years ago
|
||
Created an attachment (id=1147408) Comment From MTK and the last mtklog
|
|
Reporter | |
Comment 32•9 years ago
|
||
Created an attachment (id=1147408) Comment From MTK and the last mtklog
|
|
Reporter | |
Comment 33•9 years ago
|
||
(In reply to sync-1 from comment #32) > Created attachment 8558269 [details] > Comment From MTK and the last mtklog Dear Mozilla, MTK said that the channel "0-3" is come from AP at step two. Channel "0-3" is setted by PLMN at first step and it will saved in an simple setting. When device boot up, it will get the search list from settings first at step two. Will AP send the channel "0-3" to modem at this time?
|
|
||
Comment 34•9 years ago
|
||
(In reply to sync-1 from comment #33) > (In reply to sync-1 from comment #32) > > Created attachment 8558269 [details] > > Comment From MTK and the last mtklog > > > Dear Mozilla, > > MTK said that the channel "0-3" is come from AP at step two. > > Channel "0-3" is setted by PLMN at first step and it will saved in an > simple setting. When device boot up, it will get the search list from > settings first at step two. Will AP send the channel "0-3" to modem at this > time? Yes, as I said in comment 25, the search list will be stored in the persistent storage in step 1. Hence, at the beginning of step 2, we apply with the old settings firstly will override after we got new SIM detected and the corresponding search list "0,9,19,28,112" to be set. Currently, we don't have a complicated design in gecko to comply AT+CSCB to enable/disable msg_ids by caching what has been set after device boot up. We simply expect GSM_SET_BROADCAST_SMS_CONFIG to override with the latest search list we provided instead of merging them with the previous one. However, from the radio log in comment 18, we saw that MTK's rild will query what have been set "0-3" after device bootup at step 2 and merge the new request "0,9,19,28,112" after new SIM detected with corresponding search list "0,9,19,28,112". Is possible for MTK's RILD to just apply the last search list without merging the previous one?
|
|
Reporter | |
Comment 35•9 years ago
|
||
> Is possible for MTK's RILD to just apply the last search list without
> merging the previous one?
Dear Mozilla,
MTK didn't answer it directly.
They want to know how you send the channel to modem. Such as what interface and so on. It seems that they want to confirm something.
Thanks!|
|
||
Comment 36•9 years ago
|
||
(In reply to sync-1 from comment #35) > > Is possible for MTK's RILD to just apply the last search list without > > merging the previous one? > > Dear Mozilla, > > MTK didn't answer it directly. > > They want to know how you send the channel to modem. Such as what > interface and so on. It seems that they want to confirm something. > > Thanks! The RIL command GSM_SET_BROADCAST_SMS_CONFIG is the only thing we can use to set the search list to the modem.
|
|
Reporter | |
Comment 37•9 years ago
|
||
Dear Mozilla, The last comment from MTK: Dear Customer， 您好！请让Mozilla修改实现方式，调用两次REQUEST_GSM_SET_BROADCAST_SMS_CONFIG() ，并不是覆盖。而是会把两次的合并一起。请Mozilla修改实现方式，对于old list，不要调用REQUEST_GSM_SET_BROADCAST_SMS_CONFIG()。 MTK Support --------------------------------------------- Is that possible?
|
|
||
Comment 38•9 years ago
|
||
(In reply to sync-1 from comment #37) > Dear Mozilla, > > > The last comment from MTK: > > Dear Customer， > 您好！请让Mozilla修改实现方式，调用两次REQUEST_GSM_SET_BROADCAST_SMS_CONFIG() > ，并不是覆盖。而是会把两次的合并一起。请Mozilla修改实现方式，对于old > list，不要调用REQUEST_GSM_SET_BROADCAST_SMS_CONFIG()。 > > MTK Support > --------------------------------------------- > > Is that possible? Sorry, it is not possible for now in a short time and is risky which requires a complicated design change to cache all the history of the search list we have set and identify what channel has to be disabled/enabled according the last search list to be set. [1] [1] http://androidxref.com/5.0.0_r2/xref/frameworks/opt/telephony/src/java/com/android/internal/telephony/IntRangeManager.java [2] http://androidxref.com/5.0.0_r2/xref/frameworks/opt/telephony/src/java/com/android/internal/telephony/IccSmsInterfaceManager.java#714
|
|
||
Comment 39•9 years ago
|
||
BTW, will this be a blocker? Actually, the symptom will be recovered once device reboot with the same SIM card.
|
|
Reporter | |
Comment 40•9 years ago
|
||
(In reply to comment #27) > Comment from Mozilla:BTW, will this be a blocker? > Actually, the symptom will be recovered once device reboot with the same SIM > card. Not a blocker. 因短时间内让Mozilla或MTK中的一方修改现有实现都存在风险，鉴于此PR紧急程度较低，且不影响用户使用。我已向VPM建议暂不修改，先关闭此PR。等有回复后再向您反馈。非常感谢您的支持！
|
|
Reporter | |
Comment 41•9 years ago
|
||
MTK p8 will fix this issue. Thanks!
|
|
Reporter | |
Comment 42•9 years ago
|
||
Dear Dengwei, 合入MTK V1.3 P8后，在v7G1M-5上验证通过，请关闭此PR。谢谢！
|
|
||
Comment 43•9 years ago
|
||
Per comment 42 Close this issue as POVB.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Whiteboard: [POVB]
|
|
||
Updated•9 years ago
|
Flags: needinfo?(sync-1)
You need to log in
before you can comment on or make changes to this bug.
Description
•