Transmission+Nas+Ipv6

У меня достаточно своеобразная проблема, надеюсь, что кто-нибудь сможет мне помочь или просто объяснит этот вопрос:
У меня есть NAS Synology DiskStation DS713+ (прошивка DSM 4.3-3776-3 от 2013/08/17), на который я поставил Transmission из реп. сообщества (версия 2.82-5).
Проблема в списке трекеров (см. скриншот)

Через Transmission Remote GUI (последняя версия) или даже через родной веб интерфейс на вкладке списка трекеров видно, что у адреса трекера bt.ipv6.nnm-club.info стоит ошибка "Could not connect to tracer". Это как бы неожиданно, т.к. у меня поднят ipv6 тунель через anonymous.freenet6.net. Очевидно, что у меня что-то ненастроено, но я не могу разобраться что.
Предлагаю логи полученные через SSH:
Начну с банального:

Код: выделить все


DiskStation> ping nnm   ipv6.nnmclub.to
PING ipv6.nnmclub.to (2001:470:1f15:f1:6e6e:6d2d:636c:7562): 56 data bytes
64 bytes from 2001:470:1f15:f1:6e6e:6d2d:636c:7562: seq=1 ttl=57 time=203.833 ms
64 bytes from 2001:470:1f15:f1:6e6e:6d2d:636c:7562: seq=2 ttl=57 time=203.778 ms
64 bytes from 2001:470:1f15:f1:6e6e:6d2d:636c:7562: seq=3 ttl=57 time=198.920 ms
^C
--- ipv6.nnmclub.to ping statistics ---
4 packets transmitted, 3 packets received, 25% packet loss
round-trip min/avg/max = 198.920/202.177/203.833 ms

DiskStation>
DiskStation> ping ipv6.nnmclub.topv6.nnmclub.to v6.nnmclub.to 6.nnmclub.to .nnmclub.to nnmclub.to \nnmclub.tonnmclub.to nnmclub.to
PING nnmclub.to (2001:470:1f15:f1:6e6e:6d2d:636c:7562): 56 data bytes
64 bytes from 2001:470:1f15:f1:6e6e:6d2d:636c:7562: seq=0 ttl=57 time=209.527 ms
64 bytes from 2001:470:1f15:f1:6e6e:6d2d:636c:7562: seq=1 ttl=57 time=208.843 ms
64 bytes from 2001:470:1f15:f1:6e6e:6d2d:636c:7562: seq=2 ttl=57 time=206.741 ms
^C
--- nnmclub.to ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 206.741/208.370/209.527 ms

DiskStation>
DiskStation> ping nnmclub.to
PING nnmclub.to (46.246.44.90): 56 data bytes
64 bytes from 46.246.44.90: seq=0 ttl=56 time=190.546 ms
64 bytes from 46.246.44.90: seq=1 ttl=56 time=190.279 ms
64 bytes from 46.246.44.90: seq=2 ttl=56 time=190.392 ms
64 bytes from 46.246.44.90: seq=3 ttl=56 time=190.459 ms
^C
--- nnmclub.to ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 190.279/190.419/190.546 ms

DiskStation>
DiskStation> ping nnmclub.to
PING nnmclub.to (2001:470:1f15:f1:6e6e:6d2d:636c:7562): 56 data bytes
64 bytes from 2001:470:1f15:f1:6e6e:6d2d:636c:7562: seq=0 ttl=57 time=192.807 ms
64 bytes from 2001:470:1f15:f1:6e6e:6d2d:636c:7562: seq=1 ttl=57 time=190.192 ms
64 bytes from 2001:470:1f15:f1:6e6e:6d2d:636c:7562: seq=2 ttl=57 time=189.239 ms
^C
--- nnmclub.to ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 189.239/190.746/192.807 ms

Вывод:
1. Пингуется форум.
2. Неожиданно, что предпочитается Ipv6 адрес, при отключении туннеля, как видно, пинг идет на Ip4 адрес.

Итог: я в тупике пока, гуглю понемногу. Перспектива уйти с раздач из-за очередной волны блокировок огорчает. Буду рад умным мыслям, вопрос хоть и специфический, но надеюсь на помощь в нем

