А ты уверен, что айпишник на WAN порту роутера «реальный»? (в смысле из белого списка маршрутизируемых в пределах интернета, а не выделенный для локальных сетей и раздачи по 3G провайдерами)

Я понять не могу что ты пытаешься сделать? Если у тебя трансмишн не конектится просто включи шифрование. MTC вроде как режет пакеты по их содержимому. С шифрованием должно прокатить.

192.168.100.19

Также тестировал тут: http://www.canyouseeme.org Не помогло.

Это как, простите?! У тебя ip для локальных сетей.

Стоит настройка «Предпочесть шифрование», сменил на «Require encryption» - ничего не изменилось. Порты закрыты.

Поясни, в чем может быть загвоздка.

UPD2: выяснилось, что под виндой с ноутбука работает закачка, значит, проблема с лялехом.

Посмотри на роутере в статусе, какой айпишник на WAN-порту (он же оптический порт). Он НЕ должен быть из диапазонов:

10.0.0.0/8 (10.0.0.0 - 10.255.255.255)
100.64.0.0/10 (100.64.0.0 - 100.127.255.255)
172.16.0.0/12 (172.16.0.0 - 172.31.255.255)
192.168.0.0/16 (192.168.0.0 - 192.168.255.255)

Суть в том, что «реальных» маршрутизируемых адресов относительно мало и они стоят денег для оператора. Поэтому некоторые провайдеры выдают «серые» адреса, которые потом преобразуют в один реальник на своём маршрутизаторе. Ваш домашний маршрутизатор выполняет такую же роль. Он «прячет» вашу локальную сеть за одним адресом на WAN порту в сети провайдера и для того, чтоб ваш локальный хост был виден из сети интернет нужна обратная операция (в вашем случае port forwarding), которая при поступлении запроса на адрес WAN порта перенаправляет запрос уже в локальную сеть. Причём при использовании NAT такая операция должна быть проделана на всех маршрутизаторах с NAT. Собственно, если провайдер сам занимается NAT, то у вас нет возможности на это повлиять.

Обычно, за доп. плату провайдер предоставляет услугу «реальный IP», что означает выдачу на WAN порт вашего роутера заветного IP-адреса без преобразований (на самом деле не всегда, но обычно именно так) и вы уже можете его пробрасывать как вам угодно.

Собственно, важно понимать, что даже якобы реальник может быть за NAT, такое редко бывает, но бывает. Для проверки NAT вам необходимо посмотреть в статусе вашего роутера выданный/назначенный айпишник, если он в диапазоне заведомо серых адресов (выше список) - нужно обращаться к провайдеру с запросом «выдайте мне реальник». Если айпишник выглядит реальником, дальше зайдите на любой сайт определения вашего адреса (myip.ru или другие, их много). Если на сайте будет другой адрес, чем тот что назначен вашему роутеру - вы за провайдерским NAT или прокси-сервером, поэтому лучше заходить на такие сервисы через https. И тут тоже потребуется заказывать услугу «реальный айпи».

не парься про закрытый порт - оно может криво определять.

В конторе машина с белым ip ( и ipv6 ), а transmission-daemon говорит, что закрыто.

UPD2: Deluge заработал и на openSUSE. Значит, дело в напилинге Transmission.

Да, про серые адреса я слышал давно еще, но не совсем понял, зачем нужен «белый» для P2P.

Для лучшей работы. А так - не нужен, да. Собственно, в торренте ты можешь качать и без реальника/без проброса портов, вот только подключаться ты сможешь только к тем, у кого этот реальник есть (или проброс средствами upnp того же). Ну и отдача повышается, если с реальником.

Починить бы

http://retracker.local/announce Got a scrape error «Could not connect to tracker»

гм. Чинить retracker.local ?

Его для начала нужно иметь :)

Если ты знаешь, что у проваейдера есть ретрекер, то можно его адрес указать в /etc/hosts

Правда всякие #$%&^% avahi могут перебивать домен .local для нипоймикаких целей.

Да трекер-то http://bt2.t-ru.org :) Не понял, что произошло, я поставил случайный порт в Transmission, перезапустил .torrent-файлы и заработало. Хотя до сих пор пишет - Could not connect to tracker. Удалил все правила в проброске портов роутера, включил файрвол, все равно работает. Чудеса