Столкнулся с широко известной проблемой -- VPN-клиенту нужен маршрут на подсеть внутренней сети, а гнать через VPN-канал доступ в Интернет неприемлимо. Обычно, в этой ситуации предлагают route add (ручками или через bat-файл), дескать Винда автоматически брать маршрут не может, но я-то знаю -- может и решил попробовать решить эту задачу на DFL-800.
DHCP на DFL настроил быстро, правда ухитрился поначалу вогнать бедную железку в ступор (вышла только по watchdog'у), задав для DHCP пул адресов 0.0.0.0/0. Пришлось вводить более реальное значение, хотя пул в данной ситуации не нужен -- адреса раздает PPP. Опция 249 явно не поддерживается, пришлось кодировать побайтно, тип UINT8ARRAY.
Результат -- на XP работает, на семерке -- нет. И проблема вовсе не в опции 249. Опция 15 -- Domain Name, очень удобная для отладки DHCP (если срабатывает, результат виден по ipconfig /all в поле "DNS суффикс подключения") также не работает в Windows 7, даже если 249 убрать.
Исследование сниффером показало, что ответ от DFL приходит в обеих случаях, а также выявило вероятную причину того, что семерка его игнорирует. На XP в запросе: htype=8 (HyperChannel), hlen=6, haddr=какая-то имитация MAC. В ответе htype=1 (Ethernet), hlen=6, haddr=сохранено из запроса. На семерке в запросе: htype=8 (HyperChannel), hlen=0, haddr=нули. В ответе htype=1 (Ethernet), hlen=6, haddr=нули. Не знаю, насколько правильно для PPP выдавать htype=8, но в любом случае все эти три параметра -- идентификация клиента, которую сервер должен вернуть без изменений, ведь он именно этому клиенту отвечает. DFL же сохраняет только MAC-адрес, а htype и hlen устанавливает в предположении, что DHCP будет использоваться только для Ethernet.
Уважаемые сотрудники техподдержки D-Link! Может можно довести до разработчиков? При наличии исходников исправить никакого труда не составит. Функция ведь востребована, а не работает из-за одного-двух неверных байтов.
|