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

Most2 06.<trusishka> пинг

onon Напомните мне пути получения новых RI.

onon 1. Зондирование.

onon 2. Запросы к фф, если через нас строится транзитный туннель.

onon 3. Если мы - фф, то прямая публикация от роутера, либо републикация от соседнего фф.

onon Ничего не забыл?

orignal забыл подключение к нам

onon В каких случаях мы не можем проверить валидность RI?

onon Во всех, кроме прямого коннекта или прямой публикации от роутера?

onon Я пытаюсь собрать в кучу случаи, когда нам могут налить фейковых RI

onon И кто это может делать.

onon Очевидно флудфил.

orignal если кратко то только на флудфил

onon Он может через зондирование наливать и на другие флудфилы.

orignal он на другие и наливает

orignal и отвечает ими на запросы других узлов

onon Их у нас не так много, есть ли вероятность его вычислить

orignal кого?

onon Источник

onon "заражения"

orignal ну будет какой то U узел из Тора

onon fU?

orignal ты не понял

orignal он сам не флудфил

orignal он только срет на флудфилы

orignal однако ты подал идею

onon А как он так много умудряется насрать

orignal поключается к флудфилу и кидает на него

orignal списки

onon Типа как себя публикует?

orignal а идея вот в чем

onon Или републикация

onon Так он же не фф

orignal нет он публикет нагенеренные RU

orignal RI

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

onon Это зачем

orignal потому что ты можешь быть концов тонеля

orignal вот в этом идея

orignal от U роутеров принимать только себя

orignal счас с дедом поделюсь мыслью

onon Не совсем понял логику про конец туннеля, вроде чтобы публиковаться не напрямую, а через туннель?

onon Зачем так сделано

orignal ну помнишь твою же проблему

orignal ты не всегда можешь поключиться в флудфилу напрямую

onon Да, есть такое.

onon Тогда вопрос, а зачем вообще в моём случае публиковаться?

onon Мой доверенный пир получит мой RI при подключении, а кому я ещё нужен?

orignal в твоем действительно не нужно

orignal публиковаться нужно для транзита

onon Ну так а если для транзита, то прямой коннект быть должен, пусть сам публикуется

orignal еще один вариант упустили

orignal флуд

orignal когда флудфил пересылает другим

onon Ну так атакующий в таком случае сам должен быть фф

orignal естественно

orignal и тогда ему придется публиковать свой IP который будет легко забанить

orignal onon ты понял мой замысел?

onon Да

orignal тогда атакубщему придется строить все тоннели с концами на флудфилах

orignal при этом посылая их как флуд

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

onon Т.е. при флуде мы не можем определить, это сам фф прислали или транзитом?

onon Только косвенными методами

orignal флудфил если ему прислали он пересылает ближазим соседям

onon Я имею ввиду формат I2NP сообщений

orignal но если атакующий сделает концом тоннеля флудфил то роутеры которые через него пойдут будут сильно далеко по рассятонию

orignal в I2NP флаг есть но атакующий тоже может его поставить и прикинуться транзитом

onon Ну да, я сразу не сообразил.

onon По расстоянию тут тоже не всё так однозначно

onon Может он был валидный, просто в базе не было более близкого

onon А этот был самым близким

orignal так если валидный флудфил

orignal он сам наберет список флудфилов быстро

onon Логично, проблемы возможны только при старте.

orignal именно

orignal на а кого ебет флудфил который только стартует

onon Он тогда сам себя нормально опубликует, а ему соседи уже нальют.

orignal емтественно

Vort у меня опять узел крешнуло в том же самом месте - github.com/PurpleI2P/i2pd/blob/02895d4cf5d0d5e047713a3af7d72f8a9b796e68/libi2pd/I2NPProtocol.cpp#L178

orignal то же само в каком смысле?

Vort на той же строчке кода

Vort точнее, на той же инструкции процессора

orignal а когда уже падаело?

orignal откуда вызывается ты знаешь?

Vort вчера утром

Vort [11:52:02] <Vort> разобрался я, как всё же вытащить названия функций из бинарника. стек креша вот такой: NetDb::HandleDatabaseSearchReplyMsg -> NetDbRequests::SendNextRequest -> RequestedDestination::CreateRequestMessage -> CreateRouterInfoDatabaseLookupMsg

orignal мне интересно откуда excludedPeers прилетают

orignal видимо я отваливался

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

Vort и адрес там не нулевой, а 0x00000000662A43D2

orignal а если он ссылается на то чего уже нет?

orignal то есть передали указатель на стуркутуру

orignal а она удалилась из другого треда

Vort в прошлый раз был адрес 0x0000000066288bb5

Vort ну вообще ничего по этому адресу нету, вот в чём загадка

