Closed Bug 966564 Opened 8 years ago Closed 8 years ago

STUN logging is reporting wrong transport

Categories

(Core :: WebRTC: Networking, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla30

People

(Reporter: drno, Assigned: bwc)

Details

Attachments

(2 files, 1 obsolete file)

In case of a network which blocks all UDP and the call goes over TURN TCP the STUN logs still reports reading from UDP.

It seems the string representation of the transport is outdated for some reason, as the attached patch which updates the string every time after reading from it fixes the issue (with the patch UDP no longer shows up in the log).

We should probably find a better way of updating the string less often, but still have been reported correctly.
Assignee: nobody → docfaraday
So, I'm seeing some places where we are hard-coding UDP nr_transport_addr, but what I'm not seeing is where we could be switching that addr over to TCP, allowing a subsequent call to nr_transport_addr_fmt_addr_string to fix things up. Also, using ice_unittest, I can see that TURN TCP traffic is logged with the right string, whereas after it is unwrapped it is always logged as UDP (this is consistent with my reading of the code), both before and after the patch is applied.

Can you send r_log at DEBUG so I can try to figure out whether we're seeing the same thing?
Flags: needinfo?(drno)
Status: NEW → ASSIGNED
Attached file stun.log.bz2
This contains lines like this one:
(ice/DEBUG) ICE(PC:1394599591666615 (id=19 url=https://apprtc.appspot.com/?r=56411989)): Read 999 bytes from IP4:23.236.53.1:51895/UDP
although TURN TCP was used.
Flags: needinfo?(drno)
Are you saying that after unwrapping a STUN packet from a TCP connection would always log UDP?
I understand that we will get the full STUN packet from the far end as it got wrapped into the send indication by the far end. But this original packet does not contain a transport indication, or? Because the log file above was taken on the same machine with two browsers and the machines firewall blocked UDP. So there really should be no UDP on the media path.
(In reply to Nils Ohlmeier [:drno] from comment #4)
> Are you saying that after unwrapping a STUN packet from a TCP connection
> would always log UDP?

   Yes. This is because we try to log using the tuple that the sender is using to talk to the relay, as indicated in the XOR_PEER_ADDR attribute, but this attribute does not indicate transport protocol. So we just assume UDP (since there is no reason to think otherwise).
This should make the logging more clear.
Attachment #8368986 - Attachment is obsolete: true
Comment on attachment 8389926 [details] [diff] [review]
Make logging more clear when processing an unwrapped indication.

Would this clarify things sufficiently?
Attachment #8389926 - Flags: review?(drno)
Comment on attachment 8389926 [details] [diff] [review]
Make logging more clear when processing an unwrapped indication.

lgtm
Attachment #8389926 - Flags: review?(drno) → review+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/7884913fe074
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.