333.i2p

Почему происходят эти ошибки?
1) "I2PTunnel: write error: Bad file descriptor"
2) "Tunnels: Can't create inbound tunnel, no peers available"
Uptime: 6 hours
Routers: 1351
Client Tunnels: 202

С трудом верится в наличие идентичного бага в двух реализациях. В i2p не стабильно работают тоннели с одинаковым ключом. Один из таких тоннелей можеть падать. Налицо наличие конфликта из-за ключа.

получился дубликат сообщения.

Last edited: Sat, 04 Sep 2021, 11:53am от sAzh7Y

Методом научного тыка удалось нащупать и устранить проблему. Floodfillы оказались не причастны. Одновременно с этим нащупал нечто неожиданное для себя.

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

Сменой ключа на клиентском сервисе удалось решить главную проблему и сразу обнаружить другую: почему нельзя использовать один ключ более одного раза и для разных типов тоннелей? Этот вопрос актуален, в том числе, для i2p.

Last edited: Sat, 04 Sep 2021, 11:54am от sAzh7Y

На той же самой машине у меня есть ещё один сервис. Он доступен, вообще нет проблем. Ты всё ещё винишь floodfill?

Значение Routers снижается?
Видел похожее на VPS в middle east - база постепенно и неумолимо деградирует. Потом нашёл ту страну в списке борющихся с I2P.
Попробуй VPN с обфускацией.

Плохой floodfil попадал на протяжении суток? Сейчас запустил - всё равно флудфилы плохие.
Возможно проблема кроется в другом - вчера обновил систему, среди завимосотей i2pd был openssl.

Установил нативный i2p, там поднял свой сервис - попадаются только хорошие флудфилы. Вполне возможно я откажусь от i2pd в пользу i2p.

Last edited: Thu, 02 Sep 2021, 08:20am от sAzh7Y

Мой сервис недоступен внутри сети. Такая бодяга уже возникала ранее. Вылечил перезапуском демона. Сейчас перезапуск не помог.

21:32:28@901/info - SOCKS: requested ***.i2p:**
21:32:28@901/info - Destination: Requesting ***= at rGY3Vu0LSZ~nI7YBj7x-sGgN224-JhxoVs-rNlmAH10=
21:32:29@901/info - Destination: Requesting ***= at rDIsxDdTlBTYzkU~hb1bE7AP2lP2RkqTOJhCUz9BKsk=
21:32:34@901/info - Destination: Requesting ***= at rKbFuTGrLvir4PBafeLYOQSIdWt-QZnTAKZJWcOFxp8=
21:32:34@901/info - Destination: Requesting ***= at rWZMOblslnhKzTci1SKINubhLA4tuOqdKDExTwzjRSI=
21:32:34@901/info - Destination: Requesting ***= at rRL5aK9EUjmkstNCnJjmD9Vj~9MtR5xZK39kBcF7aQ0=
21:32:35@901/info - Destination: ***= was not found on 7 floodfills
21:32:35@901/error - SOCKS: error when creating the stream, check the previous warnings for more info
21:32:35@901/warn - SOCKS: v4 request failed: 4
21:32:35@901/warn - Destination: Request for ***= not found

Аналогично через HTTP прокси.

Обратил внимание на крайне малое количество обращений к сервису с утра. Они есть, но в мизерном количестве. Самое интересное, что я не могу получить доступ к собственному сервису, обращаясь к нему через HTTP или SOCKS прокси.

Получилось!

[***********]
type = http
inport = ****
host = 127.0.0.1
port = *****
keys = **********
address = 127.0.0.1
enableuniquelocal = true
gzip = true

Дождался версии 2.38. Описанная проблема сохраняется.

До обновления адреса всех клиентов варьировались в диапазоне 127.0.0.1-127.255.255.255.После обновления все клиенты стали обращаться с адреса 127.0.0.1. Адрес клиентов регистрируется в логе сетевого сервиса. Я пока не нашёл иного решения этой проблеме, кроме отката на версию 2.36.

Начиная с версии 2.37 перестал был уникальным исходящий псевдо-IP адрес, регистрируемый в логе сервиса при обращении к этому сервису. Проще говоря, я хочу видеть адрес 127.52.52.52 вместо 127.0.0.1.
Назови причину и способ устранения.

Но только не твой джамп. И твоей книге не быть в моём конфиге.

Адреса популярных ресурсов мы резервируем сами. Например, ты не сможешь зарегистрировать 102chan по новой.

Всегда можно поднять пустую заглушку на этом адресе локально.

Если он лежит в больнице столь долго, то вряд ли ему потом будет дело до i2p.