Имеем:
1. DI-604 hw f1, f w 3.11 & 3.14
2. подключение через кабельного оператора.
IP адрес получаем по DHCP
задача - постройка тунеля (pptp) в другую сеть.
Суть проблем:
Получаем настройки по DHCP, строим тунель -все прекрасно все работает.
Проходит 30 минут - идет DHCP Renew, вот ту и выявляется проблема, по чемуто Dlink во первых - меняет ДНС сервера с тех
что получены от pptp сервера на те которые получены по DHCP
( как по мне так абсолютно нелогично) но ето можно пережить, вбивая их прямо на машине подключеной к длинку.
Основная проблема - по какойто причине начинают слатся пакеты с source pptp тунеля но мимо оного.
Похоже что кроме НС серверов меняется еще чтото.
очень хотелось бы что бы в случае DHCP Renew, при условии что не меняется IP которое раздается по нему, не производилось никаких изменений в конфигурации железки.

Возможно конечно проблема совсем в другом, в таком случае подскажите в какую сторону копать ?

Судя по сообщениям на форуме такоепроисходт не только уменя ( только люди обычно спихивают на то что инет перестает работать )
Как то всеже более детально продианостировать проблему можно ?
не весело каждых пол часа дергать железку.

Интересный провайдер, попробую сегодня собрать стенд и протестировать, о результатах отпишусь

_________________
С уважением,
Бигаров Руслан.

Провайдер просто расдает настройки по DHCP , тунель строится совсем в другую сеть.
Если нужні еще какието даные/действия скажите.

Протестировал на прошивке 3.14, все прекрасно работает: не теряет PPTP соединение и не получает левые DNS-ы.

_________________
С уважением,
Бигаров Руслан.

Тем немение факт более чем налицо, да и полистав форум можно найти людей описывающих подобную проблему.
Может все таке есть ситуации когда подобное безобразие возникает?
Вот пример tcpdump до ренью и после
далее на xxx.xxx.xxx.xxx - заменен IP адрес pptp серера
на yyy.yyy.yyy.yyy - заменен IP адрес тунеля ( выдается всегда один и тотже)
85.202.218.233 - адрес выдаваемый броадбанд оператором.

до ренью:
21:40:00.761943 IP xxx.xxx.xxx.xxx > 85.202.218.233: GREv1, call 0, seq 6, ack 5, length 24: CHAP, Success (0x03), id 40, Msg
21:40:00.762197 IP xxx.xxx.xxx.xxx > 85.202.218.233: GREv1, call 0, seq 7, ack 5, length 30: IPCP, Conf-Request (0x01), id 39, length 12
21:40:00.762501 IP 85.202.218.233 > xxx.xxx.xxx.xxx: GREv1, call 112, seq 6, ack 7, length 28: IPCP, Conf-Ack (0x02), id 39, length 12
21:40:00.762666 IP 85.202.218.233 > xxx.xxx.xxx.xxx: GREv1, call 112, seq 7, length 36: IPCP, Conf-Request (0x01), id 3, length 24
21:40:00.789116 IP xxx.xxx.xxx.xxx > 85.202.218.233: GREv1, call 0, seq 8, ack 7, length 42: IPCP, Conf-Nack (0x03), id 3, length 24
21:40:00.789775 IP 85.202.218.233 > xxx.xxx.xxx.xxx: GREv1, call 112, seq 8, ack 8, length 40: IPCP, Conf-Request (0x01), id 4, length 24
21:40:00.815889 IP xxx.xxx.xxx.xxx > 85.202.218.233: GREv1, call 0, seq 9, ack 8, length 42: IPCP, Conf-Ack (0x02), id 4, length 24
21:40:03.037050 IP 85.202.218.233 > xxx.xxx.xxx.xxx: GREv1, call 112, seq 9, ack 9, length 77: IP [|ip]
21:40:03.066583 IP xxx.xxx.xxx.xxx > 85.202.218.233: GREv1, call 0, seq 10, ack 9, length 173: IP [|ip]
21:40:03.067185 IP 85.202.218.233 > xxx.xxx.xxx.xxx: GREv1, call 112, seq 10, ack 10, length 94: IP [|ip]
21:40:03.300593 IP xxx.xxx.xxx.xxx > 85.202.218.233: GREv1, call 0, seq 11, ack 10, length 96: IP [|ip]
21:40:07.795215 IP xxx.xxx.xxx.xxx > 85.202.218.233: GREv1, call 0, seq 12, ack 10, length 60: IP [|ip]

