Чтобы добавлять сообщения и комментарии, .

@Zert:
Zert

Как можно протестировать передачу UDP по SOCKS5? Есть ли какие-нибудь простые тулзы для этого? netcat не хочет гнать UDP по SOCKS5, а socat вообще не понимает его

@Zert:
Zert

Есть ли способ поднять VPN-сервер без создания tun-девайсов? Чисто userspace приложение/библиотека, которое по tcp принимает трафик от пользователя VPN.

@L29Ah:
L29Ah

garron.me
Пакетик проёбывается на routing decision, судя по расставленным -j LOG. В ответ присылают ECONNREFUSED для tcp и нихуя для udp. Как отдебажить?

@Dant:
Dant

Затарился отакой антеннкой для удаленных от цывилизаций мест, где не ступала нога интернетов. Будем посмотреть, насколько оно лучше свистка с комнатными усилителями типа коннектов ; )

@dr-Chaos:
dr-Chaos

Залёз тут опять в дебри UDP и ICMP. Походу таки буду делать разбирание/собирание байтстроки на UDP пакеты с исследованием MTU. Тока я смотрю этого на цацкеле никто не пейсал. " Я сильная, я смелая и на голову ебанутая."

@Sc0rp1us:
Sc0rp1us

недавно встретился с проблемой.
время от времени, при tcp запросов с linux на linux не происхадил хэндшэйк
как оказалось, с определённой версии ядра tcp_timestamps включен
и сесли пакет прилетал из будующего, то хэндшэйк не происходил
проблема излечилась просто
sysctl net.ipv4.tcp_timestamps=0

@Lis:
Lis

биткоин в китае всё... bitnovosti.com

@datacompboy:
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

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

@vbooh:
vbooh

Необычное для меня поведение относительно 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 .
Другие сочетения ОС, сетевой и драйвера не пробовал.

@mahury:
mahury

перезагрузил роутер и получил прирост скорости интернета в два раза.

@datacompboy:
datacompboy

А только от меня проблема со скоростью доступа в сторону softlayer ?
speedtest.sng01.softlayer.com — гляньте от себя.

@datacompboy:
datacompboy

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

@Dant:
Dant

Последний GTK-шный теплый ламповый Wireshark 1.12.0. В комплекте страшненький QTShark 2.0 Preview: wireshark.org

@ridouchire:
ridouchire

Злой у меня оператор. Удалённо только на тариф повыше забраться можно, а ниже — лично при поездке в офис. Эх-эх, с утричка и поеду.

@DespicableMe:
DespicableMe

Я просто поражаюсь этим мелкомягким. Серьёзно. Казалось бы: .net существует весьма давно и как бы по идее должен нормально работать даже в Windows XP. Но, нет! И это несмотря на то, что версия 3 существует уже давно и должна работать нормально и под ней.
Короче говоря, судя по всему, меня ждут ад и муки отладки, дабы заставить свой код нормально работать под XP.
И не надо мне говорить, что оно устарело. У меня лицензия и старый комп. Я не могу туда водрузить ничего новее. Так что буду пилить и пытаться.

@4DA:
4DA

Уже несколько раз натыкаюсь на дискуссии, что нынче проблема с 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, есть еще чо?

@ishe:
ishe

Через Керченский пролив прокладывают интернет-кабеля:
economics.lb.ua

Ну да, электричество и все остальное — то подождет. первым делом надо навести шмон с цензурой, чтобы не читали и не смотрели ua-сайты и телек. все правильно, кгб рулит )

@ishe:
ishe

Редакция lenta.ru заявляет про тыск и цензуру:
pravda.com.ua

lenta.ru — не сдавайтесь, я Вас читаю много лет!!

@ishe:
ishe

Ну что, в lenta.ru сменился главный редактор (после публикации
интервью с одним из лидеров "Правого сектора"). Жаль, неплохое было
издание, много лет читал его постоянно. Фамилия нового — Гоеславский,
логично и новости такие же ожидать (.

@green:
green

[05/03/14 22:25:16] Kirill Sotnikov: А вот интересно, есть ли такая софтина, которая стримит звук с одного устройства на другое?
[05/03/14 22:25:39] Kirill Sotnikov: чтобы колонки подключить только в одно место и именно весь звук, про мпд я в курсе

@datacompboy:
datacompboy

оставил только 20 ширину канала, ибо extension каналы и 2 и 10 перегружены до той матери.
вроде пЫнг нормалезовалсэ.

@datacompboy:
datacompboy

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

@datacompboy:
datacompboy

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

@datacompboy:
datacompboy

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

@AChernakov:
AChernakov

Угадайте, что находится по адресу procrastination.ru?

@datacompboy:
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:
datacompboy

Запилил тестовый клиент, пойду теперь мучать китаёсов.
github.com

@datacompboy:
datacompboy

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

@datacompboy:
datacompboy

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

@datacompboy:
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:
datacompboy

Что-то не понимаю. При UDP всё ясно — client И server порты передаются.
А в случае TCP — серверный порт 554? А клиентский любой?

@datacompboy:
datacompboy

Йесс, йа его подебил — digest сожрало, теперь можно писать мимимитатор проблем приемника.

@datacompboy:
datacompboy

Ну зашибись, все либы на питоне/руби для rtsp не умеют digest авторизацию.
Да вы что все, сговорились, что-ли...

@datacompboy:
datacompboy

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

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

@datacompboy:
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:
datacompboy

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

@datacompboy:
datacompboy

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

@datacompboy:
datacompboy

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

@datacompboy:
datacompboy

Всё, теперь по квартире честный гигабит растянут. Осталось протянуть один проводок.

@datacompboy:
datacompboy

iperf3 всем красив, там наконец-то появилась очень важная фича "reports the number of TCP packets that were retransmitted"... но сервер у меня на винде, а он "Windows is not currently supported".
ну чтёёёё ты бууишь делать :/
чем можно протестировать сеть, так чтоб сервер на винде а клиент на линухе? Интересует макс пропускная способность и количество tcp retransmittion.