如何解决:在Ubuntu中,xxx字节的UDP发送失败,错误11?

时间:2018-05-13 17:50:14

标签: udp webrtc ubuntu-16.04 stun turn

XXXX字节的UDP发送失败,错误为11

我正在Ubuntu 16.04上运行WebRTC流媒体应用。 它通过Electronjs桌面应用程序在Logitec HD Webcam c930e中传输视频和音频。

在我的其他机器Macbook Pro上运行良好且流畅。但是在我的Ubuntu机器上,当建立对等连接10-20秒后我收到错误:

[2743:0513/193817.691636:ERROR:stunport.cc(282)] Jingle:Port[0xa5faa3df800:audio:1:0:local:Net[wlx0013ef503b67:192.168.0.x/24:Wifi]]: UDP send of 1019 bytes failed with error 11
[2743:0513/193817.691775:ERROR:stunport.cc(282)] Jingle:Port[0xa5faa3df800:audio:1:0:local:Net[wlx0013ef503b67:192.168.0.x/24:Wifi]]: UDP send of 1020 bytes failed with error 11
[2743:0513/193817.696615:ERROR:stunport.cc(282)] Jingle:Port[0xa5faa3df800:audio:1:0:local:Net[wlx0013ef503b67:192.168.0.x/24:Wifi]]: UDP send of 1020 bytes failed with error 11
[2743:0513/193817.696777:ERROR:stunport.cc(282)] Jingle:Port[0xa5faa3df800:audio:1:0:local:Net[wlx0013ef503b67:192.168.0.x/24:Wifi]]: UDP send of 1020 bytes failed with error 11
[2743:0513/193817.712369:ERROR:stunport.cc(282)] Jingle:Port[0xa5faa3df800:audio:1:0:local:Net[wlx0013ef503b67:192.168.0.x/24:Wifi]]: UDP send of 1029 bytes failed with error 11
[2743:0513/193817.712952:ERROR:stunport.cc(282)] Jingle:Port[0xa5faa3df800:audio:1:0:local:Net[wlx0013ef503b67:192.168.0.x/24:Wifi]]: UDP send of 1030 bytes failed with error 11
[2743:0513/193817.713086:ERROR:stunport.cc(282)] Jingle:Port[0xa5faa3df800:audio:1:0:local:Net[wlx0013ef503b67:192.168.0.x/24:Wifi]]: UDP send of 1030 bytes failed with error 11
[2743:0513/193817.717713:ERROR:stunport.cc(282)] Jingle:Port[0xa5faa3df800:audio:1:0:local:Net[wlx0013ef503b67:192.168.0.x/24:Wifi]]: UDP send of 1030 bytes failed with error 11 

==>顺便说一句,如果我不流式传输音频,只能视频。我得到了同样的错误,但只有"视频"日志行之间......

在某些行之间我也有一行说:

[3441:0513/195919.377887:ERROR:stunport.cc(506)] sendto: [0x0000000b] Resource temporarily unavailable

我也查看了sysctl.conf并增加了那里的值。我的货币 sysctl.conf 如下所示:

fs.file-max=1048576
fs.inotify.max_user_instances=1048576
fs.inotify.max_user_watches=1048576
fs.nr_open=1048576
net.core.netdev_max_backlog=1048576
net.core.rmem_max=16777216
net.core.somaxconn=65535
net.core.wmem_max=16777216
net.ipv4.tcp_congestion_control=htcp
net.ipv4.ip_local_port_range=1024 65535
net.ipv4.tcp_fin_timeout=5
net.ipv4.tcp_max_orphans=1048576
net.ipv4.tcp_max_syn_backlog=20480
net.ipv4.tcp_max_tw_buckets=400000
net.ipv4.tcp_no_metrics_save=1
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_synack_retries=2
net.ipv4.tcp_syn_retries=2
net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_wmem=4096 65535 16777216
vm.max_map_count=1048576
vm.min_free_kbytes=65535
vm.overcommit_memory=1
vm.swappiness=0
vm.vfs_cache_pressure=50