теперь после:

22:10:26.686106 IP xxx.xxx.xxx.xxx > 85.202.218.233: GREv1, call 0, seq 23490, ack 13975, length 60: IP [|ip]
22:10:27.124630 IP xxx.xxx.xxx.xxx.1723 > 85.202.218.233.65535: . ack 364 win 3764
22:10:27.124959 IP 85.202.218.233.65535 > xxx.xxx.xxx.xxx.1723: . ack 221 win 5840
22:10:34.749211 IP 85.202.218.233 > xxx.xxx.xxx.xxx: GREv1, call 112, seq 13976, ack 23490, length 66: IP [|ip]
22:10:34.800758 IP xxx.xxx.xxx.xxx > 85.202.218.233: GREv1, call 0, seq 23491, ack 13976, length 68: IP [|ip]
22:10:34.801921 IP 85.202.218.233 > xxx.xxx.xxx.xxx: GREv1, call 112, seq 13977, ack 23491, length 58: IP [|ip]
22:10:34.802097 IP yyy.yyy.yyy.yyy.59743 > 212.42.64.8.80: P 1557759477:1557760062(585) ack 3113162853 win 65535
22:10:37.812986 IP yyy.yyy.yyy.yyy.59743 > 212.42.64.8.80: P 0:585(585) ack 1 win 65535
22:10:42.528982 arp who-has 85.202.218.233 tell 85.202.218.233
22:10:43.848274 IP yyy.yyy.yyy.yyy.59743 > 212.42.64.8.80: P 0:585(585) ack 1 win 65535

вопрос - почему же мимо тунеля?

Касательно ДНС серверов - то чно заменяются ето впринципе не беда, ето всего лиш указание на глюк.
Не должны ДНС менятся с тех что пришли с pptp сервера на DHCP
что интересно - с етой же партии dlink( разом)
но используемый как pptp+static ip, причем pptp сервер тотже естествено никаких проблем невызвал - даже с родной прогивкой (3.11)

Очень похожая ситуация:
DI-604, поключает 2 рабочих станции к интернету по районной сети. Интернет - через PPTP с динамическим IP адресом. И держится это PPTP соединение ровно час, после чего связь пропадает. На страницу маршрутизатора, disconnect/connect и работаем дальше (ещё час) Провайдер говорит "У нас всё нормально", и похоже у них действительно всё нормально, ибо до появления марштутизатора всё работало нормально...

прошивка 3.14 ревизия F1

Та же проблема, что у вышевысказавшихся.

Я - администратор сети кабельного провайдера, и мы хотели предлагать клиентам DI-604 в качестве решения для доступа в интернет из локальной сети небольших организаций.
Однако при нашей конфигурации - существует как раз эта самая проблема.

Конфигурация такая:
IP адреса внутри провайдерской сети раздаются по DHCP, обновление - раз в 5 минут.
Доступ в интернет - с использованием PPTP или L2TP.

После настройки WAN и перезагрузки - доступ из-за роутера в интернет есть ровно пять минут, как раз до обновления IP-адреса.

Прошивка 3.14, H/W ver F1

Нашелся конечно вариант: установить в настройках L2TP "Connect on demand", и таймаут поменьше - 1 минуту. Тогда соединение сбрасывается при неактивности и, в следующий раз восстанавливаясь, позволяет ходить в интернет. Но решение это не очень-то хорошее.

up!
(господа техподдерка, ну скажите хоть что нибудь!)

Кстати если интересно - выяснил коечто.
1. у меня next server для DHCP находится в другом сегменте.
2. используя снифер удалось выловить что общение с DHCp сервером происходит не с IP которое выдалось по DHCP а с IP тунеля, точнее оно через раз.

Вопрос к тех поддержке- может вам подкинуть логфайл снятый
ethereal?
Может хоть какаято польза будет ...

Вопрос к Супорту.
Уважаемые может хоть голос подадите?
Все же хочется довести раследования сбоя в работе девайса до логическо и положительного конца.

Если не трудно -- киньте мне на почту езериловский лог и еще разик описание проблемы и конфигурации. Надо проверить детально что у вас происходит.

_________________
С уважением -- Александр Шебаронин.

Письмо отписал в суботу вечером, на деюсь хоть чтото станет понятно.

Всего лишь хотел поитересоватся у технической поддержки - какието предварительные выводы по проблеме есть?

И так уже вторая неделя идет, можно хотябы узнать, проблему хотябы выловить удалось?