Проверил на transmission 2.77-r1 и 2.88-r3 — всё работает. Возможно, проблема с неправильным значением MTU для IPv6-интерфейса. Попробуйте воспроизвести проблему и поймать трафик до трекера пакетным сниффером (например, wireshark или tcpdump).

Добавлено спустя 1 минуту 55 секунд:

И, конечно же, проверьте опцию bind-address-ipv6, там должно быть "::".

google писал(а):

Добавлено спустя 1 минуту 55 секунд:
И, конечно же, проверьте опцию bind-address-ipv6, там должно быть "::".

Проверил, все настроено правильно.
Прилагаю вывод ifconfig, может натолкнет на что-то...

Код:

bond0 Link encap:Ethernet HWaddr 00:11:32:1B:79:81
inet addr:192.168.0.124 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::211:32ff:fe1b:7981/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:192891322 errors:0 dropped:0 overruns:0 frame:0
TX packets:308660547 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:37368810162 (34.8 GiB) TX bytes:395924636088 (368.7 GiB)

eth0 Link encap:Ethernet HWaddr 00:11:32:1B:79:81
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:192835125 errors:0 dropped:0 overruns:0 frame:0
TX packets:308660547 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:37364519775 (34.7 GiB) TX bytes:395924636088 (368.7 GiB)
Interrupt:16 Memory:40300000-40320000

eth1 Link encap:Ethernet HWaddr 00:11:32:1B:79:81
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:56197 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4290387 (4.0 MiB) TX bytes:0 (0.0 B)
Interrupt:17 Memory:40200000-40220000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:121044 errors:0 dropped:0 overruns:0 frame:0
TX packets:121044 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:9522053 (9.0 MiB) TX bytes:9522053 (9.0 MiB)

tun Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet6 addr: 2001:5c0:1400:a::45f/128 Scope:Global
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1280 Metric:1
RX packets:8838483 errors:0 dropped:0 overruns:0 frame:0
TX packets:14740931 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:1111686695 (1.0 GiB) TX bytes:17311790975 (16.1 GiB)

bond0 - это у меня Link Aggregation, была надежда слабая, свитч умеет с этим работать, но увы нет. Оставил для NFT. Теста ради включение, отключение не проявляет эффекта на проблему.

google писал(а):

Проверил на transmission 2.77-r1 и 2.88-r3 — всё работает. Возможно, проблема с неправильным значением MTU для IPv6-интерфейса. Попробуйте воспроизвести проблему и поймать трафик до трекера пакетным сниффером (например, wireshark или tcpdump).

Мысль интересная, правда схема подключения к интернету у меня не позволит это сделать напрямую (Роутер - Свитч - Nas). Попробую поднять на компьютере прокси и пустить через себя... Хотя тогда проблема по идее не проявит себя, т.к. на компьютере у меня настроен Teredo, в uTorrente кстати такой проблемы нет...

Update от 02.11.13:
Ради теста поставил Qt-Transmition Windows. Поведение один в один. Wireshark показал в режиме фильтра по Tcp соединениям к порту 2710 (tcp port 2710) подключения только по ipv4, хотя на компьютере настроено Teredo и другие приложения работают без каких либо проблем. Нет устанавливаются даже попытки соединения с ipv6 адресом, вот такая беда...

Цитата:

Мысль интересная, правда схема подключения к интернету у меня не позволит это сделать напрямую (Роутер - Свитч - Nas). Попробую поднять на компьютере прокси и пустить через себя... Хотя тогда проблема по идее не проявит себя, т.к. на компьютере у меня настроен Teredo, в uTorrente кстати такой проблемы нет...

Можно запустить tcpdump прямо на NAS, записать трафик в pcap-файл (tcpdump -n -w /tmp/dump.pcap 'port not 22 and port not 23'), а потом анализировать его на компьютере.

google писал(а):

Можно запустить tcpdump прямо на NAS, записать трафик в pcap-файл (tcpdump -n -w /tmp/dump.pcap 'port not 22 and port not 23'), а потом анализировать его на компьютере.

