← All posts tagged net

datacompboy

Ничерта не понимаю!
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

как такое может быть?!?!

datacompboy
net

"Мало того, программный поиск по массиву с нахождением наилучшего соответствия (longest match) — ну очевидно же, что тем медленнее, чем больше в массиве элементов, каким алгоритмом не ищи."
По-моему, работая с деревьями и поиском o(log(n)), где 0<=n<=128 это как-то не сильно роялит, или я где-то туплю с усталости?

datacompboy
net

Что-то внезапно случилось, и пинг по вайвайваю стал ОЧЕНЬ нестабильным, до 1000мс.
При этом wifianalyzer показывает, что на этом канале я один сижу.
Что за худоба?! :(

datacompboy
net

судя по лапочкам свича, телек подключается на жалкие 100мбит. и отключается от сети при выключении — так что разбудить его через сеть невозможно :(

datacompboy

Ковырнул паршивку второй камеры. Там вообще всё зашито в какой-то бинарь под именем "Sophia", зачем-то сжатый upx. внутри нечто безымянное с коекакерской поддержкой onvif только шоп было, но с поддержкой всего и вся, включая GPS, wifi, блюпуп и фрешки.
в общем, кроссафцы, со второй камерой такой фокус не проходит.. "live555" и не пахнет — видимо, выкосили строки, или используют еще более древние куски его.

datacompboy

Итак, решил потестировать способы восстановления из поломки потока китайских камер из-за неуспевания выгребания.
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
потыкай этой палочкой камеры, которые у тебя под ногами есть — сработает подход? или это только на моих экземплярах паштет?

datacompboy

Автонастройка окна TCP в действии. Если sleep делать не сразу на 1сек, а постепенно наращивать, то спустя 2 минуты оно засыпает без проблем на 4 секунды; и до сдыхания после этого высасывается из канала сразу 107790983 байт!

datacompboy

Итак, в принципе, достаточно слипа даже в одну секунду — поток ломается после этого спустя ~250k байт (линупс)
Причем поток средний перед поломкой 500кбайт/сек.
Если поток перед поломкой ~600кбайт/сек — ломается через 300кбайт.
Короче, похоже, что ломается поток через пол секунды

datacompboy

# Блин. Для просто проиграть, как оказалось, даже авторизации камера не требует:
##################
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()

datacompboy

Судя по всему, проблема — в трёх местах:
1) В настройках винды, ибо MTU=1300 (fixed), TcpMaxWindow=65480 (fixed), ну и Tcp1323 тоже включать надо (fixed too)
2) В приложении. Ибо, прошу прощения, 6 ядер по 3.2 гигагерца, загрузка 20%, а оно не успевает вычитывать всё из сети — явно хреновое приложение
3) В камере — если приложение не успевает выгребать и на недолго блокирует поток — поток рвётся.
Не могу сказать какой длительности надо лаг, чтобы оно пропало, но похоже дело в этом.

Хотя стоп, это не отвечает на вопрос "почему рвётся UDP поток, причем весьма стабильно"

datacompboy

Так, всё, логика у меня отказала, требуется помощь. Камеры отваливаются постоянно, причем что 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мбит, а протянут гигабит.
То есть вообще речь совсем не об этом. ЧОЗАФИГНЯ?!

datacompboy

Разбираюсь с отвалами камер. Записал полный дамп в 5 минут — 600 Мбайт.
Wireshark говорит Avg Bandwidth — 15mbit.
Замерил ноутом и свичом — 500мбит в обе стороны работает на ура.
Так что не сеть. Чозахня, вот в чем вопрос.

datacompboy
net

Что про TP-Link TL-WR1043ND скажете? Мне DDWRT там не надо, мне надо только стабльный мультиплексинг на гигабите внутри, честные 100мбит данных по вафле, не помирающий DNS, и поддержка gre. USB на нём нафиг не надо.

datacompboy
net

Итого, первый облом у обжимки случаился меньше, чем на 30 коннекторах. Интересно, когда она совсем сдохнет? Кончится пакетик в 100 коннекторов, или раньше?