#dev (ilita) | Обсуждение разработки I2Pd | i2pd development discussion | http://i2pd.website/

Vort "<weko> но тут вроде первоисточник - TBM" - не уверен, но, по-моему, в таком случае запрос с хешем логируется. тут же первое упоминание хеша в логе касается уже ответа

Vort может это в RI интродьюсером такая фигня приходит?

Vort что-то ещё вспоминается похожее с лизсетами

Vort где-то я раньше это AAAAAA видел уже. или кажется, не знаю

weko Vort: ну а по какой ещё причине твой узел станет запрашивать такой RI?

Vort проще посмотреть. жаль, что атака нерегулярна

Vort короч я добавил вывод стека в NetDb::RequestDestination если там находится AAAAAA

Vort и запустил на U узле

Vort даже если я со стеком накосячил (вполне вероятно), то хотя бы будет подтверждение, что запрос приходит в эту функцию

Vort точнее, проходит через неё

Vort две новости:

Vort во-первых, я опять словил сброс интродьюсеров пир тестом

Vort на сей раз из-за переключения в Unknown статус. а зачем было так делать - загадка. наверно опять баг

Vort мне пришло вот такое: SSU2: Peer test 4 error code 68 from lzkm

Vort 68: rejected by Charlie, Alice is already connected

Vort сомневаюсь, что это хороший повод для установки Unknown статуса

Vort вторая новость - я словил запросы с атакой

Vort стек я вывел криво, но, похоже, понял источник атаки

Vort и это скорее всего таки атака на чтение за пределами массива в i2pd

Vort хотя... уже не уверен. сейчас попробую стек разобрать

Vort я его таки криво вывел :)

Vort про чтение за пределами мне показалось. по крайней мере, в этом месте нету

Vort пока что могу сказать, что было три RequestDestination подряд: один глюченый с AAA и два нормальных

Vort это я конечно конкретно тупанул - собрал релиз и теперь пришлось копаться в бинарнике без отладочной информации и гадать чему стек соответствует :)

Vort но вроде догадался - скорее всего, запрос идёт из SSU2Server::ConnectThroughIntroducer

Vort там внизу запрос интродьюсеров

Vort то есть, я подозреваю вот это место: github.com/PurpleI2P/i2pd/blob/8447822c3596cadadfa6c7bd7ab0643ddd814b34/libi2pd/SSU2.cpp#L763

Vort опять в логах нету нужных данных. не понятно, к какому узлу была попытка коннекта :(

Vort исходящие запросы тоже логировать надо, а в i2pd почему-то с этим проблемы

Vort собираю новый бинарник с отладкой и понимаю, что есть шанс и без бинарника понять, в чём дело

Vort есть кое какая идея

Vort это вообще может быть не атака, а баг в i2pd :)

Vort пиздец. похоже, джава обновилась и стала делать такие RI, которые i2pd не ожидал

Vort а должен был ожидать...

Vort короч всё понятно. ну не со 100% шансом, а примерно с 99%