Спасибо, попробую чуть позже. Честно говоря не знал об этом. Кстати на текущий момент я перепробовал разные конфигурации
1. Прошил роутер OpenWrt - туннель и ipv6 раздавалось через него. Не помогло.
2. Переуставливал Transmission и даже сам DSM - ноль эффекта.
3. Перекомпилировал сборку Transmission из репозитория сообщества сам. Нихт.
Но сделал следующие выводы:
1. Независимо от способа получения ipv6 родная качалка с торрентов (DM Synology) работает, т.е. успешно получает данные с ipv6 адреса трекера.
2. Пинг и телнет тоже работает.
3. У меня есть смутное подозрение, что по-какой-то причине Transmission пытается получить DNS имя как адрес ipv4 собственно попытка не успешна, поэтому и проблема.
Причем проблема именно в моей конфигурации, я поднимал вопрос в репозитории. Там пока не могут ничего конкретно подсказать. Проблема кстати не с этим трекером, качая образ Убунты ситуация такая же (у них тоже два адреса трекера).
Upd 23.11.13:
Трафик я снял чуть модифицированной командой tcpdump -i any -n -w /volume1/public/dump.pcap 'port not 22 and port not 23'.
Честно говоря я тут совсем не спец. Банально фильтром tcp.port == 2710 увидел подключения, но только по ipv4.

Попробуйте посмотреть на DNS-запросы внутри дампа трафика (порт 53), transmission должен отправлять запросы с типом AAAA.

google писал(а):

Попробуйте посмотреть на DNS-запросы внутри дампа трафика (порт 53), transmission должен отправлять запросы с типом AAAA.

Попробовал. В этом вопросе моих знаний не хватает, но если я правильно понял в моем логе dns запрос идет только с типом A. Т.е. не было ни одной попытки получить адрес с типом АААА.

Сравнил с работой uTorrenta на компьютере, тут все логично, сначала попытка с типом А, затем успешная с АААА

Хм. Ради интересна делал срез одновременно с попыткой подключения telnet'ом к трекеру, тут все заработало правильно:

Чтобы не создавать новую тему, задам вопрос здесь, если можно.
На компе у меня uTorrent раздает, но есть еще и трансмишн в локалке на приставке Dune.
Часть скачанных с трекера файлов раздается с нее трансмишном в режиме 24/7
Вопрос. Учитывается ли аплоад только с uTorrenta, трансмишна, или же с обоих клиентов?

Schein2013 писал(а):

Вопрос. Учитывается ли аплоад только с uTorrenta, трансмишна, или же с обоих клиентов?

Учитывается весь отданный и скачанный трафик с каждого клиента по идее.

Тоже не буду создавать новую тему, но после запуска transmission на DNS-320 со статистикой раздач что-то не то, uTorrent показывает отданного на данный момент 141Гб, transmission - 83, в профиле - 114 всего, да и вчера по сравнению с обычным отданного упало вдвое с лишним. uTorrent стоит на компьютере и с DNS-320 находятся в локалке

Цитата:

Учитывается весь отданный и скачанный трафик с каждого клиента по идее.

Как раз по идее и смущает.

Цитата:

Учитывается весь отданный и скачанный трафик с каждого клиента!

У меня 6 клиентов (все uTorrent, но разные версии). Все учитываются.

war писал(а):

вчера по сравнению с обычным отданного упало вдвое

Вчера какое-то время трекер был не доступен - возможно с этим связано. Да и не стоит забывать, что вчера было 1-е января и не все даже сейчас в строю!

foralreg
Может быть и совпало так, посмотрим что дальше будет

И все таки сейчас статистика совпадает с uTorrent, то что раздает transmission - в статистике профиля нет, не может же ошибка быть в сотню с лишним гигов

war
А на раздачах котрорые раздаете Transmission в torrent activity учитывается отданное?

Да, только сейчас проверил здесь: http://nnmclub.to/forum/viewtopic.php?p=6221739
В uTorrent отдано 350 с копейками, в transmission 136, в профиле 347
Кстати, в transmission можно как-то выводить статистику за сутки, а не общую и за сессию?