Vort с кучей такое бывает редко

Vort обычно какое-то старьё болтается

orignal вот надо смотреть откуда вызов

Vort мне вот это не нравится: &m_ExcludedPeers

Vort и дальше потом никаких блокировок

Vort удалиться m_ExcludedPeers, думаю, не мог

Vort а вот поменяться в процессе его итерирования - вероятно

orignal надо посмотреть

orignal откуда вызывается и все станет ясно

Vort ну я же скинул цепочку вызовов. что ты имеешь в виду под " откуда вызывается "? названия потоков что ли?

Vort HandleDatabaseSearchReplyMsg, вроде, только из NetDB потока может вызваться

orignal а все вижу

orignal RequestedDestination скорее всего сдохла в процессе

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

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

Vort у меня подозрение, что это может быть гонка между SendNextRequest из дропа и из ManageRequests

Vort доказательств пока что нету

orignal часа через 4 займусь

Vort решил я половить проблему с выжиранием памяти при закрытии i2pd и довольно быстро попал на очень подозрительное место

Vort с участием - опять же - m_Peers из Transports.cpp

Vort github.com/PurpleI2P/i2pd/blob/d3b699d7cdec72e6513d7a55c711e6e21902dba4/libi2pd/Transports.cpp#L474

orignal это страннл

Vort вот на этой строчке сейчас m_Peers { size=0xfffffffffffffff7 }

Vort и контейнер там какие-то миллионы элементов перебирает

Vort сейчас стек покажу

Vort paste.i2pd.xyz/?bbdda9f6f5b48ffa#Ewg4Hab4QFU6J9u5jiNdx99G5uqFYZp1QMnwQAdkAWMy

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

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

Vort хрен из него выйдешь. полгига сожрал за 3 секунды

Vort пришлось опять на паузу ставить

Vort ещё одна попытка - уже 3 гига отожрано. не выйдет он из этой функции по-хорошему

tetrimer_ Под фрей такая фигня уже давно: при каждом корректном выключении корку оставляет.

Vort tetrimer_: креши - постоянно. а это другое - тут не просто креш, тут выжирается вся RAM

Vort при чём так быстро, что не успеваешь среагировать

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

tetrimer_ геометрическая прогрессия в определении размера выделяемой памяти?

Vort вот сейчас malloc с 2 гигами!! вызвался

Vort я не пойму, что конкретно контейнер делает. но он поломан, поэтому может делать что угодно

Vort в общем, останавливаю процесс, всё понятно. надо накрывать все доступы к m_Peers мьютексами

tetrimer_ Нда. А на флудфилах - все так же TCSR = 1-2%. :(

orignal похоже там просто котейнер побился

Vort откомментил на гитхабе

Vort ну да, m_Peers хочет больше мьютексов

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

orignal а не храниени самих данных в структуре

onon педелеки это 5

Vort это поможет расставить мьютексы корректно?

orignal да

orignal смотри

orignal мы блокируем мьютекс только чтобы достать указатель на пир

orignal на короткое время

Vort вижу, что struct Peer довольно жирный. он постоянно по контейнеру сейчас копируется что ли?

orignal да

orignal это дурацкий код там

Vort понятно

orignal просто раньше он не был таким и задач таких не было

Vort попробовал я понять, как работают запросы (lookup) дестинейшенов в i2pd. честно говоря, это какой-то пиздец

Vort вот пример: 1. ищется флудфил

Vort 2. флудфил нашёлся, пошли уже через него запросы поиска

Vort 3. флудфил вылетел почему-то, опять ищется

Vort 4. почему-то прекратились поиски (плохо понял, почему)

Vort 5. вызывается обработчик дропа от сообщений ещё первого!! (1) поиска

Vort 6. вызывается обработчик дропа от сообщений второго (3) поиска

Vort 7. вызывается обработчик дропа от поиска от первого дропа (5)

Vort 8. вызывается обработчик дропа от поиска от второго дропа (6)

Vort то есть, флудфил уже несколько раз успел поискаться, уже поиски несколько раз прекращались, а затем без регистрации в m_RequestedDestinations ещё дропы друг другу перекидывали запрос

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

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

Vort насколько такие решения в i2pd обоснованы - отдельный вопрос. я вообще логику в HandleDatabaseSearchReplyMsg не понял

orignal Vort

orignal это очевидная лажа в коде

senki hi. I have a question about the name resolution of tunnels.

senki I run i2pd in a container, and have a http tunnel with the destination httpd

senki when I start the container httpd points to some arbitrary address, but is then updated when the http container starts (by updating /etc/hosts in the i2pd container)

senki this seems however not to work

senki does i2pd not resolve the name on access but only on setup perhaps?

orignal http resolve address in "host" param

orignal e.g. you can write host=google.com and it will work

senki but, I have like 'host = httpd'

senki but when i try to connect the i2pd logs for the container says that the net is not reachable

orignal what does it resolve to?

senki even if I at the time of the attempt have like "10.88.0.3 httpd" in /etc/hosts

orignal I didn't try it, maybe the resolver doesn't look into /etc/hosts

senki so, it resolves to that, bt when i2pd started it did point to nonsense as the ip of the http container isn't known at that time

senki I'll try to start the httpd container first and see if that wors then...

senki works*

senki it'

orignal auto resolver = std::make_shared<boost::asio::ip::tcp::resolver>(GetService ());

orignal resolver->async_resolve (boost::asio::ip::tcp::resolver::query (m_Address, ""),

orignal std::bind (&I2PServerTunnel::HandleResolve, this,

orignal std::placeholders::_1, std::placeholders::_2, resolver));

orignal in I2PTunnel.cpp

senki 's interesting to type with a 5 sec lag! connected to a terminal via i2p that runs weechat... :D

orignal and it resolves at start

senki aaha, so, only at start - that kind of explains it

senki thanks

orignal I was going to redo it but didn't do it

senki aight. =) I'll work around it.

