Тайм-аут соединений IPv6

У меня проблемы с подключениями IPv6. Только с теми. Они тайм-аут примерно каждые 10 минут (из-за обновления адреса, я полагаю).

Случается с каждым дебианским вкусом Linux, который я пробовал через год или около того, x86 и x64, на разных ПК, проводных и беспроводных.

В настоящее время я использую Linux Mint 17.1 с ядром 3.13.0-37-generic x86_64 (ранее 3.2.0-60) и NetworkManager 0.9.8.8. Иногда, когда я пытаюсь немедленно перезагрузить загрузку, я получаю «никакого маршрута к хосту». потому что мои IPv6-адреса, похоже, на мгновение исчезли.
Вот так: http://pastebin.com/4Xida2qu

Я запускаю двойной стек IPv4 – IPv6 (PPPoE), так настроен мой маршрутизатор Netgear DGND3700v2 (версия прошивки V1.1.00.22_1.00.22): http://i.imgur.com/YgxAyQb.png

Сетевой профиль, о котором идет речь, настроен на игнорирование IPv6, но я все равно получаю глобальные адреса IPv6. Переход на авто не имеет никакого значения. Это запутанно, но я думаю, что это просто ядро, выполняющее свою работу.

Правила брандмауэра или их отсутствие не имеют никакого значения, но в основном это:

iptables -P INPUT DROP ip6tables -P INPUT DROP iptables -P FORWARD DROP ip6tables -P FORWARD DROP iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT ip6tables -A INPUT -i lo -j ACCEPT ip6tables -A OUTPUT -o lo -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT ip6tables -I INPUT -p icmpv6 -j ACCEPT 

Пробовал использовать DHCP вместо autoconf для локальной сети, теперь я не получаю таймаутов в окнах, но нет подключения ipv6 в Linux (хотя у меня, похоже, есть глобальный адрес, но я все равно получаю «недостижимые сети»).

Соответствующие части tcpdump -vvni wlan0 icmp6

Место назначения недоступно:

 19:25:05.381081 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 88) {GW's ipv6 - redacted} > {My pc's ipv6 link-local addr - redacted}: [icmp6 sum ok] ICMP6, destination unreachable, beyond scope 2001:760:ffff:b1::34, source address {My pc's ipv6 link-local addr - redacted} 19:25:12.948944 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 88) {GW's ipv6 - redacted} > {My pc's ipv6 link-local addr - redacted}: [icmp6 sum ok] ICMP6, destination unreachable, beyond scope 2001:760:ffff:b1::34, source address {My pc's ipv6 link-local addr - redacted} 19:25:18.446900 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 88) {GW's ipv6 - redacted} > {My pc's ipv6 link-local addr - redacted}: [icmp6 sum ok] ICMP6, destination unreachable, beyond scope 2001:760:ffff:b1::34, source address {My pc's ipv6 link-local addr - redacted} 

Требование маршрутизатора:

 19:25:18.775794 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) {Unknown link-local ipv6 addr - redacted} > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16 source link-address option (1), length 8 (1): {Unknown MAC - redacted} 0x0000: {Unknown MAC - redacted} 

Реклама маршрутизатора:

 19:25:18.777825 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 112) {GW's ipv6 - redacted} > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 112 hop limit 64, Flags [other stateful], pref medium, router lifetime 1800s, reachable time 30000s, retrans time 1000s prefix info option (3), length 32 (4): 2a01:2000:2001:91b1::/64, Flags [onlink, auto], valid time 360s, pref. time 360s 0x0000: 40c0 0000 0168 0000 0168 0000 0000 2a01 0x0010: 2000 2001 91b1 0000 0000 0000 0000 unknown option (24), length 24 (3): 0x0000: 4000 0000 0168 2a01 2000 2001 91b1 0000 0x0010: 0000 0000 0000 rdnss option (25), length 24 (3): lifetime 600s, addr: 2a01:2000:2001:91b1:861b:{Gateway} 0x0000: 8800 0000 0258 2a01 2000 2001 91b1 861b 0x0010: {gateway MAC - redacted} mtu option (5), length 8 (1): 1492 0x0000: 0000 0000 05d4 source link-address option (1), length 8 (1): {gateway MAC - redacted} 0x0000: {gateway MAC - redacted} 

Время от времени я получаю что-то подобное, не знаю, имеет ли это значение:

 17:09:42.546840 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1240) {GW's ipv6 - redacted} > {My pc's temp ipv6 addr - redacted}: [icmp6 sum ok] ICMP6, packet too big, mtu 1462 

