Доброго времени суток.

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

DSL-504T с прошивкой V1.00B02T02.RU.20041014
Модем используется в качестве маршрутизатора.
DHCP отключен.

На компьютере установлен Linux Debian
В качестве нэймсервера стоит 192.168.1.1 (адрес 504T-ого)

Пытаюсь коннектиться по ssh на внешний сервер. Ничего не получается. Запускаю ssh с -v опцией и вижу, что соединиться он пытается с адресом 1.0.0.0, а вовсе не с тем адресом, который нужен. Логично подумать проблема с ДНС. Хорошо... Пингую тот же сервер по имени. И он пингуется! Делая "host" по имени - ip адрес распознается правильно!

Кстати, в логах модема видно, что со своей стороны DNS сервера он получает автоматически от провайдера. В конфиге DNS указано использовать автоматически полученные DNS сервера.

Да, еще надо заметить, что браузер нормально работает с именами. Не работает ssh, pop3, apt-get. Дальше все интереснее... Пингую сервер, потом пытаюсь соединиться по ssh - и получается! Видимо скэшировалось...

Смотрю tcpdump, что происходит, при первом соединении с ssh (когда не работает):

предположим tmp.ru - адрес внешнего сервера
предположим 193.193.193.193 - его реальный IP

23:48:35.870028 IP (tos 0x0, ttl 64, id 33743, offset 0, flags [DF], length: 52) 192.168.1.3.32777 > 192.168.1.1.53: [udp sum ok] 14313+ AAAA? tmp.ru. (24)
23:48:35.901208 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 96) 192.168.1.1.53 > 192.168.1.3.32777: 14313 q: AAAA? tmp.ru. 0/1/0 ns: tmp.ru. SOA[|domain]
23:48:35.901435 IP (tos 0x0, ttl 64, id 33746, offset 0, flags [DF], length: 52) 192.168.1.3.32777 > 192.168.1.1.53: [udp sum ok] 14314+ AAAA? tmp.ru. (24)
23:48:35.903736 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 52) 192.168.1.1.53 > 192.168.1.3.32777: [udp sum ok] 14314- q: AAAA? tmp.ru. 1/0/0 [|domain]
23:48:35.904095 IP (tos 0x0, ttl 64, id 33746, offset 0, flags [DF], length: 52) 192.168.1.3.32777 > 192.168.1.1.53: [udp sum ok] 14315+ A? tmp.ru. (24)
23:48:35.905513 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 68) 192.168.1.1.53 > 192.168.1.3.32777: [udp sum ok] 14315- q: A? tmp.ru. 1/0/0 tmp.ru. A 1.0.0.0 (40)

т.е. видно, что реально модем возващает в качестве ip-адреса некое странное число 1.0.0.0
Откуда оно вообще берется.

Далее пингую:
ping tmp.ru

00:18:53.689860 IP (tos 0x0, ttl 64, id 18887, offset 0, flags [DF], length: 52) 192.168.1.3.32777 > 192.168.1.1.53: [udp sum ok] 3114+ A? tmp.ru. (24)
00:18:53.729459 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 380) 192.168.1.1.53 > 192.168.1.3.32777: 3114 q: A? tmp.ru. 1/7/8 tmp.ru. A 193.193.193.193 ns: ru. NS[|domain]

Вот это да... С первого раза все нормально распознал. В чем разница? Видно, что нету запроса "AAAA?". Что это такое - я толком не понял. В манах tcpdump не нашел. Но судя по ответам серверов (пробовал на разных машинах) это что-то вроде запроса на разные DNS записи. Мне отвечали CNAME, NS и т.д. Кто-нибудь знает точно, что это значит?
Интересно, что при запуске ssh, у меня на Debian - этот запрос есть. На Fedore2 тоже есть. А вот на AltLinux этого запроса не было вовсе. Наеврное это какие-то внутренние настройки resolv. Но какие именно - я пока не понял.

Итак, после этого опять делаю ssh. И вижу:

00:05:57.541710 IP (tos 0x0, ttl 64, id 6821, offset 0, flags [DF], length: 52) 192.168.1.3.32777 > 192.168.1.1.53: [udp sum ok] 13921+ AAAA? tmp.ru. (24)
00:05:57.543209 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 52) 192.168.1.1.53 > 192.168.1.3.32777: [udp sum ok] 13921- q: AAAA? tmp.ru. 1/0/0 [|domain]
00:05:57.543381 IP (tos 0x0, ttl 64, id 6821, offset 0, flags [DF], length: 52) 192.168.1.3.32777 > 192.168.1.1.53: [udp sum ok] 13922+ A? tmp.ru. (24)
00:05:57.544714 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 68) 192.168.1.1.53 > 192.168.1.3.32777: [udp sum ok] 13922- q: A? tmp.ru. 1/0/0 tmp.ru. A 193.193.193.193 (40)

Теперь все работает нормально. Но не долго, к сожалению.
С чем может быть связана такая проблема? Я, в общем, не могу уверенно грешить на 504T, может это у меня с настройками что-то не так (не исключено ). Если есть мысли - ответьте пожалуйста.

Сразу скажу, что досконально Вашу проблему я не изучил, но очень похоже на то, что часть Вашего программного обеспечения пытается работать по ipv6.
Для меня заработало следующее:
alias net-pf-10 off
alias ipv6 off
в файле /etc/modprobe.conf