orignal думаю что там с логикой дропов проблема что они не зануляются

Vort orignal: так а как их занулишь? это скорее dest надо как-то отключать перед m_RequestedDestinations.erase

orignal пришел ответ на запрос фудфила почему тот дроп запроса не занулился?

Vort чтобы SendNextRequest сразу выходил

orignal он должен исчезнуть

orignal <Vort> 2. флудфил нашёлся, пошли уже через него запросы поиска

Vort так запросов то дофига, как я понял

orignal <Vort> 5. вызывается обработчик дропа от сообщений ещё первого!! (1) поиска

orignal это дроп от поиска флудфила который уже нашелся?

orignal или что?

Vort не

Vort ща

orignal давай по порядку что мы ищем?

Vort дроп от Peer::Done

orignal мы ищем некий адрес

orignal так?

orignal и его хотят несколько рыл потому каждлый добавляет свой дроп

Vort в delayedMessages сообщение может пролежать долго. и никто у него дропы не чистит

orignal почему не чистит?

orignal / drop not sent delayed messages

orignal for (auto& it: delayedMessages)

orignal it->Drop ();

orignal в дестуркторе

orignal точнее даже в методе Done

Vort ну вызываются, да. а нафига они нужны когда уже поиск отменён давно?

Vort надо их как-то деактивировать

Vort дропы вот этого: auto msg = dest->CreateRequestMessage(

Vort msg->onDrop = [this, dest]() { this->SendNextRequest (dest);

orignal так в почему поиск отменен?

Vort вот эта штука вызывается через фиг знает сколько времени когда она уже не актуальна

orignal так погоди это в какой строке?

Vort допустим, по m_Requests.RequestComplete из NetDb::HandleDatabaseSearchReplyMsg

orignal this же вообще уже может не быть

orignal покажи строку

orignal я че опять что ли бухой был когда это писал?)))

Vort github.com/PurpleI2P/i2pd/blob/d3b699d7cdec72e6513d7a55c711e6e21902dba4/libi2pd/NetDbRequests.cpp#L194

orignal а ну это не так плохо

orignal надо лишь проврять статус dest и все дела

Vort а отмена вот отсюда (наверно): github.com/PurpleI2P/i2pd/blob/d3b699d7cdec72e6513d7a55c711e6e21902dba4/libi2pd/NetDb.cpp#L953

orignal да это все понятно что случилось

orignal починю где то через час

Vort окей

orignal просто не подумал о таком варианте на бухой был ))

orignal а вот за моими коммитами в выходные надо смотреть внимательно ))

orignal onon заценил мою новую идею?

onon С подписью?

orignal да

onon А как же обратная совместимость

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

orignal а обратная совместимость ничего не знает о подписи и проверять ее не будет

onon Ну тогда, выглядит интересно

orignal а если получаем RI с новой версией и без подписи то выкидываем

orignal точнее ОТ RI

orignal у котрого новая версия но он не подписывает

orignal значит жулик

onon Я пока обдумываю варианты, где могут возникнуть проблемы

onon Пока не придумал

onon У нас же только один раунд флуда?

onon На мне опубликовались, я только нескольком роутерам перепосылаю

onon Они двльше не флудят

orignal проверку я счас сделаю чтобы незапрошенные флудфилы приходили только от флудфилов

orignal один раунд на 3 соседа

orignal просто когда я так сделаю атакущий быстро допрет и станет выдавать себя за флуд

orignal нет дальше не флудят

orignal там где то есть флаг что это флуд

orignal уже не помню где точно