Radvd.conf маршрутизатора (найденный с помощью telnet)

 interface group1 { AdvSendAdvert on; AdvManagedFlag off; AdvOtherConfigFlag on; MaxRtrAdvInterval 600; MinRtrAdvInterval 198; AdvSourceLLAddress on; AdvReachableTime 30000; AdvRetransTimer 1000; AdvDefaultLifetime 1800; AdvCurHopLimit 64; AdvLinkMTU 1492; prefix 2a01:2000:2001:cd96::/64 { AdvPreferredLifetime 360; AdvValidLifetime 360; AdvOnLink on; AdvAutonomous on; }; route 2a01:2000:2001:cd96::/64 { AdvRouteLifetime 360; }; RDNSS 2a01:2000:2001:cd96:XXXX:XXXX:XXXX:XXXX { AdvRDNSSOpen on; }; }; 

  • Ручная настройка сетевых интерфейсов на Cubieboard
  • Дисплей и сетевая карта не работают при загрузке без дисплея
  • Скрипт для перезапуска сети
  • Как я могу вручную сбросить счетчики RX / TX в выход ifconfig без влияния на доставку данных?
  • Проблема с конфигурацией сервера шлюза в Centos 7
  • Где хранится таблица маршрутизации, хранящаяся внутри ядра Linux?
  • Как выполнить udhcpc как не root
  • Как настроить Wi-Fi-точку доступа в режиме 802.11n?
  • 2 Solutions collect form web for “Тайм-аут соединений IPv6”

    При автоматической настройке адресов IPv6

    В настоящее время автоматическая настройка IPv6 (в общем) всегда основана на обнаружении маршрутизатора на основе обмена пакетами ICMPv6. Основная идея – получить информацию о сети от маршрутизатора к клиенту. Как только клиент получит рекламу маршрутизатора с информацией, он также узнает, следует ли использовать DHCP и, особенно, использовать ли его только для другой конфигурации или также для настройки адреса. Конкретные конфигурации, протестированные с помощью NetworkManager, описаны в вики Fedora .

    Настройка IPv6 с помощью NetworkManager

    Начиная с NetworkManager 0.9.6 поддержка IPv6 в NetworkManager в основном используется, но в значительной степени зависит от ограниченных возможностей автоконфигурации ядра. Поскольку NetworkManager 0.9.10, конфигурация IPv6 полностью управляется пользовательским пространством, а ядро ​​настраивается таким образом, что это работает намного лучше. Текущая ветвь NetworkManager – 1.0.

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

    Конфигурация соединения

    / И т.д. / NetworkManager / система-соединение /:

     [ipv6] method=auto 

    Вы не должны использовать method=ignore если ожидаете, что ваши подключения IPv6 будут работать правильно. В то время как игнорирование допускает ограниченную конфигурацию IPv6 на базе ядра без DNS и тому подобное, предпочтительный способ – позволить NetworkManager обрабатывать конфигурацию IPv6. Мы действительно надеемся удалить игнорирование в будущем. Существуют также [известные ошибки] [1] в стандартах автоконфигурации IPv6, которые NetworkManager пытается обойти, когда method=auto .

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

    Для простого тестирования сделайте разрешенный брандмауэр:

     ip6tables -P INPUT ACCEPT ip6tables -F INPUT ip6tables -P OUTPUT ACCEPT ip6tables -F OUTPUT 

    Убедитесь, что вы не используете расширения конфиденциальности

    В прошлом были проблемы с расширениями конфиденциальности (также называемыми временными адресами). Вы используете Linux Mint, который является одним из дистрибутивов, которые по умолчанию включают их.

    Примечание. Проблема, которую вы получаете, связана не с расширением конфиденциальности. Вероятно, вы можете пропустить этот раздел, но я хотел бы оставить его для всех, кто может отлаживать еще одну проблему с похожими симптомами.

    /etc/sysctl.conf:

     net.ipv6.conf.default.use_tempaddr = 0 

    Обычно вы просто используете все insetad по умолчанию, но NetworkManager читает файл и ищет по умолчанию . Этого параметра должно быть достаточно, чтобы убедить NetworkManager, что мы не хотим использовать расширения конфиденциальности для любых подключений. NetworkManager теперь должен игнорировать конфигурацию конфиденциальности для каждого подключения. После этого перезапустите NetworkManager.

    Маршрутизатор и запрос на рекламу

    Из вашего обновленного вопроса я вижу, что, когда Networkmanager отправляет запрос на маршрутизатор, маршрутизатор немедленно отвечает рекламой маршрутизатора, что является хорошим поведением с точки зрения вашего хоста, поскольку вы получаете необходимую информацию. Вопрос в том, всегда ли это происходит.

    Также маршрутизатор должен регулярно отправлять рекламные ролики маршрутизатора, чаще, чем время ожидания адресов. И ваш хост должен, вероятно, отправлять запросы маршрутизатора, когда время ожидания приближается, на всякий случай, если вы пропустили информацию с маршрутизатора. С вашей версией NetworkManager ответственность за это будет зависеть от ядра.

    Из другого обновления ясно, что маршрутизатор не отправляет рекламу маршрутизатора так часто, как должен . Действительность некоторой информации составляет всего 360 секунд, но частота рекламных роутеров составляет до 600 секунд . Правильная конфигурация будет заключаться в том, чтобы доставить вам пару рекламных роутеров в течение 360 секунд на случай, если некоторые из них потеряются.

    С другой стороны, ваш хост должен, вероятно, запросить информацию через приглашение маршрутизатора, когда срок службы истечет . Вы можете следить за заявлениями и объявлениями с помощью tcpdump, чтобы узнать, отправляет ли ваше ядро ​​запрос в течение примерно шести минут от последних рекламных объявлений. Если это не так, вероятным признаком является то, что ваше соединение будет длиться только шесть минут от последнего объявления, что означает шесть или более минут с момента установления соединения.

    Рекомендуемая конфигурация маршрутизатора

    Стандарты, похоже, рекомендуют некоторые ценности, но я скорее использую здравый смысл. На очень плохих ссылках (что относится к Wi-Fi и другим) вы можете потерять несколько пакетов. Таким образом, я бы в основном сохранял все жизненные ситуации, по крайней мере, на хороших кратных максимальном рекламном интервале маршрутизатора.

    Ваш MaxRtrAdvInterval – это 600 секунд, и это круто, так как вы будете получать обновленную информацию каждые десять минут или меньше. Единственная цель MinRtrAdvInterval – рандомизировать время, так что вы можете сохранить его или использовать 300 секунд, например. Все времена жизни можно было бы изменить, например, в пять раз больше максимального интервала, что означало бы 3600 секунд, что означало бы, что вся информация будет действительна в течение часа, но обновляется примерно каждые десять минут.

    Итоговые заметки

    Вы можете обратиться к поставщику, чтобы установить время на своих машинах. Я не знаю, настраивается ли он. Но изменение файла напрямую, вероятно, не поможет вам, так как маршрутизатор перепишет его при выполнении конфигурации.

    Вы также можете связаться с разработчиками сетей ядра, чтобы прокомментировать отправку запроса маршрутизатора. Не стесняйтесь включать меня в любое сообщение.

    Это звучит как проблема MTU. Заголовки IPv6 больше, чем IPv4, и вы используете PPPoE. Сделайте ifconfig чтобы получить MTU. Возьмите это число и вычтите 48 байт. Ping с уменьшением размеров пакетов, начиная с этого числа, с установленным битом df (не фрагментируйте):

    ping6 [2001:760:ffff:b1::34] -M do -s [MTU-48]

    Linux и Unix - лучшая ОС в мире.