Проверил
IPV6 на системе нет вовсе
IPV6 траффик не ходит (проверено tcpdump)
На 504T (со стандартной прошивкой) вроде ipv6 тоже нет, да?
Короче, в чем то другом проблема.
А жаль %) Так бы все просто решилось...

Извиняюсь.
Действительно связано с IPv6.
Как починить - пока не знаю, так как в ядре действительно IPv6 нет. Значит какие-то сервисы без спроса сами шлют AAAA запросы.

для гномовских и кде-приложений были какие-то переменные среды, отменяющие использование ipv6, но, к сожалению, не помню, какие точно.
попробуйте сделать grep по /etc - может, что-то, связанное с ipv6 и обнаружится...

К сожалению мало времени поковыряться с этим всем...

До графических приложений дело толком и не доходит. Не проходит простой ssh. Первое что удалось выяснить:

если в resolv.conf поставить в качестве nameserver-а сторонний сервер, то все работает нормально, хотя AAAA? запросы ходят.

если в resolv.conf поставить в качестве nameserver-а DNSсервер, который 504T получил автоматически, то все тоже работает нормально.

если поставить в resolv.conf 192.168.1.1 (адрес 504T), то после AAAA? на обычный запрос A? сервер отвечает странным адресом 1.0.0.0

Ничего уверенно сказать нельзя, но наводит на мысль, что обычно DNS-сервера умеют отвечать правильно, а встроенный в 504T DNS-сервер, в той же ситуации, неправильно себя ведет. Хотелось бы обратить на это внимание разработчиков прошивки. Может получиться, что это исключительно мои кривые ручки %), а может быть и ошибка...

Почитав про эти AAAA? запросы, используемые для туннелирования ipv4 и ipv6, понятно, что в ipv4 сети их генерация - не совсем нормальная вещь (не нужны они), но тем не менее стандартные (т.е. никакие специфические изменения не вносились) дистрибутивы Debian и Fedora 2 по умолчанию их генерят. Соответственно у них могут быть проблемы при использовании 504T.

Второе, что выяснил - оказывается в resolv.conf можно указать хитрую опцию
options inet6
Включение этой опции приводит как раз к такому поведению, как у меня. Т.е. сначала шлются AAAA?, а потом, в случае неудачи A?.
Так вот видимо опция включена по умолчанию. Включить ее просто, а вот как выключить -вопрос %). Библиотека libresolv, которая собственно занимается распознаванием ip-адреса по имени, входит в пакет glibc. Странно, если такое поведения resolver-а по-умолчанию установлено в glibc и что его нельзя изменить с помощью конфигов. Так что завтра попытаюсь порыться в исходниках resolv-а. Может что там найду.

У меня такое происходило со всем трафиком(1.0.0.0), ни в какую не хотел получать ДНС с 500Т. Прописывал ДНСы стрима руками в настройках сетевого соединения. Прибил IP6 (причём оно отключено было) в соединение всё заработало.

Есть такая функция в линуксе getaddrinfo(). Она производит разные действия, в том числе посылает запрос (с помощью функций более низкого уровня) к ДНС-серверу. Среди аргументов getaddrinfo() есть поле, которое определяет какое семейство протоколов использовать. Возможные значения:
AF_INET - использовать IPv4
AF_INET6 - использовать IPv6
PF_UNSPEC - семейство не определено
Вот этот PF_UNSPEC расшифровывается функцией getaddrinfo() так, что сначала надо послать IPv6 запрос, а потом IPv4 запрос.

(Кстати смотрел пакет bind, содержащий утилиты host и dig, которые не посылают AAAA?. Так вот нашел там комментарий, в котором выражается недовольство таким поведением функции getaddrinfo(). Из за этого пишется своя реализация, практически дублирующая реализацию из glibc).

Так вот... по умолчанию ssh использует PF_UNSPEC при вызове getaddrinfo(). В принципе, при запуске ssh-клиента, можно в явном виде указать опцию "-4", тогда все будет ок, или при сборке пакета также можно указать семейство IPv4 по умолчанию. Однако если это явно не указать, то скрипт configure желает по умолчанию включить IPv6 IPv4 map, т.е. установить PF_UNSPEC - пробовать и IPv6 и IPv4.

Кроме ssh, который в крайнем случае можно пересобрать, функцию getaddrinfo() с параметром PF_UNSPEC используют и другие программы. Так что проблема достаточно глубокая.

Несостыковки линукса с 504T (а оказывается и с 500Т) можно считать багой реализации resolv под линух, можно считать недочетом прошивки модема. Но тем не менее стандартные, распространенные дистрибутивы линукса плохо уживаются со встроенным ДНС-ом модема. Может проще научить модем правильно реагировать на "AAAA?"?. По-идее, он же просто форвардирует запросы другим ДНС-серверам (полученным автоматически или прописанным пользователем).

Народ, модераторы, обратите внимание на эту проблему. Как оказалось, она возникает не только у меня.

Никакой реакции со стороны технической поддержки так и не будет?

тудаже! модем 504Т. Кода будет исправлен этот фитч с ипв6?

А чем Вас DNS провайдера не устраивает? Модемные DNS и DHCP я убил бы первым делом!

провайдер может поменять DNS. Модем их получат по DHCP - они всегда атуальные. Компьютеры не могут их получить от провайдера по DHCP. Если конечно не использовать коронный workaround техподдержки ДЛинк - перевести роутер в бридж

А чё тут такого? Я не из D-Lnik, но всё равно скоро выделю на работе комп под шлюз и переведу роутер в бридж.
К тому же в моём селении своя специфика - входящий трафик платный.