Vort хотя наверно даже не обновилась, а так всегда было. но никто не заметил :((

Vort и таки да, похоже, мы всё же имеем проблемы с памятью в i2pd - в сеть рассылаются данные из неинициализированных переменных

Vort orignal: похоже, я нашёл источник AAAAAA. глянь на вот эти RI: paste.i2pd.xyz/?d51dcad50d3bb47c#EcFUeRSEarPc3umise6Mxm9x9k3mH6T2n4o8bYtXQkKd

Vort iexp0 там есть, ih0 - нету

Vort и скорее всего это не атакующий делает, а обычные джава узлы

orignal так когда ih нету это нормально

orignal это просто SSU1

orignal и мы такие интродьюсеры просто выкидываем у себя

Vort orignal: у SSU v2 тоже такое бывает

Vort там вместо ih0 прописаны ihost0 и ikey0

orignal все правильно

orignal у них SSU обшщий для SSU1 и SSU2

Vort то есть, если нету ihN, то i2pd должен такое выкинуть?

orignal и вот то что видишь это просто SSU1 интродьюсер

orignal i2pd должен такие выкидыватьу себя

Vort тогда может быть не баг, а атака

Vort надо бы сохранить проблемный RI

Vort понятно, что проблема где-то там, но надо её чётко выловить

orignal а в чем атака?

orignal что джава публикует SSU1 интродьюсер?

Vort в том, что i2pd создаёт ih0 из мусора

Vort а почему - будем разбираться

Vort ошибся с функцией записи RI в файл, но успел его спасти из netdb. сейчас буду разбираться, что с ним не так

Vort ну да, ровно то, о чём я говорил

Vort нет ih0, зато есть ihost0, ikey0 и iport0

Vort хаха. кажется, понял

Vort github.com/PurpleI2P/i2pd/blob/8447822c3596cadadfa6c7bd7ab0643ddd814b34/libi2pd/RouterInfo.cpp#L350

Vort else if (!strcmp (key, "ih"))

Vort [ih2] = [hnGO~d~l8PakvaAiN91NpTskZ0OhbI0keiAMRvaamA8=]

Vort [ihost0] = [46.72.4.45]

Vort orignal: похоже, "ihost0" тоже за "ih" принимается

Vort таки баг, а не атака

tetrimer Vort: А почему в сравнении нельзя указать "ih0"?

Vort tetrimer: потому что там не только ноль, но и 1, 2,... бывают

Vort кстати, спасибо за наводку по поводу всплесков активности )

orignal ой бля

Vort без неё я бы не скоро решился свой U узел запускать

orignal надо чинить если так

tetrimer Блин, без рег

tetrimer без регэкспов - как без рук...

Vort а я другую фразу про регекспы помню - jeffgeerling.com/sites/default/files/images/regex-now-i-have-two-problems-regular-expressions-picard-facepalm.jpg

orignal if (!strcmp (key, "ih"))

orignal точное сравнение в коде

Vort да что ж за проблема упёртая. никак не сдаётся

tetrimer strncmp(key,"in",2) - не лучше будет?

Vort paste.i2pd.xyz/?694bcc4e65f05c69#6HyZzzrmGRX4nRfDd9iR32MC2pA4RBe3grQNhqPrZQz8

Vort ^^ вот RI, сейчас буду насильно пихать в i2pd и смотреть, как распарсится

orignal нет не лучше

Vort насчёт strcmp я был не прав. но всё равно проблема остаётся - вместо ih0 - мусор

Vort "<~orignal> i2pd должен такие выкидыватьу себя" - где хотя бы примерно он должен это делать?

orignal строка 406 RouterInfo.cpp

Vort UpdateIntroducers (address, ts); ?

Vort не вижу там ничего такого. да и как можно узнать, что в ih - мусор?

Vort после того, как парсинг завершён, эта информация утеряна

Vort тег есть, срок годности в порядке. а то что .iH не инициализирован - так это не узнаешь уже

Vort баг загнан в угол ) я сожалею, что много ошибался, но главное, что причина (почти) найдена

Vort уже не в тему бага с iH: опять мой U узел получил статус "OK". похоже, что это проблема нередкая

Vort и гадит эта проблема всем - и узлу, через который не идёт транзит, и всем тем, кто к нему пытается подключиться

orignal так в почему он получает? PeerTest 5 прилетает?

Vort да, от узла с которым недавно была сессия

orignal мы с дедом обсуждали давно это

orignal как решать непонятно

orignal видимо надо хранить списик недавних

Vort ну да

orignal надо бы заняться конечно

Vort и пускать пиртесты пока не полуим годный ответ

Vort error code 68 мне тоже совсем не понравился

Vort точнее, то, как он обрабатывается

Vort хотя важнее, думаю, баги 1. с мусором в iH и 2. его (мусора) ловлей на транзитных узлах

Vort у меня уже сомнения, что мусор в iH - это основная проблема низкого рейта, но мусор - это мусор - его надо убирать в любом случае

orignal с 68 у меня просто не доделано

user Объясните мне кто-нибудь чяднт. Запускаю U роутер, проверяю, все работает. Включаю в конфиге список доверенных роутеров, перезапускаю роутер - и нихера. Никуда не коннектится, в туннелях два нуль-хоповых висят и всё.

user Хотя доверенные роутеры в БД есть, он только что через них туннели строил, и в транспортах они были.

user А самое интересное, что пару недель назад это работало...

Vort речь про секцию [trust] и опцию routers = ?

user да

user В логе вижу попытки подключиться к доверенному роутеру, потом пишет AEAD verification failed

Vort сейчас потестирую. никогда ещё не пробовал эту опцию

orignal не стоит

orignal она нихуя не работает

orignal ему много раз это говорили

orignal но он все равно продолжает мучать жопу

Vort а, ну тогда ладно. значит надо чинить. когда-нибудь

user Она охуенно две недели отработала

user А потом хз чего перестала

Vort хотя всё же попробую )) мало ли, вдруг что интересное найду

orignal значит не судьба ей работать

Vort у меня вроде заработало

weko [14:19:29] <~orignal> видимо надо хранить списик недавних

