Closed Bug 1276871 Opened 8 years ago Closed 8 years ago

[Remote Control] There has higher chance unable to invoke pin code page in first pairing

Categories

(Firefox OS Graveyard :: Gaia::TV, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.6?)

RESOLVED WORKSFORME
blocking-b2g 2.6?

People

(Reporter: mlien, Assigned: chunmin)

References

Details

(Whiteboard: [ft:conndevices])

[Testing Steps]
0. Fennec and TV are not paired before
1. TV and Fennec link to the same network domain
2. Invoke Remote Control TV from Fennec

[Expected result]
Invoke pin code page succesfully

[Actual result]
There has higher chance unable to invoke pin code page in first pairing and only show blank page

Error log:
I/Gecko   (  171): RemoteControlService: onInputStreamReady(aInput=[xpconnect wrapped (nsISupports, nsIInputStream, nsIAsyncInputStream, nsISeekableStream, nsISearchableInputStream, nsICloneableInputStream)]) on thread [xpconnect wrapped >(nsISupports, nsIThread, nsIThreadInternal, nsIEventTarget, nsISupportsPriority)] (main is [xpconnect wrapped (nsISupports, nsIThread, nsIThreadInternal, nsIEventTarget, nsISupportsPriority)])
I/Gecko   (  171): RemoteControlService: onInputStreamReady called on a closed input, destroying connection, error: [Exception... "Component returned failure code: 0x805a2fa3 [nsIInputStream.available]"  nsresult: "0x805a2fa3 (<unknown>)"  location: "JS frame :: resource://gre/modules/RemoteControlService.jsm :: Connection.prototype.onInputStreamReady :: line 500"  data: no]

[Build Info]
Environment: 2.6 Nexus Player
gaia:
https://github.com/mozilla-b2g/gaia/commit/53f70ab0313250225210e966c7407ec828265895
gecko:
https://github.com/mozilla-b2g/gecko-b2g/commit/1f9da1c47090cd29110df577ea1708cf6531c299
Component: GonkIntegration → Gaia::TV
Hi Eric,
Can you help to check this? 
Thanks.
Flags: needinfo?(etsai)
Assignee: nobody → etsai
Status: NEW → ASSIGNED
Flags: needinfo?(etsai)
Some notes of tracking this issue:
1. Remove then create a new cert -> doesn't work
2. Only happen after new gecko first reboot (no matter it's adb reboot, reboot from UI or just unplug)
3. On this status, use openssl on ubuntu connects to nexus player -> works.
4. This happen when fennec addon sends first event, that means it can pass onSocketAccepted.

From 3 and error code, not sure if it's caused by fennec addon?
SSL_ERROR_UNKNOWN_CA_ALERT=Peer does not recognize and trust the CA that issued your certificate.
This error can be reproduced after rebooting the TV. After rebooting TV, the TV side will suffer the UNKONW ERROR "0x805a2fa3 (<unknown>)".

From testing with OpenSSL, the Fennec add-on also can connect and send message to OpenSSL server successfully, so I think finding the root cause of the UNKONW ERROR "0x805a2fa3 (<unknown>)" is a better way to solve this issue. The add-on side will send the messages to server until SSL status is turned into STATUS_CONNECTED_TO[0] after overwriting the server's self-signed certificate. The add-on side follows the exactly same steps to connect to server before and after rebooting the TV. I will try investigating what's the difference between before and after the rebooting of TV.

Steps to setup OpenSSL server
-----------------------------------------
1. Generating a 2048 bit RSA private key
$ openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes
2. Generating DH parameters with 2048 bit long safe prime and generator
$ openssl dhparam -out dh_2048.pem 2048
(This is to avoid issue[1]. The minimal bits for DH in Gecko is 1023[2])
3. Start the server
$ openssl s_server -key key.pem -cert cert.pem -dhparam dh_2048.pem -accept 4433
4. Connect to the server by the ip address with the port 4433. The output will be:
Setting temp DH parameters
Using default temp ECDH parameters
ACCEPT
bad gethostbyaddr // It causes no harm; it just passes back a nullptr for the hostname
{"type":"auth","action":"request_handshake"}


[0] https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsISocketTransport.idl#142
[1] https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/ssl3con.c#7499
[2] https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/nss/nssoptions.h#19
From add-on's log, the following error shows only after the rebooting of TV.

---------------------------------------------------------------------------
192.168.1.111:44186 uses an invalid security certificate.

The certificate is not trusted because it is self-signed.
The certificate is not valid for the name 192.168.1.111.
The certificate expired on 12/31/00 08:00. The current time is 06/08/16 11:01.

Error code: <a id="errorCode" title="SEC_ERROR_UNKNOWN_ISSUER">SEC_ERROR_UNKNOWN_ISSUER</a>
---------------------------------------------------------------------------

There are three errors. The first two are already overwritten by Ci.nsICertOverrideService.ERROR_UNTRUSTED and Ci.nsICertOverrideService.ERROR_MISMATCH in add-on. The third error, "The certificate expired on 12/31/00 08:00. The current time is 06/08/16 11:01.", is caused by time issue. The certificate indicates that it's expired by 2000/12/31, but the time now is 2016/06/08. 

From testing on TV side, at the moment of generating self-signed certificate, the year of the current time is 2000. It's apparently wrong. Thus, there is two approachs:

1. Use the correct time to generate certificate on TV side
2. Overwrite certificate time error by Ci.nsICertOverrideService.ERROR_TIME in add-on side.

For me, I will take approach 2 for now because we only use TLS to establish a confidential channel. The only requirement is the messages are encrypted. The approach 1 might take too much time to correct.
Hi Mike,
I was wondering if you could help us to test it in your environment. Please update both Gecko and Gaia to the latest version on TV side. The newest version of add-on has a workaround for this issue. You can install it to test again. If the connection can be established successfully before and after rebooting of TV, please resolve this bug. I will open a new bug for tracking the root cause of this problem. Thanks!
Flags: needinfo?(mlien)
Assignee: etsai → cchang
(In reply to Mike Lien[:mlien] from comment #6)
> Add-on
> https://github.com/ChunMinChang/fennec-fxos-tv/commit/
> a8e285547f333e3130481025ad9abce3fd018911
Please make sure there is no "Send-tab-to-tv" in your add-ons, it may be conflicted with the remote-control.

Alternative way is to download the custom fennec with the built-in add-on from the following link:
http://people.mozilla.org/~cchang/fennec-49.0a1.en-US.android-arm.apk

All you need is inside the custom fennec itself.
Flags: needinfo?(mlien)
Mike, could you help to clarify current status? Still not easy to discovery TV?
Verify again with the latest build, cannot reproduce this issue.

[Build Information]
2.6 Nexus Player:
gaia:
https://github.com/mozilla-b2g/gaia/commit/efa9514dbd028bbd243246cb94e354d78ccff04b
gecko:
https://github.com/mozilla-b2g/gecko-b2g/commit/e81fd19f9e908939f9476b95b85d09e155b4aaea

Fennec add-on:
https://github.com/ChunMinChang/fennec-fxos-tv/commit/48bee4df266fe08e19c81e1d8aa3d4fa8b3da6c2
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Flags: needinfo?(mlien)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.