Хочется узнать, будет ли какое-нибудь изменение в ситуации с файрволлом? Вернее с тем, что он не отслеживает живость своего PPTP соединения.
Собственно проблема в том, что при временной потере связи сессия на сервере завершается, тогда как DFL-700,стоящий в качестве клиента, даже не подозревает об этом, и не предпринимает никаких попыток к восстановлению потерянного соединения.
Моделируем ситуацию:
DFL-700 настраиваем на соединение через PPTP(можно к такому-же DFL-700)
после перезагрузки все у нас в порядке. Пакетики бегают. Теперь в административном порядке на серверной стороне говорим сбросить того клиента.
Нормальная железка пытается через какое-то время(зачастую настраиваемое) восстановить погибшее соединение. Только не наш DFL-700. Ждать можно долго(лично я ждал около 3 часов ради эксперимента)

Надеюсь всетаки хотя-бы на какие-нибудь комментарии.
ЗЫ.
Версия прошивки DFL-700 1.3.00.

А в ответ тишина....... Мож всетаки поставите эксперимент.... Или какой-нибудь вопрос зададите наводящий? Я конечно понимаю, что всвязи с недоработанностью софта на оборудовании D-link Вопросов у пользователей возникает много, даже чересчур. Но вы-ж на то и служба поддержки, чтобы хотя-бы как-нибудь реагировать, а не отмалчиваться..... Ямогу сказать только одно, что отныне буду агрессивно сопротивляться идее приобретения оборудования D-Link хоть сколько-нибудь более сложного чем DI-804. Который, надо сказать: тоже нуждается в доработке, а именно в установке элемента принудительного охлаждения. Ибо греется он всетаки прилично. Боюсь что летом я с ними хлебну по полной.

Эксперимент поставим. Будут результаты -- сообщим.

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

Вот что происходит после прибития ППТП-сервера, обслуживающего DFL-700:
[2005-02-24 14:55:45] <5>EFW: PPTP: event=pptp_session_request remotegw=192.168.100.25

[2005-02-24 14:55:45] <5>EFW: PPTP: event=pptp_tunnel_up iface=WAN, remotegw=192.168.100.25

[2005-02-24 14:55:45] <5>EFW: PPTP: event=pptpclient_connected iface=WAN, remotegw=192.168.100.25

[2005-02-24 14:55:45] <5>EFW: PPTP: event=pptpclient_start iface=WAN, remotegw=192.168.100.25

[2005-02-24 14:55:43] <5>EFW: PPTP: event=pptp_tunnel_closed iface=WAN, remotegw=192.168.100.25

[2005-02-24 14:55:43] <5>EFW: PPTP: event=pptp_session_closed iface=WAN, remotegw=192.168.100.25, callid=0

То есть ППТП тут же сразу поднимается обратно. Расскажите поподробнее как сэмулировать вашу ситуацию.

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

Пока не смогу показать логи, потому что сдох сам объект.. Вернее его блок питания, и как-то так хитро подпалил файрволл, что эти туннели перестали подниматься совсем. перегрев исключался, потому как условия просто идеальные.
Но ситуация была такова:
Соединение формировалось на WAN-PPTP То есть было желание сделать WAN портом - туннель. Это, как я вижу Вы воспроизвели. Соединение поднялось. Далее я начал экспериментировать с аварией соединения. То есть отключать Ethernet порт, нарушать маршрут, и так далее(хочу оговориться,PPTP сервер находится с файрволлом не в одном сегменте сети. то есть допустим, что WAN-PHYS адрес нашего подопытного - 192.168.0.1 - WAN-PHYS шлюз 192.168.0.2 маска 255.255.255.252 тогда как сервер имеет адрес 192.168.30.1 ) обрываю чего нибудь посередине - на сервере сессия падает( сервером кстати выступал такой-же DFL - не жалуюсь) А вот клиентская сторона стояла как ни в чем не бывало. Через туннель ничего не ходило, и попытки пересоединиться я так и не дождался.
Были конечно еще мелкие грабельки... например сетку свернуть на WAN-PHYS не удалось. То есть прописать ее туда можно, тока ходит она почему-то через туннель..... Остальное по мелочи, как железка с ремонта вернется - обновлю впечатления.

Ага. Спасибо, стало понятнее. Буду пробовать. И сетку на WAN-PHYS завернуть это как? То есть она там есть непосредственно, а вот инет за ППТП?

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

До подыхания DFL отображал WAN-PHYS в списке интерфейсов при добавлении маршрута. И позволял добавить маршрут к какой-либо сети через шлюз WAN-PHYS

всплыл аналогичный глюк на роутере DI-804HV
не восстановилось не только PPTP соединение но и пропал пинг к WAN_PHYS шлюзу, при физическом отключении Ethernet от WAN порта на некоторое время. То есть PPTP сессия оказаласть разорваной, но восстановиться она не смогла по причине падения WAN порта, Причем отмечено, со стороны мира виден MAC адрес рутера DI-804HV, но на пинг он не отвечает, ИМХО софтверный глюк.
Проявляется глюк следующим образом: понадобилось перезагрузить шлюз к которому подцеплен DI-804HV. Перезагружается это чудо весьма медленно, бутилось наверное минут 5, с несколькими подьемами и падениями ETH. После того, как оно запустилось, DI-804HV немедленно появился в его arp таблице. Но туннеля не поднял. Я попытался его попинговать - ответа не последовало. Я пропинговал адрес шлюза - всё в порядке. Попробовал ткнуться в TCP 8080 - результат нулевой. (как Вы понимаете, находился я на порядочном расстоянии от роутера, и доступа к его лану не имел) на мою удачу, там оказался человек, способный заглянуть на шлюз, и воспользрваться теми средствами диагностики, что там есть. Со шлюза пинг в WAN интерфейс не шел. В общем в результате вылечили железку ребутом.
Вторая ситуация произошла при мне. Я одновременно включил и шлюз и DI-804.
Естественно DI-804 загрузился раньше. Но вот после того, как прогрузился-таки шлюз - DI-804 его уже пингать не захотел. Положение было таким-же как я описывал ранее: то есть DI-804 присутствовал только в ARP шлюза, но никаких ответов от него не было Естественно ни о каких туннелях в такой ситуации речи идти не может.
Конструкция подключения - аналогичная конструкции описанной ранее.
Firmware Version: V1.40b04, Wed, Oct 06 2004