weko ещё можно лечить симптом - например, ждать нескольких удачных тестов, прежде чем ставить ОК

Vort лучше не надо

orignal тут можно застрять навсегда

orignal если у тебя тысчи линков

Vort этот ОК вообще сам по себе подозрительный

orignal так это чинить надо

weko в данном случае мы исправим все случайные причины, почему мог оказаться ОК

Vort да просто у меня это вылазит когда линков штук 20-50. подозрительное невезение при том, что в сети тысячи узлов

orignal если чарли видит тебя в списке то должен отвечать 68-ым кодом

orignal будет прилетать 68-ой будет Unknown и все

orignal у меня такого не случается однако

Vort weko: у меня подозрение, что этот ОК не случаен. лучше починить нормально на случай, если это всё-таки какая-то атака

weko а что от этого 68? узлы не могут знать точные параметры NAT

weko а то, что сессии нет, самим можно проверить

weko Vort: надо починить, да

weko но и моё предложение смысл имеет

Vort user: вот поставил ограничение на флудфилов, начинающихся с шестёрки: paste.i2pd.xyz/?136901b95f50a94e#BZKMteUFZqgGEWw1AYy6gsmyQjbhaurySfjv2CK1xshS

orignal 68 занчит реальный статус x3

Vort 68 значит "не повезло, надо пробовать дальше"

user Да, у меня завелся роутер, но только через один из роутеров пока работает.

user Буду продолжать наблюдение

user И, да, меня продолжает бомбить, что privatebin требует яваскрипт.

Vort "<~orignal> тут можно застрять навсегда" можно на всякий случай сделать ограничение по количеству попыток. допустим, не больше 20 штук.

Vort хотя если все 20 попыток израсходуются, то это уже будет явно атака

Vort у невезучести есть свои пределы :)

Vort так читеров в спидранах ловили

Vort шансы некоторых событий таковы, что за всю историю человечества такое происходило всего несколько раз

weko [16:03:13] <Vort> 68 значит "не повезло, надо пробовать дальше"

weko вот значит нужно пробовать дальше, а не ставить Unknown

Vort даже если шанс неудачи 80%, то за 20 попыток этот шанс превращается в 1%

Vort "<weko> вот значит нужно пробовать дальше, а не ставить Unknown" ага. только это надо код переделывать, чтобы количество попыток было динамическим. вроде, сейчас этого нету

Vort если не везёт, то надо пробовать дальше. если же везёт, то и 5 попыток хватит (или сколько там сейчас стоит)

weko тяп-ляп и в продакшн

Vort всё же чинить проще, чем с нуля делать, так что ладно

weko иногда проше с нуля

weko проще*

Vort у меня есть слабообоснованное подозрение, что такие случаи ошибочной установки OK могут свидетельствовать о разделении сети на мелкие островки

Vort или из-за багов/особенностей или из-за атаки

Vort но чтобы сказать с уверенностью, это надо проводить масштабное исследование. не до этого сейчас

user Кстати, в этом самом режиме trust, у меня всегда роутер OK показывает

user Хотя он за файрволос

user м

Vort user: транзит ему хоть вырубил?

user Да

Vort подозреваю, что для нормальной работы пиртеста в списке должно быть под тыщу узлов

Vort хотя... он наверно всё равно не заработает

Vort откуда Бобу знать, что у Алисы trust режим?

Vort trust режим - он же и на входящие и на исходящие распространяется?

user Да

Vort это режим, кстати, может быть полезен для исследований TCSR

Vort можно делать разные "срезы" по netdb и смотреть, какой будет рейт

Vort так можно вычислить кластеры узлов, которые гадят (если таковые есть, конечно)

orignal Vort ты прав похоже проверки на хуевый ih нет

orignal отсюда и проблемы

Vort ну точнее на его отсутствие

orignal счас починим

orignal точнее не счас там подумать надо

Vort может, занулить iH, а затем проверить - остался нулём или заполнился? хотя может есть и более умные методы

orignal я подумаю

Vort ок

orignal короче ты правильно нашел проблему

orignal как всегда собирался сделать и не сделал

R4SAS user: используй консольный клиент тогда

user Для чего?

R4SAS < user> И, да, меня продолжает бомбить, что privatebin требует яваскрипт

user Это где скачать/посмотреть

R4SAS идея privatebin в том, что сервер не должен знать чего лежит в записи

R4SAS а этого добиться можно только если запись шифруется на стороне клиента

R4SAS user: github.com/PrivateBin/PrivateBin/wiki/Third-party-clients

user Да, это интересно, не знал как это устроено. Спасибо, буду разбираться.