333.i2p

Rdfpfh wrote:

Ребят, а есть решение для этих микроконтроллеров

Стесняюсь спросить - а для чего так упарываться? Есть же недорогие китайские модули для построения роутеров, HI-LINK HLK-7622 и HLK-7688 на MT7622 и MT7688 соответственно. Там и мощщи в достатке, и вайфай в наличии, и мозгов от 128 мегов. А медь и туда и сюда прикручивать отдельно придётся, разницы в этом нет. Ссылочку на али подкинуть?

Подтверждаю. Всё ок.

I2P shifting into destruction phase.

I predicted this. When zzz disappeared and at least one of the guys doing this seemed to be from his writings Jewish, I predicted they would after the take over work for a while and then start slowly changing the algorithms and making the whole thing unusable. They DO NOT want any uncensored media.

Look at the newest release,

"...Legacy transport protocols are being removed..."

"...I2P no longer allows I2P-over-Tor, connections from Tor exit IP addresses are now blocked..."

I predicted,

"...I have speculated that java I2P has been taken over by hostile forces and I also predicted that eventually this new software from the java I2P would screw up the network...."

Here,

http://333.i2p/topics/222?page=1#p1976

I suspect that dropping some transports is to shift older routers into their new code. At some point they will start adding small snippets of code that make it easier to track you. Canceling tor out routers, simple, shut off anonymous browsing and interaction.

The way the java I2P was taken over was classic Jewish subversion. Jew weasels his way in by making himself useful doing administrative task. Stuff zzz doesn't want to do. But one day zzz wakes up and finds he has been locked out. It would not surprise me at all if he was dead.

BTW how many people do you know work on something over ten years, all the while complaining about how the former maintainer of the code disappeared and how he would never do that, THEN closes his forum and drops off the face of the earth without a word?

That zzz did this for the reasons we have been told is not credible. At all.

We see the lengths that the Jews will go to in the recent assassination attempt of Trump. You think they care any more about zzz than they do Trump? And yes I'm fully aware that Trump may have set this up as a fake himself. I would not rule it out completely.

When they do start corrupting the code it will likely be very subtle. How many people actually go through all the code to I2P. One, two, likely none.

I should add I'm not saying I2Pd is the same.

Last edited: Fri, 02 Aug 2024, 02:34am от VargThePissed

в tunnels.conf или в tunnels.d отдельным файлом

Починено.

ребята помогите я хотел поиграть в майнкрафт на сервере mc.r4sas.i2p:25565

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

[MC-R4SAS]
type = client
address = 127.0.0.1
port = 25565
destination = qkpmajnvhilmwxzwd53vdigk6dagz6zdqynm6knsvs3yb35gglia.b32.i2p
destinationport = 25565
gzip = false
inbound.length = 1
outbound.length = 1
inbound.quantity = 3
outbound.quantity = 3
i2cp.leaseSetType = 3
i2cp.leaseSetEncType = 4
keys = transient-minecraft-r4sas

Нет я дефолтный флаг не трогал. Просто если разные треды то действительно могут быть проблемы.
Я попробовал запускать снарк, там все нормально запускается и останавливается.
Если новые сессии не создаются это значит тред подвис, неплохо бы к нему прицепиться gdb и посмотреть на чем.

Да, забыл добавить, когда этот баг случился, новые i2cp сессии не будут создаваться.

>А если только одна сессия, то завершается нормально?
>И еще вопрос: там один тред или несколько? Параметр i2cp.singlethread в конфиге.
У меня он не был задан в конфиге. i2pd на виртуалке с одним ядром. BiglyBT создаёт минимум 2 сессии, но вторую с большой задержкой. Тогда постараюсь подловить момент, когда ровно одна сессия...

i2pd 2.53.0 с сегодняшним фиксом. Роутер только что запущен, запускаю BiglyBT, жду появления нужного количества сессий, создания туннелей, и выключаю BiglyBT...

i2cp.singlethread=true и 1 сессия. Результат: 100% cpu, единственная сессия исчезла, новые сессии не создаются.

i2cp.singlethread=true и 2 сессии. Результат: 100% cpu, осталась 1 из 2 сессий, новые сессии не создаются.

i2cp.singlethread=false и 1 сессия. Результат: 0% cpu, единственная сессия исчезла, ошибку "I2CP: Can't receive header" видел, новые сессии создаются и работают.

i2cp.singlethread=false и 2 сессии. Результат: Результат: 0% cpu, обе сессии исчезли, новые сессии создаются и работают.

Я подозреваю, что ошибка "I2CP: Can't receive header" была во всех случаях, но я не успел её заметить. Потом проверил, когда во второй раз выключал BiglyBT с двумя сессиями, два раза появилась эта ошибка.

Вывод: нужно ставить i2cp.singlethread=false.

