~AreEnn
~R4SAS
~acetone
~orignal
~villain
&N00B
+Xeha
+relaybot
DUHOVKIN
Guest7184
Leopold
Most2
Nausicaa
Ruskoye_911
Vort
`
anon2
b3t4f4c3
nemiga
not_bob_afk
plap
poriori
profetikla
soos
teeth
un
weko_
whothefuckami
orignal
if (!ec && moreBytes >= m_NextReceivedLen)
orignal
else
orignal
Receive ();
orignal
вот она бага
orignal
мы вызываем Receive даже если до этого была ошибка
orignal
ну и не проверяем длину
weko
исправь, проверб
weko
проверю
orignal
завтра уже
orignal
и кстати AEAD откуда поятно
weko
кстати я тут 3+3 проверял и скорость хорошая
weko
просто я вот что думаю
weko
я поставил буфера 50000
weko
проверю ещё конечно но думаю это как повлияло
weko
как то
orignal
где буфера я не понял
weko
буферы которые транспортов
weko
уж не знаю
orignal
так у NTCP2 же они динамические
weko
ну именно максимум
orignal
там максимум 64K
weko
который сейчас 500
orignal
ты про число пакетов что ли?
weko
const int NTCP2_MAX_OUTGOING_QUEUE_SIZE = 50000;
weko
else if (m_SendQueue.size () > NTCP2_MAX_OUTGOING_QUEUE_SIZE)
weko
{
weko
LogPrint (eLogWarning, "NTCP2: Outgoing messages queue size to ",
weko
GetIdentHashBase64(), " exceeds ", NTCP2_MAX_OUTGOING_QUEUE_SIZE);
weko
Terminate ();
weko
}
weko
а
weko
это единственное место что-ли?
weko
теперь по крайней мере выжимает максимум на тред дистнейшна. так то в теории оно и 200MB/s может, если процессор получше был бы
orignal
это в пакетах
weko
я понимаю
orignal
50 мегов на сессию многовато
weko
да
weko
я тестирую ж
weko
просто тут Terminate если превышает
weko
сессию просто грохает
weko
почему?
orignal
а что он должен делать?
weko
ну дропать те что превышают
orignal
если превышает то получается затык всей сессии
weko
ntcp2 сессия то тут при чём, когда на уровне выше шлют больше чем вывозим
orignal
возможно
weko
зачем закрывать её?
orignal
ну я считал что раз она не справляется значит с проблема с ней
weko
вероятно оттуда и затыки
weko
так может в туннеле перед ней быстрее коннект
weko
сессия может и умеет 5 MB/s а мы может шлём на неё 6
weko
и вот она несправляется
weko
хотя с ней всё ок
weko
orignal: ещё может быть несколько туннелей через эту сессию
weko
просто теперь понятно почему пакеты прямо пачками пропадают
weko
просто сессия вот так сгорает и пакеты из очереди идут в жопу
weko
понятно теперь почему когда я ставил 5, всё лагало...
weko
потому что сессии пересоздавались
weko
могу завтра попробовать тулзу написать чтобы тестировать пинги, смотреть какие пики выходят
weko
типо графика сделать
weko
orignal: мне кажется тут должен был быть код, который дропает сообщения, но в итоге его тут нет
weko
хотя очень просто
weko
сделать
weko
for (auto it: msgs) {
weko
m_SendQueue.push_back (std::move (it));
weko
if (m_SendQueue.size() == NTCP2_MAX_OUTGOING_QUEUE_SIZE) break;
weko
}
weko
в SSU2 также нету
orignal
ну да нету
orignal
потому что я считал по другому
weko
ну в любом случае дучше дропнуть сообщение, чем рвать сессию
orignal
а если сессия хуевая как определять?
weko
ну просто дропаться будет постоянно
weko
как в общем то и должно судя по стримингу
orignal
по какой причине?
weko
потому что не вывозит сессия
weko
orignal: прикол в том что вот мы рвём сессию, владелец туннеля нихуя об этом не знает
weko
и дальше шлёт
weko
и мы снова созздаём
weko
так что толку от этого полный 0
weko
ничего лучше кроме как дропать я не вижу
orignal
ну x3
orignal
возможно да надо дропать новые
weko
и даже в идеальном случае, когда реализовано сообщение взад о том что буфер наполнился слишком сильно, то всё равно нужно оставить что при привышении дропать
weko
orignal: ты сам сказал мне изначально что дропаются. а по факту не так
orignal
ну дпропается все что не отослано
orignal
надл не так
weko
ну да, надо дропать что не влезает в буфер
orignal
надо с какого то момента начинать дропать
orignal
а когда переполняется то закрывать сессию
orignal
ха
orignal
у меня есть идея получше
weko
так дело в том что закрывать не придётся
orignal
не отосланные не выкидывать а возврашать в очередь транспорта
orignal
закрывать сессию и пробовать друго
orignal
й
weko
так от того что мы сессию пересоздадим канал связи не станет быстрее
orignal
если ты поменял NTCP2 на SSU2 вполне может стать быстрее
weko
максимум если только в коде тупняк который фиксится пересозданием. так в таком случае нужно исправить тупняк
weko
orignal: так тогда нужно плавно менять
weko
и в общем всегда предопочитать ssu2 когда возможно
weko
если сразу создать ssu2 то менять не придётся
orignal
есть причина предпочитать NTCP2
weko
какая?
orignal
если неизветный роутер то следует снчала соединиться по NTCP2
orignal
чтобы не попасть на фейк
weko
а ну та бага
weko
с ssu2
orignal
ну да
weko
так и не исправили?
weko
ну пиздец
weko
ну значит костыль писать надо ещё))
orignal
дед ее так и не понял даже
weko
orignal: я уже не помню что там
weko
но помню что была
weko
скоро будет уже год
orignal
ну ты соединяешься с адресом
orignal
он тебе отвечает сообщениями
orignal
но этот не тот роутер к которому ты поключаешься
weko
да вроде роутер совю подпись не присылает
weko
в отличии от ntcp2
orignal
злоумешленник может сделать фейковый роутер с IP адресом реального роутера
orignal
нет в ntcp2 там первое сообщение шифруется хэшем того роутера
weko
да суть атаки понятно
orignal
а в SSU2 ключом i
orignal
суть атаки в том что злоумеленник может наплодить несушествующих роутеров которые будут считать успешно работающими
weko
orignal: а в ntcp2 не проблема что оно так? просто в ntcp2 тоже можно сделать i, но чтобы уже внутри приходила подпись роутера
weko
orignal: да я понимаю
orignal
говорю же первое сообщение шифруется хэшем роутера
weko
мы никак не проверяем что тот кто нам отвечает реально владеет приватным ключом RI
orignal
потому та сторона просто его не расшифрует
orignal
вот нету проверки
orignal
в эту сторону
orignal
в другую есть
orignal
считалось что мы проверим подпись когда получим его RI
weko
orignal: во первых не понимаю как шифровать хэшем, во вторых я понял про что ты, вопрос в другом - является ли это проблемой?
orignal
я предлагал ввести отдельный блок
weko
потому что звучит так будто DPI так работать проще
orignal
там шифруется AES
orignal
в качестве ключа используется i а в качестве IV хэш
weko
аа..
weko
тогда да
weko
понял
orignal
в вот в SSU2 только i
weko
там нету IV?
weko
там вроде другая криптография,да?
orignal
там chaha а не AES
weko
orignal: так а что, джависты не собираются исправлять?
orignal
там вроде в качесте IV используется кусок шифрванного блока данных
orignal
idk ниасилил а деду влом вникать
orignal
а мне лень 10 раз объяснять
weko
ну в i2pd можно сделать блок
weko
а джава будет его дропать просто
orignal
ну мне не хочется самому хрень городить
weko
так а если не хрень
weko
блок то простой
weko
взять просто подписать ключ i например да отправить подпись
orignal
да просто можно отправлять хэш боба чтобы он сравнивал
weko
<orignal> в качестве ключа используется i а в качестве IV хэш
weko
<orignal> да просто можно отправлять хэш боба чтобы он сравнивал
weko
ты под хэшом подразумеваешь подпись или что?
weko
хэш чего?
orignal
хэш роутера к которому мы подключаемся
weko
а толку от него если он всем известен?
weko
я про то что злоумышленик тоже знает хеш и может его спокойно использовать
orignal
так ты не понял
orignal
боб получает его и сравнивает со своим
orignal
если не совпадает говорит иди на хуй и закрывает сессию
orignal
так что делает злоумешленникэ
orignal
он подсовывает кому то фейковый роутер с IP реального
weko
аааа
orignal
а если будет такой блок то там будет стоят хэш фекового ротуера
orignal
а реальный сразу поймет что это не его
orignal
казалосб бы проблема пустяковая но idk ничего не пожелал менять
orignal
а деду не охота вникать
weko
ща подумаю чуток
weko
orignal: так у боба же нету ещё хэша алисы. с чем он сравнит?
orignal
он знает свой собственный
orignal
а алиса должна в сообщении послать хэш боба
orignal
к которому как она думает подключается
orignal
а если не совпадает то отвечает "это не я" и закрывает соединение
weko
почти вкурил, секунду))
orignal
а дед сказал пиши пропозал
orignal
зная что я по английски сделаю 3 ошибки в 2-х словах ))
weko
напиши на русском и закинь в переводчик
orignal
лол
weko
ну а чо они умные щас
orignal
или сразу дать попозал деду на русском
weko
да и его проблемы))
orignal
вот писать по английски меня не научили в дестве
weko
вот он многополярный i2p
orignal
говорить и понимать на слух научить
orignal
читать написанное другими тоже
orignal
а вот писать самому нет
orignal
а дед прекрасно знает о моей неспособности писать по английски
weko
orignal: кажется вкуриваю. чтобы если кто то RI нам скинул где IP реальный и i реальные, но другой ключ роутера (а потому и хэш), то при попытке соединится у нас не вышло и мы бы откинули такой RI
orignal
ну да мы бы понял что эта сессия предназначена там и дали отлпу
weko
ну да чтобы нельзя было роутеры подставлять
orignal
так соединение то устанвлвает не злоумышленник которому нет резона подставлять что либо
weko
распространяет такой RI злоумышненник
weko
правда он ничего не добьётся кроме бана роутера
weko
но это может быть использовано в атаке
weko
например забанить хорошие роутеры, чтобы увеличить процент своих в netdb
weko
orignal: на самом деле можно другим способ найти это. вроде бы, так как раз и писали во время атаки
orignal
нет смотри что получалось
orignal
он распостранял фейковые роутеры с реальными адресами
weko
да я понял
orignal
и куча народу ломилась на них
weko
об этом и говорю
weko
да дудос роутера и сети , помню ))
orignal
угу
weko
фиксилось это вроде привязкой
weko
что когда к нам подключаются, мы сохраняем хэш и i
orignal
ну так и сделано
orignal
если у нас есть профайл роутер
orignal
если были содеинения от него или мы уже соединялись по NTCP2 то как угодно
orignal
а если новый только по NTCP2
weko
но это больше похоже на исключительный случай
weko
потому что можно не запариваться с переходом
weko
потому можно*
weko
ну в плане не делать перех ntcp2 -> ssu2
weko
а во всех случаях когда можно сразу делать ssu2
orignal
возможно
weko
ну сначала пофиксить его конечно ))
weko
надо бы его ещё потестить после изменений
orignal
надо деда пинать
weko
а он сказал чего пропал ?
weko
надо расписать всё, а то уже не влезает в голову
orignal
я не спрашивал
weko
отпуск
weko
видимо
weko
orignal: а ntcp2 разве не другой i?
orignal
другой разумеется
weko
просто если другой то он нам не поможет чтобы ssu2 подтвердить
orignal
там всего 16 байт
orignal
мы подтверждаем сам роутер
orignal
что мы с ним смогли соединиться по NTCP2
weko
мы подвердаем связь i и RouterIdent
weko
а ssu2 i другой
orignal
и s
orignal
ну в приципе да злоумыщленник может воткнуть разыне NTCP2 и SSU2
weko
да
orignal
но тогда ему придется опубликовать свой NTCP2
orignal
реальный
orignal
а котором будет сидеть именно его роутер
weko
ну да сложнее придётся))
weko
заспамить не выйдет
weko
тут вернее всего исправить проблему
weko
а не сможет ntcp2 вставить
weko
потому что если он поставит свой ntcp2, и другой ssu2, то хэш в любом случае ддругой будет
weko
а значит при соединении по ntcp2 он по любому не совпадёт
orignal
хэш тут непричем
weko
а бля
orignal
не совпадет подпись RI
weko
да точно
orignal
если просто что то подменить в чужом
weko
а выйдет наспамить у него... он может один ntcp2 адрес туда вставить, а проверку на хэш не делать
weko
но на этот ntcp2 сервер нагрузка будет пиздец
orignal
не может
weko
почему?
orignal
этот ntcp2 может быть только его собственным
weko
может
weko
ну да он вставит собственный, специальный без проверки хэша
orignal
даже если один на всех ему приедтся пробовать расшифровать первое сообщение с разынми хэщами
orignal
там не проверка
orignal
там НАДО расшифровавать
orignal
потмоу что в этом месте идет публичный эфемеральный ключ из которого солгасуется сессионный
weko
а , ну тогда да
weko
понятно, да
orignal
в NTCP2 случайно сделано все правильно
orignal
на саморм деле причина там тривиальная
orignal
деду было влом делать полноценный эллигатор
weko
эллигатор?))
orignal
цель то была спрятать первое сообщение от DPI
weko
ну да понятно
orignal
а там если эфемеральный ключ x25519 отправлять как есть
orignal
можно понять что это именно ключ x25519
orignal
потому его и шифруют AES
orignal
более правильный способ для этого эллигатор
orignal
он появился позднее в сквозном шифровании
orignal
а когда делеали NTCP2 его еще не было
weko
orignal: тогда короче злоумышленнику нужен ещё более мощный сервер чтобы обойти расширенную версию костыля )))
orignal
только ты забыл еще об одном
orignal
IP адреса NTCP2 и SSU2 будут разные
orignal
что сразу же палево )))
weko
палево )) но бывает же такое
weko
так атака в любом случае палево
weko
дудос же
orignal
ну так это легко вычисляется
weko
ну может если на деанон то важно чтобы не видно было
orignal
можно кстати сразу проверку добавить
orignal
что если IP не совпадают то всегда сначала пытаться по NTCP2
weko
orignal: формально разные адреса не плохо, просто такое редко бывает
weko
хорошая идея
weko
но тоже костыль))
orignal
никогда не встречал такого
orignal
тестирование же адреса делается по SSU2 а публиуется тот же самый NTCP2
orignal
грубо говоря в реальности такого просто не бывает
weko
ну можно так настроить просто не яснр зачем
weko
orignal: ну задать вручную можно адреса
orignal
где?
weko
и настроить чтобы порты в разные адреса уходили
orignal
в i2pd такой натсройки нет
weko
ну значит добавить
weko
)))
orignal
порты можно адреса нельзя
orignal
ну вот такое "добавление" сразу банить
weko
ну ничего плохо нету на самом деле
weko
плохого
weko
вдруг кому то очень надо))
weko
при чём кстати когда к нам NTCP2 подключаются там точно известно что и i ssu2 верный
orignal
и по SSU2 тоже
weko
да
orignal
когда к там потому что там в SessionConfirmed приходит RI
orignal
и если там если IP адреса мы сравниваем с теми откуда пришло соединение
orignal
если не совпадает сразу в бан
weko
кстати
weko
насчёт этого
weko
если кто то в сети для нас адреса подменяет
weko
это кстати ещё одна причина, почему для туннелей нужно использовать только RI, полученые анонимно
weko
если злоумышленник - гос-во, у него больше возможностей
weko
например могут адреса источника подменять спокойно. и самим получать данные вместо целового адреса
orignal
китай наример
weko
потому и использоать для туннелей можно не все подряд RI
weko
Webconsole
weko
3902087702:me ⇒ Qxpp ⇒ KitS ⇒ sy6o ⇒ ( 282ms ) established, 17179869182.02 GiB
weko
Streaming
weko
максимальный размер окна слишком маленький. нужно ставить хотя бы 4096. но по факту, если окно растёт, значит оправданно и ограничивать смысла нету (либо большое число либо без лимита). иначе нужно исправлять алгоритм.
weko
возможно, неверно считался RTO - *1.5 вместо 1.8 (1.8 в SSU2). требуется проверка
weko
фактическое время переотправки от 1 до 2 RTO, а не ровно (хотя бы приближенно) RTO
weko
хотябы слегка ускорить увеличение window, сделать не линейным, а экспоненциальным (*1.01)
weko
сделать либо распределение пакетов стриминга по пачкам (оптимальным для буфера транспорта), а не сколько в ACK придёт (распределение по времени). В идеале пачка равна 1 и буферы по размеру минимальные соотвественно.
weko
Закрытие сессии, запутанное и вполне вероятно багованное.
weko
NTCP2/SSU2 buffer
weko
буферы слишком большие - большой буферы делают работу алгоритма окна на низких скоростях менее качественной (мысленно представил, трудно расписать, хотя если надо опишу)
weko
Когда буфер забит, не влезаюшие пакеты должны дропаться, а не закрываться сессия (!!!) - PostI2NPMessages
weko
SSU2
weko
отсутствие проверки хэша бобом боба, отправленным алисой (( чтобы если кто то RI нам скинул где IP реальный и i реальные, но другой ключ роутера (а потому и хэш), то при попытке соединится у нас не вышло и мы бы откинули такой RI )). костыльный фикс: ждём когда к нам
weko
подключаться по ssu2 или ntcp2 (или мы по ntcp2, но злоумнышник может вставить свой реальный ntcp2 (при этом будут разные адреса ssu2 и ntcp2 и ему нужны большие ресурсы под это)), и сохраняем i и router ident
weko
неизвестная проблема со скоростью. требуется подтверждение после фикса некоторых других багов, чтобы убедится что они не были причиной.
weko
Logging
weko
добавить параметр для отображения миллисекунд в логах
weko
Tunnel Building
weko
Нужно повысить скорость создания туннелей, текущая скорость некомфортна для использования роутера и при низком TCSR создаваться туннели не успевают
weko
офомлю лучше потом
weko
оформлю*
weko
Ещё кое что понял: предположим, у нас есть стрим, в который мы постоянно пускаем мало данных. соотвественно, нам часто приходит ACK на малое количество пакетов. Но при этом окно увеличивается независимо от того, какой ACK нам пришёл. итого окно сильно вырастет (явно
weko
больше чем надо), так как потерь на низкой скорости не будет. И после, если начать грузить на максимум, то куча пакетов всрётся, и окно будет долго падать обратно, а стрим сильно тупить. алгоритм явно нужно сильно менять. Мне вообще код в ProcessAck кажется очень
weko
странным
weko
И мне вообще пока не понятно, почему RTO настолько больше чем RTT... 1.8 в SSU2, 1.5 в стриминге
weko
SRTT (smoothed round-trip time)
weko
RTTVAR (round-trip time variation)
weko
ясненько )))
weko
Whenever RTO is computed, if it is less than 1 second, then the RTO SHOULD be rounded up to 1 second.
weko
а почему...
weko
А ну блять забыл самое главное - проблему с зависанием сессий NTCP2
weko
Кстати вот что они виснут может и решит, а почему они не пересоздаются тоже открытый вопрос
weko
[04:01:45] <weko> Whenever RTO is computed, if it is less than 1 second, then the RTO SHOULD be rounded up to 1 second.
weko
То есть если всрался один пакет, то мы должны секунду сидеть без данных, даже если пинг 10ms?
tetrimer
CAPS_FLAG_HIGH_CONGESTION = 'E'; - индикатор перегрузки?
tetrimer
Тогда почему с ним еще какое-то время (десяток минут) растет количество транзитных туннелей?
tetrimer
Transit: 1.17 GiB (291.19 KiB/s)
tetrimer
Router Caps: OfRE
tetrimer
Version: 2.50.2-14-g7cfcb12c
Vort
подтверждение бОльшей скорости через SSU2 хоть кто-нибудь хоть когда-то получал?
Vort
я пока что вижу единственное преимущество SSU2 - поддержку пробива NAT. и то, работает этот механизм не очень-то
Vort
пир тест через SSU2, может, ещё важен. но это тоже к скорости отношения не имеет
Vort
это я к тому, что "переподключиться с NTCP2 на SSU2 и получить более качественный коннект" может быть малореально на данный момент
weko
[08:53:45] <tetrimer> Тогда почему с ним еще какое-то время (десяток минут) растет количество транзитных туннелей?
weko
Потому что RI не сразу до всех доходит
weko
Vort: это теоретическое рассуждение
weko
При условии что ssu2 работает как надо
Vort
"Потому что RI не сразу до всех доходит" - а отлупы узел не должен начинать давать на новые транзиты что ли пока флаг висит?
Vort
"это теоретическое рассуждение" - _если_ подтверждений практикой нет, то лучше такую логику в коде не держать
Vort
вдруг, допустим, наоборот, медленнее становится. зачем такое надо?
weko
Vort: так а я не уверен что такая логика в коде есть или нет
weko
Ну как я уже сказал именно переключение не очень полезно
weko
А сразу выбирать ssu2 смысл имеет
Vort
поэтому я и написал. что оно может по двум причинам быть не очень полезным, а не только по одной
weko
А какая вторая? Я только одну увидел
weko
Я говорил именно про переключение, потому что редкая ситуация если сделать чтобы всегда выбирался ssu2 когда можно
Vort
так глюки ж ты какие-то описывал вылазят из-за переподключения. я не очень вчитывался
weko
Глюки на ntcp2
weko
А на ssu2 пока хз - может тоже
Vort
если его разрывать для того, чтобы получить шанс переключиться на ssu2, да?
weko
Нет не надо так делать
weko
Или ты про какое переключение?
weko
Короче разрывать из-за очереди неверно даже ради "шанса на ssu2"
weko
Потому что сообщения из очереди сгорают
weko
Ни в каком случае так делать не надо
Vort
вот. это одна причина. а вторая - можно получить на ssu2 ещё хуже связь. потому, что чётких доказаьтельств, что SSU2 в среднем лучше - нету
weko
Ну да и то и другое понятно
weko
Первое мы знаем, второе тоже знаем
weko
Говорю, рассуждение теоретическое
weko
Которое работает в идеале
orignal
потому что E ставится либо по достижении скорости либо числа тоннелей
Vort
и что? в каком-то из случаев надо продолжать принимать транзиты?
orignal
ни в каком
orignal
просто статус E не менется каждый раз
orignal
а примерно раз в 12 минут
Vort
так как объяснима ситуация о которой говорит tetrimer кроме как багом?
Vort
то есть, какие ещё варианты объяснения есть
orignal
так вот я ее и объясняю
orignal
дошли до лимита по каналу выставили E
orignal
потом перестали принимать трафик уменьшился
orignal
проинимаем снова число транщитных тоннелей растет потому что не дошли до предела
orignal
а E стоит потому что обновляется не сразу
Vort
то есть, кроме E есть ещё внутреннее состояние перегрузки?
Vort
которое обновляется чаще
orignal
там нет состояния как такового
orignal
мы на каждый запрос проверяем можем мы принять или нет
Vort
в общем, примерно понятно - E - это не значит, что сейчас перегрузка, E значит - что перегрузка недавно была
orignal
E это значит сигнал другим пошли на хуй
orignal
это не то что у нас счас на самом деле а как видят другие
Vort
я просто вспоминал волны коннектов у себя. и сейчас понял, что то были ложные Firewalled, а не E
orignal
E это другое
Vort
E, значит, более гладко работает. ну и хорошо
orignal
но кстати работатет довольно эффективно
orignal
просто раньше оно плохо работало потому что idk поломал у джавистов
weko
Я мало толку вижу в этом
weko
Можно в отлупе слать причину
weko
Или вообще если есть отлуп, не использовать роутер какое то время
weko
orignal: для чего вообще I используется? Просто чтобы были какие то случайные данные?
weko
i
orignal
для шифрования заголовка пакета
weko
Просто если это просто случайные данные, то DPI если имеет RI, то знает и ident, и i. Я точно не знаю, как там идёт защита от DPI, но точно уверен что разницы что использовать нету
weko
Потому что хэш тоже по сути случаен для каждого роутера
weko
В том смысле, что ключи генерируются случайно, а ident на их основе
orignal
в старом SSU кстати он всегда был ident
weko
Вопрос нахуя мудрить)
orignal
ну так деду захотлеось
orignal
похоже jrandom это в свое время предусмотрел
weko
orignal: так стало понятно почему при той баге сессия не пересоздаётся?
orignal
ты думаешь я всю ночь не спал оь этом думал?
orignal
ты разобрался в сценарии что просиходит при соединении?
weko
orignal: ну просто ты нашёл кусок, я ж не знаю объясняет это что не соединяется или нет
orignal
нет
orignal
это может объяснять ошибку AEAD
weko
после ошибки AEAD на другой стороне всплывает Bad file descriptor при отправке
weko
явно оишбка где то в i2pd
weko
тоесть тут одна бага, которая если срабатывает вызывает другую багу
orignal
нет
orignal
ошибка AEAD возникает когда получено меньше чем заказывали
orignal
нет там бага с сокетом явно
weko
да но почему мы меньше получили
weko
ядро багануло?
orignal
надо системные логи читать
orignal
такое бывает на линуксе
weko
ладно предположим случилось. но что происходит дальше явно проблема i2pd
weko
в частности Bad file descriptor на другой стороне
weko
явно завершение работает неверно
orignal
так почему дальше не пересодиняется?
weko
сначала ставить Unreacable в peerprofile. а что после, когда пропадает - не ясно
weko
ставиться*
weko
вот я предлагаю сначала выяснить почему ставить этот флаг
weko
ставиться*
orignal
нет почему он вообще ставит
orignal
почему не может соединиться?
orignal
не может установить TCP соединение
weko
надо логи вывести
orignal
та сторона не отвечает
orignal
ну так ясен пень
weko
после, сейчас вспоминаю проблемы и заношу в todo
weko
и решения соотвественно
weko
я даже как то давно расписывал защиту от сивиллы или типо того
weko
там мудренно всё было )
weko
надо будет найти тоже занести
`
Целый день какером обсуждали?
`
12 часов прошло, моего офлайна, а тема будто та же.
weko
нет это другое
`
Даже не заметил, пока на время сообщений не посмотрел.
`
Однако вопрос.
`
А что там у Китая с ш2зв? Есть связь с кем-то аттуда7
weko
в каком смысле связь?
weko
что китайцы что-то мутят это известно
weko
или ты про то, работает ли?
`
weko, в смысле кто-то переписывается с китайским китайцем проживающим в Китае?
`
Как у них живёт ш2зв без "допингофф"?
weko
врядли. вероятно они банят IP из NetDb
weko
или как минимум связку IP:port
`
weko, а сам траффик никак не "нюхается"?
weko
без понятия
weko
вообще как я понял RI в базе бывают разного уровня надёжности
weko
я тут некоторые моменты понял, многое надо будет сделать
weko
с NetDb всё сложно
weko
например если к нам подключились по транспорту и соотвественно отправили RI (которого у нас не разу не было) - нельзя такой RI флудить, потому что возможно кто то подменяет адрес
weko
тут много всяких моментов на самом деле
abc
yo yo, i noticed in i2pd webconsole something interesting, it says it knows about 9k router, but is a part of 10k transit tunnels, hows that possible?
Vort
some tunnels are failed, maybe that's why
orignal
because tunnles might share same link
weko
orignal: думаю написал
weko
не знаю насколько граматически верно ))
weko
сейчас закину
orignal
грамматически верно пусть дед правит ))
weko
я тебе скину чтоб глянул а то стыдно будет бред кидать
weko
orignal:
weko
вопрос кстати такой. если в ssu2 при создании сессии ошибка при расшифровке, мы не отвечаем?
weko
или что отвечаем, если отвечаем?
orignal
смотря чего
orignal
смотря на какой стороне
weko
если i неверный
weko
боб
orignal
как правило отвечаем
orignal
думаю что нет
orignal
мы считаем просто мусором
weko
тогда окей, RI просто отлетит как недоступный
orignal
да
weko
прочитаешь пропосал? там не много
orignal
сча
orignal
а зачем нам посылать адрес алисы?
orignal
он же всегда приходит в SessionConfirmed
orignal
остальное нормально
orignal
смысле слать адрес алисы же нет никакого
weko
orignal: ну смысла нет потому написано что всегда 0
weko
просто блок называется RouterIdent а не BobRouterIdent
weko
мало ли понадобится
orignal
так пусть он будет просто routerindent никаких больше флагов
weko
нет там флаг от боба что всё верно
orignal
в SessionRequest идет боба
weko
нужен
orignal
в SessionCreated тоже