1528164 - Starting with firefox 65.0, I can't stream the video of the camera.

Status: RESOLVED INVALID

(Core :: WebRTC: Networking, defect)

Description

[gama.l]

Attachment: live-firefox-error.pcapng

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

I watched a live video of a camera through a website, which can be displayed normally before firefox 64, but it cannot be displayed normally after firefox 65.

Actual results:

I used wireshark to query the connection packets. After I found out that the camera communicated with the computer, when the client hello was connected to Firefox 65, Firefox replied to Handshake failure, so that the live video of the camera could not be seen. The same action in Firefox 64 is a normal connection success, so I don't know if the 65 version is different, how to fix it. Can refer to my attached wiring file, ip: 10.0.1.98 is my computer, ip: 10.0.1.55 is my camera.

Expected results:

Should be able to watch live video normally

Comment 1

[Matthias Versen [:Matti]]

Please use https://mozilla.github.io/mozregression/quickstart.html to find the change in Firefox that caused this problem.

Comment 2

[gama.l]

I use mozregression to test, it is to use Nightly version to compare, but I executed the result, firefox Nightly generated sdp video does not have H.264, my camera is using H.264 image, so use mozregression During the test, there was an error at the beginning, and even the webrtc connection was unsuccessful, and I could not test the problem I originally raised.

Comment 3

[u554753]

In which website are you experiencing this issue?

Comment 4

[gama.l]

I use the https://live.amaryllo.eu website, according to the camera icon, you will be asked to enter the ID and PASSCODE, you can enter the ID as iCRb0cz7n and PASSCODE as 7SQQDUK4, you can connect to my own camera.

Comment 5

[Matthias Versen [:Matti]]

Thank you very much for the testcase !
The reason why the Firefox builds launched by mozregression didn't work for you is that they start with a fresh Firefox user profile by default. The open264 codec isn't stored in that new profile and will be downloaded automatically some time later.
you can trigger the download with opening the addons manager (shift+a) -> plugins -> check for updates.

Anyway, this is my result
18:09.59 INFO: No more inbound revisions, bisection finished.
18:09.59 INFO: Last good revision: 9fb4fd49a8189f4da9998f9cf80d94f699c6b739
18:09.59 INFO: First bad revision: ae266baf08fe02facf73233fccf30140a42ef0f4
18:09.60 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9fb4fd49a8189f4da9998f9cf80d94f699c6b739&tochange=ae266baf08fe02facf73233fccf30140a42ef0f4

Nils Ohlmeier [:drno] — Bug 1227519: remove DHE ciphers from WebRTC DTLS handshake. r=mt

It looks like this problem is caused by removing the DHE encryption ciphers and I think that the website needs to change it's used ciphers. The developer of that change in Firefox will hopefully explain that in better words to you.

Comment 6

[Darkspirit]

It does neither work with Chrome for 2.5 years now, so the device vendor might need to provide an update to introduce support for modern encryption to ensure its product keeps usable with modern web browsers. :-/ https://www.chromestatus.com/features/5128908798164992
Safari doesn't support DHE either.

Comment 7

[gama.l]

Thank you for your suggestion, I can use mozregression to compare, I am comparing between 64 and 65 versions, in addition to the comparison you mentioned, there is another version that is different.

This is result:
95:28.32 INFO: No more inbound revisions, bisection finished.
95:28.32 INFO: Last good revision: 77f4c84bebf05b7fddb3f5bdb8e7de0d2eb3ebd6
95:28.32 INFO: First bad revision: dfa1eb1d036fc0b11a449627c0a69702b3f6309f
95:28.32 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=77f4c84bebf05b7fddb3f5bdb8e7de0d2eb3ebd6&tochange=dfa1eb1d036fc0b11a449627c0a69702b3f6309f

dfa1eb1d036f Jim Blandy — Bug 1499534: Add Pause, Resume, and IsPaused methods to ThrottledEventQueue. r=froydnj

The modification of this version seems to be independent of the transmission of DTLS. I don't know why the problem occurred.

Comment 8

[Byron Campen [:bwc]]

Yeah, the DTLS handshake is where this is failing according to the capture, and the cipher suites we disabled in bug 1227519 appear in the handshake. Here are the cipher suites we support right now.

            Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
            Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
            Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
            Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
            Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)

The choice to disable the DHE suites was carefully considered, and that's going to require some implementations to make changes.