859395 - Cannot establish a PC handshake from a machine on a VPN to a machine not on a VPN

Status: RESOLVED INVALID

(Core :: WebRTC: Audio/Video, defect, P3)

Description

[Jason Smith [:jsmith]]

STR:

1. On a Win 7 laptop with an integrated camera/mic only, go to apprtc.appspot.com
2. Grant permissions for the integrated camera/mic
3. On a Mac mini with a USB camera/mic, go to the URL of the same room the win 7 laptop is in
4. Grant permissions for the USB camera/mic

Expected:

Upon the handshake completing, I'd expect to see the remote stream on each respective machine.

Actual:

I end up seeing my local stream twice in a row and never see the remote video stream at all, even though the call indicates it's established. I've also tested a similar scenario with conversat.io and in that case, also did not see the remote stream rendering.

Comment 1

[Jason Smith [:jsmith]]

I've got a solid reproduction at my work station, so if someone in Mt View wants to see it, let me know.

I also verified that apprtc isn't broken - I established a call just fine with one of my peers no problem. This appears to be a problem in a specific configuration case across multiple machines.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

Logs with signaling:5,mtransport:5 would be appreciated from both machines, and from both machines in a case that works.  If this is from behind the Mozilla corp firewall, there could be issues.  I assume both are on the same network?  Same subnet or different?  Can the mac mini contact any other machine via apprtc?

Until we have logs, I'm going to assume this is a firewall/ICE issue, with a priority that will depend on why it's having problems.

Comment 3

[Jason Smith [:jsmith]]

Putting qawanted to note I need more info here.

Comment 4

[enda mannion (:emannion)]

I am seeing problems connecting to apprtc with the Nightly build 23.0a1.  Initially I thought it was network but it now seems isolated to certain OS's. I have problems on my Mac i386 snow leopard and on both of the Windows 7 32-bit machines.  It works on my Windows 7 64-bit manchines and my Mac Lion x86_64.

The problem seems the same as described in this bug by Jason, the calling browser remains in 'Initilizing' never going to 'Connecting...'  

Let me know if you want logs and I will email them directly.

Comment 5

[Jason Smith [:jsmith]]