像这里建议的那样:https://gist.github.com/cdgraff/7920db287988463aafd7ea09eef6f9f0

它似乎没有帮助。我仍然遇到这些错误而且我在另一方面经历了滞后。

其他信息:在Ubuntu上,Electronjs App连接到Heroku Server( Nodejs ),而对等连接的另一端(Chrome浏览器)也连接到它。 Heroku Server充当握手服务器以建立WebRTC连接。两者都有配置:

{'urls': 'stun:stun1.l.google.com:19302'},

{'urls': 'stun:stun2.l.google.com:19302'},

还有来自numb.viagenie.ca的额外转弯服务器

建立连接,在最初的10秒内质量非常高,并且没有任何滞后。但是经过10-20秒之后就会出现滞后现象,在Ubuntu控制台上我遇到了这些UDP错误。

运行Ubuntu的PC:

PROCESSOR / CHIPSET

  

CPU Intel Core i3(第二代)2310M / 2.1 GHz

     

核心数量:双核

     

缓存:3 MB

     

64位计算:是

     

芯片组类型:Mobile Intel HM65 Express

RAM

  

内存速度:1333 MHz

内存规格符合性:PC3-10600

  

技术:DDR3 SDRAM

     

已安装尺寸:4 GB

     

额定内存速度:1333 MHz

图形

  

图形处理器Intel HD Graphics 3000

可以请任何人给我一些提示或任何可以解决这个问题的东西吗?

谢谢

============== EDIT =============

我在我的非常大的strace日志中发现了这两行:

7671  sendmsg(17, {msg_name(0)=NULL, msg_iov(1)=[{"CHILD_PING\0", 11}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 11

7661  <... recvmsg resumed> {msg_name(0)=NULL, msg_iov(1)=[{"CHILD_PING\0", 12}], msg_controllen=32, [{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, {pid=7671, uid=0, gid=0}}], msg_flags=0}, 0) = 11

最重要的是,当错误发生时(在我退出应用程序之前,在日志文件的末尾),我在日志文件中看到以下内容:

https://gist.github.com/Mcdane/2342d26923e554483237faf02cc7cfad

1 个答案:

答案 0 :(得分:0)

首先,要想先了解一下正在发生的事情,我会看一下strace。使用

启动您的应用程序
strace -e network -o log.strace -f YOUR_APPLICATION

如果您的应用程序寻找另一个正在运行的进程来转换工作,请使用参数启动它,这样就不会这样做。例如,for Chrome, pass in a --user-data-dir值与您的默认值不同。

之后在输出文件= 11中查找log.strace,然后查看之前和之后发生的事情。这将让您大致了解正在发生的事情,并且可以将诸如sendtos之类的愚蠢错误排除在0.0.0.0左右(因此,这也是包含在stackoverflow问题中的非常重要的信息,例如通过上传输出到gist)。

使用Wireshark或其他数据包捕获程序来粗略了解正在发送的内容也可能会有所帮助。

假设您可以通过strace确认发生了有效的send来电,则可以进一步分析错误情况。

Error 11 is EAGAINdocumentation of send表示应该发生此错误:

  

EAGAIN(...)套接字被标记为非阻塞,请求的操作将被阻止。 (...)

     

EAGAIN(Internet域数据报套接字)引用的套接字   sockfd以前没有被绑定到一个地址,并且在   试图将它绑定到一个短暂的端口,确定了所有   短暂端口范围内的端口号目前正在使用中。看到   讨论/ proc / sys / net / ipv4 / ip_local_port_range in   ip(7)

这两个条件都适用。 如果跟踪所涉及的套接字的创建,第一个将由strace日志显而易见。

要排除第二个,您可以运行netstat -una(或者,如果您想了解所涉及的程序,sudo netstat -unap)以查看哪些端口是打开的(如果您希望Stack Overflow用户查看)它,将输出发布在gist或类似内容并在此链接到它)。您的端口范围net.ipv4.ip_local_port_range=1024 65535不是标准32768 60999;这看起来像你试图做一些关于缺少端口号的事情。这将有助于追溯您更改该参数的原因以及说服您这样做的条件。