From 192.168.116.105 icmp_seq=5792 Destination Host Unreachable
Что я ещё мог пропустить?
[⚠] Ваш провайдер подменяет DNS-записи, но не перенаправляет чужие DNS-серверы на свой.
Вам поможет смена DNS, например, на Яндекс.DNS 77.88.8.8 или Google DNS 8.8.8.8 и 8.8.4.4.
[⚠] Ваш провайдер полностью блокирует доступ к HTTPS-сайтам из реестра.
[⚠] Согласно isup.me, часть проверяемых сайтов сейчас не работает. Убедитесь, что вы используете последнюю версию программы, и повторите тест позже.
[⚠] Если проигнорировать isup.me, то у вашего провайдера "полный" DPI. Он отслеживает ссылки даже внутри прокси, поэтому вам следует использовать любое шифрованное соединение, например, VPN или Tor.
garron.me
Пакетик проёбывается на routing decision, судя по расставленным -j LOG. В ответ присылают ECONNREFUSED для tcp и нихуя для udp. Как отдебажить?
Пакетик проёбывается на routing decision, судя по расставленным -j LOG. В ответ присылают ECONNREFUSED для tcp и нихуя для udp. Как отдебажить?
время от времени, при tcp запросов с linux на linux не происхадил хэндшэйк
как оказалось, с определённой версии ядра tcp_timestamps включен
и сесли пакет прилетал из будующего, то хэндшэйк не происходил
проблема излечилась просто
sysctl net.ipv4.tcp_timestamps=0
tcpdump -i eth0 показывает, что исходящий пакет идёт:
#
U 10.1.1.18:5060 -> 37.195.247.192:5060
SIP/2.0 100 Trying..Via: SIP/2.0/UDP 172.28.1.6:5060;branch=z9hG4bK247018018;received=37.195.2
Но в iptables он никак не мигает!
root@francl:~# iptables -t nat -L -n -v
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 SNAT udp — 0.0.0.0/0 0.0.0.0/0 to:193.77.220.181
0 0 SNAT all — * eth0 10.1.1.18 0.0.0.0/0 to:193.77.220.181
0 0 SNAT all — 10.1.1.18 !10.0.0.0/8 to:193.77.220.181
1291 77526 SNAT all — 192.168.1.0/24 !192.168.1.0/24 to:10.1.1.7
как такое может быть?!?!
WoL работает только при первой загрузке ПК после его включения в электросеть, далее WoL перестаёт работать пока не отключишь ПК от электросети.
Оказалось, что после включения ПК WoL отключается, что видно в выводе ethtool:
# ethtool eth0 | grep Wake-on
Supports Wake-on: pumbg
Wake-on: d
Решается это очевидно: добавлением команды 'ethtool -s $IFACE wol g' в директиву 'up'(возможно подойдут и прочие директивы этого типа) блока настроек соответствующего сетевого интерфейса в файле /etc/network/interfaces .
Другие сочетения ОС, сетевой и драйвера не пробовал.
speedtest.sng01.softlayer.com — гляньте от себя.
По-моему, работая с деревьями и поиском o(log(n)), где 0<=n<=128 это как-то не сильно роялит, или я где-то туплю с усталости?
Короче говоря, судя по всему, меня ждут ад и муки отладки, дабы заставить свой код нормально работать под XP.
И не надо мне говорить, что оно устарело. У меня лицензия и старый комп. Я не могу туда водрузить ничего новее. Так что буду пилить и пытаться.
code execution. (то есть исполнение исходного кода на клиенте)
Что мы имеем сейчас? Браузер, основная задача которого — рендерить html,
используется как платформа для запуска приложений. При этом в качестве гуйни
используется html + css, а языка логики — js.
Нужно ли говорить о том, что html + css — не самый лучший формат описания GUI
приложений, а js (со слабой типизацией) — не самый лучший язык описании
логики? Конечно, стоит отдать должное, что компиляторы js неплохо вылизываются
и оптимизируются, даже всякие node.js и asm.js пилятся, но сам язык-то убогий
клон схемки с алголосинтаксисом.
Реальный state of art вебдваноля таков, что web-приложения это игрушки и куцые
клоны своих десктопных аналогов. Из чего-то узбл, я могу вспомнить только
gmail, который состоит из миллиона строк на JS.
TLDR:
* Для платформы запуска remote кода используется HTTP БРАУЗЕР, БРАУЗЕР блеать;
* Capability-based секурити нету;
* В некоторых браузерах (в лисе, например) запущеный js начинает теч или накручивать CPU, то хер поймешь почему.
Внимание вопрос: какие альтернативные средства запуска удаленного кода на клиенте родило человечество?
из более-менее нормального припоминаю только java applets, есть еще чо?
economics.lb.ua
Ну да, электричество и все остальное — то подождет. первым делом надо навести шмон с цензурой, чтобы не читали и не смотрели ua-сайты и телек. все правильно, кгб рулит )
интервью с одним из лидеров "Правого сектора"). Жаль, неплохое было
издание, много лет читал его постоянно. Фамилия нового — Гоеславский,
логично и новости такие же ожидать (.
[05/03/14 22:25:39] Kirill Sotnikov: чтобы колонки подключить только в одно место и именно весь звук, про мпд я в курсе
вроде пЫнг нормалезовалсэ.
При этом wifianalyzer показывает, что на этом канале я один сижу.
Что за худоба?! :(
в общем, кроссафцы, со второй камерой такой фокус не проходит.. "live555" и не пахнет — видимо, выкосили строки, или используют еще более древние куски его.
Workaround #1: тупой reconnect поймав первый же garbage в канале.
потери при этом = примерно времени, на которое замирал поток (где-то 600 RTP фреймов на каждую секунду лага для камеры fullhd)
Workaround #2: reconnect сразу после sleep()'а (прервать со своей стороны, превентивно): эффект полностью аналогичен WA#1
Workaround #3: попытаться ресинхронизоваться внутри потока. Метод показал самый лучший эффект! Во-1х: абсолютные потери синхронизации при этом примерно втрое меньше, чем при реконнекте (потери при реконнекте обычно около 1500-1800 RTP пакетов, 600 пакетов на 1сек задержки (при потоке 240 пакетов/сек); при ресинхронизации потери составляют 300-400 пакетов на 1сек, и в абсолютных цифрах где-то вдвое меньше,чем при реконнекте.
А самое главное — соединение НЕ ПАДАЕТ, а значит, алгоритм адаптации TCP Window и Receive Buffer'ов работает без потерь, и практически моментально наращивает буфера так, что потери просто исчезают! Код всё так же регулярно залипает на 1-2-3 секунды, но поток не рвётся!
Это просто фантастика!
Причем это реально ЛУЧШЕ (имхо), чем рвать соединение целиком: номера RTP пакетов в коннекте есть, так что без проблем потерянный объём можно замерить.
Если канал тоньше, чем пропускная способность сети — то потери будут расти, таким образом, обнаружив потери больше чем на 5 сек — можно спокойно жаловаться на толщину канала (реконнектиться с меньшим качеством, попросить поменять кабель, взорвать АЭС, или любой другой способ реакции на эту проблему); если же проблема в том, что приёмник просто не успевает по какой-то причине выгребать — resync поведение = наше щасте. Получаем объединение плюсов одновременно UDP и TCP подходов: если совсем что-то плохо — кусочек потеряли; в остальных случаях — ретрансмиты автоматические и проблем не доставляют.
Пойду еще потыкаю палочкой с сервера виндового.
2 @maxlapshin: уродский наколеночный код можно глянуть тут: github.com
потыкай этой палочкой камеры, которые у тебя под ногами есть — сработает подход? или это только на моих экземплярах паштет?
Причем поток средний перед поломкой 500кбайт/сек.
Если поток перед поломкой ~600кбайт/сек — ломается через 300кбайт.
Короче, похоже, что ломается поток через пол секунды
# Блин. Для просто проиграть, как оказалось, даже авторизации камера не требует: ################## require 'socket' require 'pp' host = '172.28.1.95' conn = TCPSocket.new(host, 554) setupmsg = "SETUP rtsp://#{host}/mpeg4/track1 RTSP/1.0\r\nCSeq: 1\r\nTransport: RTP/AVP/TCP;unicast\r\n" playmsg = "PLAY rtsp://#{host}/mpeg4/ RTSP/1.0\r\nCSeq: 2\r\nRange: npt=0.000-" conn.send(setupmsg+"\r\n", 0) res, = conn.recvfrom 1500 sess = res.split("\r\n")[-1] conn.send(playmsg+sess+"\r\n"+"\r\n", 0) res, = conn.recvfrom 1500 pp "1: ", res res, = conn.recvfrom 1500 pp "2: ", res conn.close()
А в случае TCP — серверный порт 554? А клиентский любой?
Да вы что все, сговорились, что-ли...
1) В настройках винды, ибо MTU=1300 (fixed), TcpMaxWindow=65480 (fixed), ну и Tcp1323 тоже включать надо (fixed too)
2) В приложении. Ибо, прошу прощения, 6 ядер по 3.2 гигагерца, загрузка 20%, а оно не успевает вычитывать всё из сети — явно хреновое приложение
3) В камере — если приложение не успевает выгребать и на недолго блокирует поток — поток рвётся.
Не могу сказать какой длительности надо лаг, чтобы оно пропало, но похоже дело в этом.
Хотя стоп, это не отвечает на вопрос "почему рвётся UDP поток, причем весьма стабильно"
Иначе говоря я смотрю и нифига не понимаю с какого перепою оно вдруг перестало работать, оборвалось и переконнектилось O_O
При этом прямо перед обрывом последнее что было — это в сторону камеры улетело, весьма незадолго до обрыва.
"SET_PARAMETER rtsp://172.28.1.91/mpeg4/ RTSP/1.0
CSeq: 6
Authorization: Digest username="admin", realm="LIVE555 Streaming Media", nonce="d98f67aa469f62b2f085df51da15f66a", uri="rtsp://172.28.1.91/mpeg4/", response="d2efc4473d07e3ee3a16e77bf10d261f"
Session: 4B54AFC7
User-Agent: Intellect"
Я уже на что только не грешил: кабеля заменил, порты на свичах переткнул в hi prio.
Но это всё фигня, так как поток 15мбит, а протянут гигабит.
То есть вообще речь совсем не об этом. ЧОЗАФИГНЯ?!
Wireshark говорит Avg Bandwidth — 15mbit.
Замерил ноутом и свичом — 500мбит в обе стороны работает на ура.
Так что не сеть. Чозахня, вот в чем вопрос.