Воткнул в живую сеть включающую в себя ноутбук Н говнороутер Г с linux на борту. На Г циферки в ifconfig бегут, в iptables пусто, таблица маршрутизации вменяемая, но тем не менее с Н он не пингуется:
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.
Как можно протестировать передачу UDP по SOCKS5? Есть ли какие-нибудь простые тулзы для этого? netcat не хочет гнать UDP по SOCKS5, а socat вообще не понимает его
Есть ли способ поднять VPN-сервер без создания tun-девайсов? Чисто userspace приложение/библиотека, которое по tcp принимает трафик от пользователя VPN.
garron.me
Пакетик проёбывается на routing decision, судя по расставленным -j LOG. В ответ присылают ECONNREFUSED для tcp и нихуя для udp. Как отдебажить?
Затарился отакой антеннкой для удаленных от цывилизаций мест, где не ступала нога интернетов. Будем посмотреть, насколько оно лучше свистка с комнатными усилителями типа коннектов ; )
Залёз тут опять в дебри UDP и ICMP. Походу таки буду делать разбирание/собирание байтстроки на UDP пакеты с исследованием MTU. Тока я смотрю этого на цацкеле никто не пейсал. " Я сильная, я смелая и на голову ебанутая."
недавно встретился с проблемой.
время от времени, при tcp запросов с linux на linux не происхадил хэндшэйк
как оказалось, с определённой версии ядра tcp_timestamps включен
и сесли пакет прилетал из будующего, то хэндшэйк не происходил
проблема излечилась просто
sysctl net.ipv4.tcp_timestamps=0
биткоин в китае всё... bitnovosti.com
Ничерта не понимаю!
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
как такое может быть?!?!
Необычное для меня поведение относительно Wake-On-Lan обнаружил у сочетания ОС Ubuntu 12.04 LTS, сетевой карты Realtek 8101L(такой чип интегрированной сетевой карты указан в описании мат. платы, а lspci показывает 8139/8139C/8139C+) и драйвера 8139too:
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 .
Другие сочетения ОС, сетевой и драйвера не пробовал.
перезагрузил роутер и получил прирост скорости интернета в два раза.
А только от меня проблема со скоростью доступа в сторону softlayer ?
speedtest.sng01.softlayer.com — гляньте от себя.
"Мало того, программный поиск по массиву с нахождением наилучшего соответствия (longest match) — ну очевидно же, что тем медленнее, чем больше в массиве элементов, каким алгоритмом не ищи."
По-моему, работая с деревьями и поиском o(log(n)), где 0<=n<=128 это как-то не сильно роялит, или я где-то туплю с усталости?
Последний GTK-шный теплый ламповый Wireshark 1.12.0. В комплекте страшненький QTShark 2.0 Preview: wireshark.org
Злой у меня оператор. Удалённо только на тариф повыше забраться можно, а ниже — лично при поездке в офис. Эх-эх, с утричка и поеду.
Я просто поражаюсь этим мелкомягким. Серьёзно. Казалось бы: .net существует весьма давно и как бы по идее должен нормально работать даже в Windows XP. Но, нет! И это несмотря на то, что версия 3 существует уже давно и должна работать нормально и под ней.
Короче говоря, судя по всему, меня ждут ад и муки отладки, дабы заставить свой код нормально работать под XP.
И не надо мне говорить, что оно устарело. У меня лицензия и старый комп. Я не могу туда водрузить ничего новее. Так что буду пилить и пытаться.
Уже несколько раз натыкаюсь на дискуссии, что нынче проблема с controlled remote
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-сайты и телек. все правильно, кгб рулит )
Редакция lenta.ru заявляет про тыск и цензуру:
pravda.com.ua
lenta.ru — не сдавайтесь, я Вас читаю много лет!!
Ну что, в lenta.ru сменился главный редактор (после публикации
интервью с одним из лидеров "Правого сектора"). Жаль, неплохое было
издание, много лет читал его постоянно. Фамилия нового — Гоеславский,
логично и новости такие же ожидать (.
[05/03/14 22:25:16] Kirill Sotnikov: А вот интересно, есть ли такая софтина, которая стримит звук с одного устройства на другое?
[05/03/14 22:25:39] Kirill Sotnikov: чтобы колонки подключить только в одно место и именно весь звук, про мпд я в курсе
оставил только 20 ширину канала, ибо extension каналы и 2 и 10 перегружены до той матери.
вроде пЫнг нормалезовалсэ.
Что-то внезапно случилось, и пинг по вайвайваю стал ОЧЕНЬ нестабильным, до 1000мс.
При этом wifianalyzer показывает, что на этом канале я один сижу.
Что за худоба?! :(
судя по лапочкам свича, телек подключается на жалкие 100мбит. и отключается от сети при выключении — так что разбудить его через сеть невозможно :(
Ковырнул паршивку второй камеры. Там вообще всё зашито в какой-то бинарь под именем "Sophia", зачем-то сжатый upx. внутри нечто безымянное с коекакерской поддержкой onvif только шоп было, но с поддержкой всего и вся, включая GPS, wifi, блюпуп и фрешки.
в общем, кроссафцы, со второй камерой такой фокус не проходит.. "live555" и не пахнет — видимо, выкосили строки, или используют еще более древние куски его.
Угадайте, что находится по адресу procrastination.ru?
Итак, решил потестировать способы восстановления из поломки потока китайских камер из-за неуспевания выгребания.
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
потыкай этой палочкой камеры, которые у тебя под ногами есть — сработает подход? или это только на моих экземплярах паштет?
Запилил тестовый клиент, пойду теперь мучать китаёсов.
github.com
Автонастройка окна TCP в действии. Если sleep делать не сразу на 1сек, а постепенно наращивать, то спустя 2 минуты оно засыпает без проблем на 4 секунды; и до сдыхания после этого высасывается из канала сразу 107790983 байт!
Итак, в принципе, достаточно слипа даже в одну секунду — поток ломается после этого спустя ~250k байт (линупс)
Причем поток средний перед поломкой 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()
Что-то не понимаю. При UDP всё ясно — client И server порты передаются.
А в случае TCP — серверный порт 554? А клиентский любой?
Йесс, йа его подебил — digest сожрало, теперь можно писать мимимитатор проблем приемника.
Ну зашибись, все либы на питоне/руби для rtsp не умеют digest авторизацию.
Да вы что все, сговорились, что-ли...
Судя по всему, проблема — в трёх местах:
1) В настройках винды, ибо MTU=1300 (fixed), TcpMaxWindow=65480 (fixed), ну и Tcp1323 тоже включать надо (fixed too)
2) В приложении. Ибо, прошу прощения, 6 ядер по 3.2 гигагерца, загрузка 20%, а оно не успевает вычитывать всё из сети — явно хреновое приложение
3) В камере — если приложение не успевает выгребать и на недолго блокирует поток — поток рвётся.
Не могу сказать какой длительности надо лаг, чтобы оно пропало, но похоже дело в этом.
Хотя стоп, это не отвечает на вопрос "почему рвётся UDP поток, причем весьма стабильно"
Так, всё, логика у меня отказала, требуется помощь. Камеры отваливаются постоянно, причем что TCP что UDP. Смотрю ретрансмиты — за одну сессию от обрыва до обрыва (около 50 секунд) было всего 4 ретрансмита — 2 ack и 2 пакета, и это был не обрыв.
Иначе говоря я смотрю и нифига не понимаю с какого перепою оно вдруг перестало работать, оборвалось и переконнектилось 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мбит, а протянут гигабит.
То есть вообще речь совсем не об этом. ЧОЗАФИГНЯ?!
Разбираюсь с отвалами камер. Записал полный дамп в 5 минут — 600 Мбайт.
Wireshark говорит Avg Bandwidth — 15mbit.
Замерил ноутом и свичом — 500мбит в обе стороны работает на ура.
Так что не сеть. Чозахня, вот в чем вопрос.
Что про TP-Link TL-WR1043ND скажете? Мне DDWRT там не надо, мне надо только стабльный мультиплексинг на гигабите внутри, честные 100мбит данных по вафле, не помирающий DNS, и поддержка gre. USB на нём нафиг не надо.
Итого, первый облом у обжимки случаился меньше, чем на 30 коннекторах. Интересно, когда она совсем сдохнет? Кончится пакетик в 100 коннекторов, или раньше?