orignal, а дефолтное значение этого флага менялось в новой версии? У меня в конфиге его не было. В конфиге, который лежит в репозитории в contrib, тоже его нет. Разве что в доках можно узнать о его существовании.

Кстати, когда с i2cp.singlethread=false во второй раз выключил BiglyBT, стала проскакивать такая ошибка: error - Router: Runtime exception: cannot create std::vector larget than max_size()
Где-то в течение минуты она прекратила появляться.

А если только одна сессия, то завершается нормально?
Этот код никто не трогал несколько лет.

И еще вопрос: там один тред или несколько? Параметр i2cp.singlethread в конфиге.

Last edited: Tue, 23 Jul 2024, 05:24pm от orignal

Фикс не помог.
Ничего не изменилось, и в логах та же ошибка I2CP: Can't receive header.

Починил.
https://github.com/PurpleI2P/i2pd/commit/23e323...

i2pd 2.53.0 проблема после закрытия I2CP сессии

После обновления с версии 2.52.0 на 2.53.0 появилась проблема с I2CP.
К i2pd по I2CP подключается BiglyBT. i2pd и BiglyBT запущены на разных хостах в одной локальной сети, так что присутствует фактор небольшой задержки в I2CP соединении. Но я пробовал минимизировать задержку и искуственно создавать её настройками netem, разницы нет, значит она не играет роли здесь.

BiglyBT создаёт 5 I2CP Local Destinations:
[BiglyBT: DHT Pure+]
[BiglyBT: DHT Bridge]
[BiglyBT: DHT Pure]
[BiglyBT: DHT Mixed]
[BiglyBT: DHT Mixed+]

Качается нормально.

Когда выключаю BiglyBT, появляется эта проблема. Сразу же i2pd нагружает процессор на 100% (и она не проходит без перезапуска), I2CP Local Destinations не исчезают (точнее, только одна из них исчазает (вроде всегда [BiglyBT: DHT Mixed] исчезает)):
[BiglyBT: DHT Pure+]
[BiglyBT: DHT Bridge]
[BiglyBT: DHT Pure]
[BiglyBT: DHT Mixed+]

Со временем у них исчезают исходящие туннели, но остаются входящие.

В логах сразу после выключения BiglyBT отловил это сообщение: "error - I2CP: Can't receive header".
Также много сообщений "Tunnels: Test of tunnel .... failed" про разные туннели. До запуска BiglyBT их нет. Во время работы BiglyBT они иногда появляются, где-то раз в 5-20 секунд, по одному или по 3 штуки сразу (когда уже качается несколько сотен КБ/с). После выключения BiglyBT они идут стабильно раз в 5 секунд, по 3-4 штуки сразу.

Хочу написать вспомогательный софт для замеров. Вернусь с более продолжительными наблюдениями.

Сегодня опять началось. У меня 2 http proxy на одном роутере, вёл наблюдения за ними. Оба настроены на 6 туннелей в обе стороны, длина 3 хопа + 1 рандом. Туннели большую часть времени простаивают, но где-то раз в минуту я через них посылаю маленькие запросы. В какой-то момент на входящих туннелях начали ставится примерно 50% yggdrasil-пиров. Я записывал список входных пиров чуть реже, чем раз в 10 минут. Вот 5 замеров для обоих прокси (где-то час этим занимался). Видно, что сначала ставится много ygg-пиров, потом приходит в норму. Имена пиров заменил на псевдонимы. Если подписано ygg, значит это ygg+clearnet пир. Если ничего не подписано, то это чисто clearnet пир.

Замер 1:
HTTP PROXY 1
LLLL
NNNN
EEEE ygg
SSSS ygg
3333
MMMM

HTTP PROXY 2
9999
9999
SSSS ygg
WWWW ygg
SSSS ygg
SSSS ygg

Замер 2:
HTTP PROXY 1
CDCD
EEEE ygg
IJIJ
EEEE ygg
TTTT
HHHH ygg

HTTP PROXY 2
RRRR
ABAB
9999
JJJJ
SSSS ygg
STST

Замер 3:
HTTP PROXY 1
QQQQ
SSSS ygg
EEEE ygg
EEEE ygg
EEEE ygg
6666

HTTP PROXY 2
WWWW ygg
XXXX
EEEE ygg
EEEE ygg
8888
UUUU

Замер 4:
HTTP PROXY 1
IIII
BBBB
EEEE ygg
QRQR
YYYY

HTTP PROXY 2
7777
KLKL
EEEE ygg
PPPP
2222
EFEF

Замер 5:
HTTP PROXY 1
EEEE ygg
DDDD
KKKK
9999
EEEE ygg
GHGH

HTTP PROXY 2
2222
CCCC ygg
OOOO
VVVV
FFFF
0000

Не воспроизводится проблема. Orignal, пока забей.
Если я смогу воспроизвести проблему, я напишу с большими подробностями.
Есть предположение, что надо ухудшить качество связи, я буду экспериментировать.