After opening a logical channel to applet on SIM card it's not possible to retrieve the OPEN RESPONSE data. REQUEST_SIM_OPEN_CHANNEL parcel has actually 4 bytes left over each time the channel is opened, but this is to small for OPEN RESPONSE data. On Flame 2.1 with QCRIL OPEN RESPONSE was retrieved by sending GET RESPONSE command immediately after the channel was opened. This is done be SE API implementation. On Nexus 5L after sending GET RESPONSE we get status word 6F00 which according to [0] means "Command aborted - more exact diagnosis not possible (e.g., operating system error)." [0] - https://www.eftlab.com.au/index.php/site-map/knowledge-base/118-apdu-response-list

Hello RIL team, Is this issues because MozRIL currently doesn't have the un-marshaling code for retrieving 'open-response' in ril_worker.js and RadioInterfaceLayer.js. Since for SE REL on 2.1 code base with Q image, we only modified RILContentHelper.js to retrieve 'channel number' & 'open Response'. Thx, Sid

(In reply to psiddh from comment #2) > Hello RIL team, > > Is this issues because MozRIL currently doesn't have the un-marshaling code > for retrieving 'open-response' in ril_worker.js and RadioInterfaceLayer.js. > Since for SE REL on 2.1 code base with Q image, we only modified > RILContentHelper.js to retrieve 'channel number' & 'open Response'. > > Thx, Sid Well I just checked our patches :). We did not modify RILContentHelper.js for retrieving 'open response'. This was done in SecureElement.js itself. However that said, do you think MozRIL should have unmarshaling logic for 'select response' along with 'channel ID / sessionId' based on recent ril update from Lollipop for 'RIL_REQUEST_SIM_OPEN_CHANNEL'.

(In reply to psiddh from comment #3) > Well I just checked our patches :). We did not modify RILContentHelper.js > for retrieving 'open response'. This was done in SecureElement.js itself. > However that said, do you think MozRIL should have unmarshaling > logic for 'select response' along with 'channel ID / sessionId' based on > recent ril update from Lollipop for 'RIL_REQUEST_SIM_OPEN_CHANNEL'. Totally agree with you, MozRIL should handle the `select response` carried in the response of RIL_REQUEST_SIM_OPEN_CHANNEL [1]. And the nsIIccChannelCallback.notifyOpenChannelSuccess() [2] will also needs a revise, too. [1] https://github.com/android/platform_hardware_ril/blob/lollipop-release/include/telephony/ril.h#L3833-L3834 [2] https://dxr.mozilla.org/mozilla-central/source/dom/icc/interfaces/nsIIccProvider.idl?from=nsIIccProvider.idl&case=true#23-29

Just a note, UiccConnector will also need to be modified to not issues `GET RESPONSE` command if the `select response` will be not null.

Same as in case of Bug 1139835 comment 7, we have a problem with Parcel format here.

(In reply to Krzysztof Mioduszewski[:tauzen] from comment #6) > Same as in case of Bug 1139835 comment 7, we have a problem with Parcel > format here. According to the log attached in bug 1139835 (attachment #8575989 [details]), > I/Gecko ( 189): RIL Worker: Parcel (size 20): 0,0,0,0,62,0,0,0,0,0,0,0,1,0,0,0,2,0,0,0 0,0,0,0 => response type 62,0,0,0 => token 0,0,0,0 => error code (0 means success) 1,0,0,0 => length of response data 2,0,0,0 => first response data, channel id The response parcel of OPEN_CHANNEL doesn't contain "select response" actually, though the documentation says it may contains "select response" in second field [1]. [1] https://github.com/android/platform_hardware_ril/blob/lollipop-release/include/telephony/ril.h#L3833-L3834

Needinfo to OEM partner. Maybe Mr. Chae can shed some light here.

Firefox OS is not being worked on