(In reply to enda mannion (:emannion) from comment #4)
> I am seeing problems connecting to apprtc with the Nightly build 23.0a1. 
> Initially I thought it was network but it now seems isolated to certain
> OS's. I have problems on my Mac i386 snow leopard and on both of the Windows
> 7 32-bit machines.  It works on my Windows 7 64-bit manchines and my Mac
> Lion x86_64.
> 
> The problem seems the same as described in this bug by Jason, the calling
> browser remains in 'Initilizing' never going to 'Connecting...'  
> 
> Let me know if you want logs and I will email them directly.

Logs would be incredibly helpful in alignment with comment 2.

I still need to get the logs as well for my test case, but more logs available here the better.

Comment 6

[Jason Smith [:jsmith]]

Bouncing to ? since we've got a 2nd report now and I know it's not network-specific.

Comment 7

[Maire Reavy [:mreavy]]

I think we should keep this as blocking? (so it stays on our radar) until we can analyze the logs of these events.  The sooner we get logs for this, the better.  I just added a needinfo to Enda.

Not only do we want to figure out if this bug is in our code or not (it could be NAT dependent or dependent on how a NAT behaves), but also how likely a developer would be to hit this problem.  Even if this bug is not ours, I think we should investigate if there are useful workarounds we can recommend to devs and/or perhaps better error reporting back to the dev so he/she knows what's happening.

Comment 8

[Jason Smith [:jsmith]]

I just sent an email to Maire and Randell with the logs Enda sent to me. If Enda is okay with attaching them onto this bug, then we can add them to this bug.

Comment 9

[enda mannion (:emannion)]

Attachment: Successfull FF console log

From Mac 64 bit lion

Darwin emannion-mac 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64

Comment 10

[enda mannion (:emannion)]

Attachment: Successfull FF log

Also from same 64 bit Mac Lion

Comment 11

[enda mannion (:emannion)]

Attachment: Bad console log

From Mac 32 bit snow leopard


Darwin admins-macbook-pro-2.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

Comment 12

[enda mannion (:emannion)]

Attachment: Bad FF log

From same 32 bit mac

Comment 13

[enda mannion (:emannion)]

I attached the 4 logs from the two Macs.  Let me know if you need more information or to run some more tests.

Comment 14

[Maire Reavy [:mreavy]]

(In reply to enda mannion (:emannion) from comment #13)
> I attached the 4 logs from the two Macs.  Let me know if you need more
> information or to run some more tests.

Thanks for the logs.  If you could get us a Wireshark capture of the call that is having problems, that could be enormously helpful.

Comment 15

[Jason Smith [:jsmith]]

Sounds like Enda has the information to go forward. I'll try to work on getting my information as well, but it sounds like we aren't blocked anymore to move forward figuring out what's wrong and how to fix this.

Comment 16

[enda mannion (:emannion)]

Attachment: pcap from offending 32-bit mac, no filter

Comment 17

[Maire Reavy [:mreavy]]

(In reply to Jason Smith [:jsmith] from comment #15)
> Sounds like Enda has the information to go forward. I'll try to work on
> getting my information as well, but it sounds like we aren't blocked anymore
> to move forward figuring out what's wrong and how to fix this.

Actually, these logs don't contain the signaling and ICE info we need.  

Enda -- I need you to set NSPR_LOG_MODULES=signaling:5,mtransport:5 R_LOG_LEVEL=7 and rerun the test.  (Thanks for the pcap!)

Comment 18

[Randell Jesup [:jesup] (needinfo me)]

Do you see the gUM request and your own video?

Enda and Jason: can you verify if there's a little camera icon to the left of the URL?  If so, please click it and see if the request for gum comes up.  Also please try with a new profile (firefox -profilemanager and create one) to make sure it's not left-over permissions (like gum disabled!)

Comment 19

[enda mannion (:emannion)]

(In reply to Maire Reavy [:mreavy] from comment #17)
> (In reply to Jason Smith [:jsmith] from comment #15)
> > Sounds like Enda has the information to go forward. I'll try to work on
> > getting my information as well, but it sounds like we aren't blocked anymore
> > to move forward figuring out what's wrong and how to fix this.
> 
> Actually, these logs don't contain the signaling and ICE info we need.  
> 
> Enda -- I need you to set NSPR_LOG_MODULES=signaling:5,mtransport:5
> R_LOG_LEVEL=7 and rerun the test.  (Thanks for the pcap!)

I had been using those log settings it seem the problem is actually GUM related and suggested.  I had been seeing the camera icon and the dialog requesting to share my audio and video devices all along, also local video was displayed to the browser.   But when I did this in a new FF profile it works well now.  The two way call is working on my two macs, so the FF demo on macs will go ahead next week.  Thanks.

Comment 20

[enda mannion (:emannion)]

I will check on Monday if creating a new profile on those Win 7 32-bit machines also fixes this.

Comment 21

[Jason Smith [:jsmith]]

(In reply to enda mannion (:emannion) from comment #20)
> I will check on Monday if creating a new profile on those Win 7 32-bit
> machines also fixes this.

Hmm...interesting. Okay, I'll try this with clean profiles on both machines as well on my end.

Comment 22

[Randell Jesup [:jesup] (needinfo me)]

enda - please also check what permissions were being overridden in your "bad" profile.  perhaps media.peerconnection.enabled was false?

You can see an easy listing of changed prefs in about:support, or go to about:config and type media

Comment 23

[enda mannion (:emannion)]

In the "bad" profile I had already been through the prefs that I remember were used and they seemed fine.  Even now here is what I have in the bad profile.

media.peerconnection.aec;1
media.peerconnection.aec_enabled;true
media.peerconnection.agc;1
media.peerconnection.agc_enabled;false
media.peerconnection.default_iceservers;[{"url": "stun:23.21.150.121"}]
media.peerconnection.enabled;true
media.peerconnection.noise;1
media.peerconnection.noise_enabled;false
media.peerconnection.turn.disable;false
media.peerconnection.use_document_iceservers;true


Could it be some other setting related to XMLHttpRequest or HTTP or how ever the comms work between page and apprtc.

Here is what is in about:support

Important Modified Preferences
Name 	Value accessibility.typeaheadfind.casesensitive	1
accessibility.typeaheadfind.flashBar	0
browser.cache.disk.capacity	1048576
browser.cache.disk.smart_size_cached_value	1048576
browser.cache.disk.smart_size.first_run	false
browser.places.importBookmarksHTML	false
browser.places.smartBookmarksVersion	4
browser.startup.homepage_override.buildID	20130423210829
browser.startup.homepage_override.mstone	23.0a1
extensions.lastAppVersion	23.0a1
gfx.blacklist.webgl.msaa	4
network.cookie.prefsMigrated	true
places.database.lastMaintenance	1366991910
places.history.expiration.transient_current_max_pages	104858
plugin.disable_full_page_plugin_for_types	application/pdf
plugin.importedState	true
plugin.state.java	0
print.macosx.pagesetup-2	PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPCFET0NUWVBFIHBsaXN0IFBVQkxJQyAiLS8vQXBwbGUvL0RURCBQTElTVCAxLjAvL0VO
privacy.cpd.downloads	false
privacy.cpd.formdata	false
privacy.cpd.history	false
privacy.cpd.sessions	false
privacy.donottrackheader.enabled	true
privacy.sanitize.migrateFx3Prefs	true
privacy.sanitize.timeSpan	0
security.warn_viewing_mixed	false
storage.vacuum.last.index	1
storage.vacuum.last.places.sqlite	1366797793
webgl.force-enabled	true
webgl.prefer-native-gl	true

Comment 24

[Jason Smith [:jsmith]]

Attachment: NSPR Windows

Here's the windows NSPR log. Sorry for taking too long to get back on this. Mac one coming shortly.

Comment 25

[Jason Smith [:jsmith]]

Attachment: NSPR Mac

Comment 26

[Jason Smith [:jsmith]]

Randell - Are my logs telling you anything interesting on the issue I'm hitting on my two machines?

Comment 27

[Jason Smith [:jsmith]]

Attachment: Windows NSPR - Android to Desktop Call

Comment 28

[Jason Smith [:jsmith]]

Attachment: Android Logcat - Android to Desktop Call

Comment 29

[Jason Smith [:jsmith]]

Attachment: Windows Wireshark Log

Comment 30

[Jason Smith [:jsmith]]

Attachment: Standard Error Output on Windows 7 Debug Build

Comment 31

[Jason Smith [:jsmith]]

Working with jesup and ekr, we've narrowed down the real problem here.

The actual problem that's happening here is that you cannot establish a PC handshake between a machine on a VPN to a machine not on a VPN.

Comment 32

[enda mannion (:emannion)]

Which is different to my bug as I was not on a mixed network for any test, my problem was related to a bad\old FF profile. A profile created roughly 8-12 months ago.

Comment 33

[Eric Rescorla (:ekr)]

(In reply to Jason Smith [:jsmith] from comment #31)
> Working with jesup and ekr, we've narrowed down the real problem here.
> 
> The actual problem that's happening here is that you cannot establish a PC
> handshake between a machine on a VPN to a machine not on a VPN.


I don't believe this is the correct conclusion. Rather, there is something
about *your* VPN that is causing us a problem. If you provide complete
wireshark logs on both sides, we can try to diagnose whether the problem
is ICE or that your VPN is really blocking something important.

Comment 34

[Randell Jesup [:jesup] (needinfo me)]

Also, please include what VPN and what version you're using, and any config settings

Comment 35

[Jason Smith [:jsmith]]

Point of clarification - the VPN being used here Mozilla Mountain View's VPN through ethernet, not VPN software. The wireshark logs here are representing exactly what you are getting through that ethernet as a result.

Comment 36

[Jason Smith [:jsmith]]

So apparently this is invalid due to how Mozilla Guest is setup. Closing as such.