прочитал в конф. про маету с беспричинным падением 600
И понял проблема то глобальная. У самого за 2 недели 2 шт упали. Фактически друг за другом. стояли у разных клиентов. Работали в совершенно разных условиях и режимах. Были поставлены примерно в одно и тоже время летом 2005. А вот грохнулись на днях. Один отправили в СЦ.
А вот со вторым решил немного повозиться. И интересную вещь открыл. Пробывал ли кто нибудь из пострадавших промониторить убитый DFL600, например, Ethereal`ом или tcpdump`ом по Lan`овским портам? Если нет, то попробуйте - откроете для себя нечто новое. Сделать нужно немного - подключите DFL к порту сетевой карты. Стартаните анализатор, включите питание DFL и увидите через некоторое время идущие от него, родимого, пакетики
типа TFTP: Read Request, File: dfl600image, Transfer type: OCTET
с соответсвующими адресами и портами. Далее дело техники: настриваем адаптер на DFLовский запрос, подымаем TFTP сервер, предварительно положив туда переименованный FW (например 3.35),
и 600 сразу же начнет его кушать. Проблема заключается в том, что эта ненасытная тварь никак не останавливается, т.е доходит до конца файла и начинает по новой. Сдается мне, что здесь, есть некая фенечка (например, некий сервисный image). Ведь зачем-то заложили ребята возможность загрузки, на практически убитом устройстве. Нечто подобное делают молодцы из NSG со своими маршрутизаторами (да и не только они) - можно зайти в специальный монитор, который загружается из ПЗУ (фиг чем собъешь) и далее по TFTP подгружаешь новый образ в замен убитого. Ну почти как у DFL600

В связи с этим у меня есть несколько вопросов к Support:
1. Что это за недокументированная возможность?
2. Если таким способ сервис восстанавливает прошивки, то почему бы не выложить правильный image на ftp или это их хлебушек с маслицем?
По поводу возражений, что это глюк убитой операционки - не принимается, по статистике не может быть абсолютно одинаковой ситуации у трех "убитых" устройств.