New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 2320 link

Starred by 13 users

Issue metadata

Status: Duplicate
Merged: issue 8809
Owner: ----
Closed: May 2017
Cc:
Components:
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocked on:
issue 8809



Sign in to add a comment

EWOULDBLOCK and error 10035 on ICE TCP connection

Reported by sergio.g...@gmail.com, Aug 29 2013

Issue description

What steps will reproduce the problem?
1. Use ICE TCP to connect to custom server
2. Connection is established, but after a while everything freezes

What is the expected result?
Testing on local network works flawlessly.

What do you see instead?
[9728:7356:0829/130629:VERBOSE1:tcpport.cc(153)] Jingle:Port[audio:1:0:local:Net[{67DC9BE9-3E1F-4561-BF11-730E10A2B1F9}:192.168.64.1/32]]: TCP send of 64 bytes failed with error 10035
[9728:7356:0829/130629:VERBOSE1:port.cc(610)] Jingle:Port[audio:1:0:local:Net[{67DC9BE9-3E1F-4561-BF11-730E10A2B1F9}:192.168.64.1/32]]: Failed to send STUN ping response to X.X.X.X:443
[9728:7356:0829/130629:VERBOSE1:tcpport.cc(153)] Jingle:Port[audio:1:0:local:Net[{67DC9BE9-3E1F-4561-BF11-730E10A2B1F9}:192.168.64.1/32]]: TCP send of 64 bytes failed with error 10035
[9728:7356:0829/130629:VERBOSE1:port.cc(610)] Jingle:Port[audio:1:0:local:Net[{67DC9BE9-3E1F-4561-BF11-730E10A2B1F9}:192.168.64.1/32]]: Failed to send STUN ping response to X.X.X.X:443
[9728:7356:0829/130629:VERBOSE1:tcpport.cc(153)] Jingle:Port[audio:1:0:local:Net[{67DC9BE9-3E1F-4561-BF11-730E10A2B1F9}:192.168.64.1/32]]: TCP send of 64 bytes failed with error 10035
[9728:7356:0829/130629:VERBOSE1:port.cc(610)] Jingle:Port[audio:1:0:local:Net[{67DC9BE9-3E1F-4561-BF11-730E10A2B1F9}:192.168.64.1/32]]: Failed to send STUN ping response to X.X.X.X:443
[9728:7356:0829/130629:VERBOSE2:channel.cc(768)] Got EWOULDBLOCK from socket.
[9728:7356:0829/130629:VERBOSE2:channel.cc(768)] Got EWOULDBLOCK from socket.
[9728:7356:0829/130629:VERBOSE2:channel.cc(768)] Got EWOULDBLOCK from socket.

What version of the product are you using? On what operating system?
31.0.1613.1 canary Aura

Please provide any additional information below.
I can provide testing html page and public server access for troubleshooting.


 
Project Member

Comment 1 by braveyao@webrtc.org, Aug 30 2013

Cc: mallinath@webrtc.org
Owner: braveyao@webrtc.org
@sergio, yes please help on the replication steps/environment. And please elaborate the difference between the success and failure case. Also the full chrome log.

sending info privately, as I cannot disclose publicly.

There is only one error EWOULDBLOCK which is error 10035. (The "and" was a typo)
Project Member

Comment 3 by juberti@webrtc.org, Sep 5 2013

Labels: Area-PeerConnection
Project Member

Comment 4 by braveyao@webrtc.org, Sep 7 2013

Did similar test with Apprtc Demo with TCP relay. No problem found.
It might be the test script's problem. Please check and try again.
Double checked and still happening, found this interesting TODO comment on tcpport.cc

int TCPConnection::Send(const void* data, size_t size) {
  if (!socket_) {
    error_ = ENOTCONN;
    return SOCKET_ERROR;
  }

  if (write_state() != STATE_WRITABLE) {
    // TODO: Should STATE_WRITE_TIMEOUT return a non-blocking error?
    error_ = EWOULDBLOCK;
    return SOCKET_ERROR;
  }
  int sent = socket_->Send(data, size);
  if (sent < 0) {
    error_ = socket_->GetError();
  } else {
    send_rate_tracker_.Update(sent);
  }
  return sent;
}

Project Member

Comment 6 by braveyao@webrtc.org, Sep 11 2013

Then how about a single page test? I enclosed a modifed pc1.html for simulating a tcp-relay test. 

Modifications:
@line 73, provide a TURN server with tcp transport. You can change it with your own TURN server since the user&credential would expire soon.
@line 121& 128, only add the relay candidates.

Please try it and see if it works to you or not. 
pc1-relay.html
3.7 KB View Download
In your test page you are using TURN TCP (turnport.cc) to send data from browser to the TURN server, which is not the same scenario in which I am getting the error.

In my scenario, browser is sending data to via an ICE TCP candidate (tcpport.cc).


Project Member

Comment 8 by braveyao@webrtc.org, Sep 12 2013

Cc: -mallinath@webrtc.org braveyao@webrtc.org vikasmarwaha@webrtc.org
Owner: mallinath@webrtc.org
Yes, that made the difference. It's about the error handling. 
The TCP socket should have some problem in your test and trigger the registered onClose() callback. Tcpport.cc, which is kind of legacy codes, would not try to reconnect so far, so it would set the socket to non-writable immediately. And Turnport.cc has implemented the reconnection part, so it still be ready for next send. 
As to what goes wrong, maybe you can tell from your sever side. (Or stick with rfc5766-turn-server for now?)

Anyhow, we would fulfill the functionality of Tcpport.cc in near future.  Handover to @mallinath.

Comment 9 by juberti@google.com, Jun 6 2014

Cc: pthatcher@webrtc.org
Mallinath, can you determine what needs to be done here?
Project Member

Comment 10 by juberti@webrtc.org, Aug 21 2014

Cc: mallinath@webrtc.org
Owner: pthatcher@webrtc.org
Not currently a high-priority issue. We'll fix the TCP reconnect issue, and then we can revisit this.
Project Member

Comment 11 by pthatcher@webrtc.org, Dec 11 2014

Labels: EngTriaged Mstone-43
Status: Available
Project Member

Comment 12 by vikasmarwaha@webrtc.org, Mar 31 2015

any update, still for M43?
Project Member

Comment 13 by pthatcher@webrtc.org, Apr 1 2015

Labels: -Mstone-43 Mstone-46
Project Member

Comment 14 by tnakamura@webrtc.org, Sep 2 2015

Cc: -mallinath@webrtc.org guoweis@webrtc.org
Labels: -Mstone-46
This didn't make M46, and it's been moved around for a while, so I'm clearing the M46 label. pthatcher/guoweis, please pick a new milestone when you get a chance. Thanks!
Privacy Statement
836 KB View Download
Project Member

Comment 16 by pthatcher@webrtc.org, Nov 8 2016

Labels: Pri-3
Project Member

Comment 17 by anatolid@webrtc.org, Dec 14 2016

Owner: ----
Status: Untriaged (was: Available)
Project Member

Comment 18 by deadbeef@chromium.org, May 6 2017

Blockedon: chromium:715484
Folding this into more general bug.
Project Member

Comment 19 by deadbeef@chromium.org, May 6 2017

Blockedon: -chromium:715484
Mergedinto: chromium:715484
Status: Duplicate (was: Untriaged)
Oops, meant to mark duplicate.
Project Member

Comment 20 by deadbeef@chromium.org, May 6 2017

Blockedon: chromium:715484

Sign in to add a comment