Как решить: UDP-отправка xxx байтов не удалась с ошибкой 11 в Ubuntu?

Отправка по протоколу UDP XXXX байт не удалась из-за ошибки 11

Я запускаю потоковое приложение WebRTC на Ubuntu 16.04. Он передает видео и аудио с веб-камеры Logitec HD Webcam c930e в настольном приложении Electronjs.

Все работает отлично и плавно на другой моей машине 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 подключается к серверу Heroku (Nodejs), и другая сторона однорангового соединения (браузер Chrome) также подключается к нему. Сервер Heroku действует как сервер квитирования для установления соединения WebRTC. Оба имеют конфигурацию:

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

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

а также дополнительный сервер Turn от numb.viagenie.ca

Соединение устанавливается и в течение первых 10 секунд качество очень высокое и лагов нет вообще. Но затем через 10-20 секунд происходит отставание, и на консоли Ubuntu я получаю эти ошибки UDP.

ПК, на котором работает Ubuntu:

ПРОЦЕССОР/ЧИПСЕТ:

ЦП Intel Core i3 (2-го поколения) 2310M / 2,1 ГГц

Количество ядер: двухъядерный

Кэш: 3 МБ

64-битные вычисления: Да

Тип чипсета: Мобильный Intel HM65 Express

ОЗУ:

Частота памяти: 1333 МГц

Соответствие спецификации памяти: PC3-10600

Технология: DDR3 SDRAM

Установленный размер: 4 ГБ

Номинальная частота памяти: 1333 МГц

Графика

Графический процессор Intel HD Graphics 3000

Может ли кто-нибудь дать мне несколько советов или что-нибудь, что могло бы решить эту проблему?

Спасибо

============== РЕДАКТИРОВАТЬ==============

Я нашел в своем очень большом журнале 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


person Nerd    schedule 13.05.2018    source источник


Ответы (1)


Во-первых, чтобы получить представление о том, что происходит в первую очередь, я бы смотрел со страхом. Запустите свое приложение с помощью

strace -e network -o log.strace -f YOUR_APPLICATION

Если ваше приложение ищет другой запущенный процесс, чтобы включить работу, запустите его с параметрами, чтобы оно этого не делало. Например, для Chrome передайте значение --user-data-dir, которое отличается от вашего по умолчанию.

После этого найдите = 11 в выходном файле log.strace и посмотрите, что произошло до и после. Это даст вам приблизительное представление о том, что происходит, и вы сможете исключить глупые ошибки, такие как sendtos to 0.0.0.0 или около того (по этой причине это также очень важная информация, которую нужно включить в вопрос о переполнении стека, например, загрузив вывод в суть).

Также может быть полезно использовать Wireshark или другую программу захвата пакетов, чтобы получить приблизительный обзор того, что отправляется .

Предполагая, что вы можете подтвердить с помощью strace, что имеет место действительный вызов send, вы можете затем проанализировать условия ошибки.

Ошибка 11 — EAGAIN . документация send говорит, когда эта ошибка предполагается произойдет:

EAGAIN (...) Сокет помечен как неблокирующий, и запрошенная операция будет заблокирована. (...)

EAGAIN (сокеты дейтаграмм интернет-домена) Сокет, на который ссылается sockfd, ранее не был привязан к адресу, и при попытке привязать его к эфемерному порту было определено, что все номера портов в эфемерном диапазоне портов в настоящее время используются. См. обсуждение /proc/sys/net/ipv4/ip_local_port_range в ip (7).

Оба условия могут применяться. Первый будет очевиден из журнала strace, если вы проследите создание задействованного сокета.

Чтобы исключить второе, вы можете запустить netstat -una (или, если вы хотите узнать, какие программы задействованы, sudo netstat -unap), чтобы увидеть, какие порты открыты (если вы хотите, чтобы пользователи Stack Overflow заглянули в него, опубликуйте вывод на gist или аналогичный и ссылка на него здесь). Ваш диапазон портов net.ipv4.ip_local_port_range=1024 65535 не является стандартным 32768 60999; похоже, вы уже пытались что-то сделать с отсутствием номеров портов. Было бы полезно проследить причину, по которой вы изменили этот параметр, и условия, которые убедили вас сделать это.

person phihag    schedule 13.05.2018
comment
привет, спасибо. Хорошо, во-первых, я запустил приложение с помощью strace, и оно вывело около 200 файлов журнала. Это должно произойти? Или как я могу сделать 1 файл журнала? - person Nerd; 13.05.2018
comment
Ух ты, тогда у вас действительно многопроцессорное приложение. Используйте -f вместо -ff, чтобы сбросить все в один файл. Обновил этот ответ. - person phihag; 13.05.2018
comment
ОК, этот файл очень-очень большой (не могу просто скопировать его в суть, извините). Теперь я нашел где-то эти две строки (я не могу подтвердить, что это единственные) ==> посмотрите мой отредактированный вопрос внизу, пожалуйста. - person Nerd; 13.05.2018
comment
Хм? Этот файл должен быть не более 1-2 ГБ. Вы ищете первое вхождение = 11. Здесь сначала происходит ошибка, а все, что потом, — лишь следствие. Из этой строки отследите сокет по ID. Материал, который вы разместили в gist, - это просто местное общение (возможно, отключение видео/аудиоканалов). В любом случае вы можете запустить netstat, как описано в этом ответе, чтобы определить, является ли проблема исчерпанием порта UDP. - person phihag; 13.05.2018