Cisco IOS recovery by tftp

Поведаю вам, друзья мои, занятную сказку. С детективным сюжетом и хорошим концом.
Добрые побили злых, но так и не поняли, почему они злые, как-то так...

Столкнулся со странной проблемой, пытаясь восстановить стертый образ IOS.
Дано: поциент - Cisco 1841
tftp-сервер - обычный tftpd на Ubuntu Linux 9.10
в корне tftp-сервера лежит образ IOS. Подключаюсь к поциенту консольным кабелем c  admin-station,  первый ethernet-порт роутера (в моем случае Fa 0/0) включаю напрямую кросс-кабелем  в сетевую карту станции,на которой Ubuntu+tftpd.
Задаю сетевой карте IP 192.168.1.1/24, включаю роутер и загружаюсь в ROMMON.
При попытке выполнить команду tftpdnld получаю -
ARP: address resolution for 192.168.1.1 timed out.
ARP failed with failure code 1.  TFTP transfer aborted.
При этом машина с tftp-сервером прекрасно видит arp-запросы в tcpdump. Но ответа на них не дает. Совсем. Никак.


Установка конфигурации
IP_ADDRESS=192.168.1.2
IP_SUBNET_MASK=255.255.255.0
DEFAULT_GATEWAY=192.168.1.1
TFTP_SERVER=192.168.1.1
TFTP_FILE=c1841-xxxxxx.bin
Гугление в попытках решить проблему приводит меня к блогу коллеги Патрика Нильсена
Patrick Ryan Nielsen: Cisco TFTP new IOS – ARP timed out , в котором он говорит, что ему удалось решить проблему с помощью увеличения количества ARP-запросов. Поэтому еще и
TFTP_RETRY_COUNT=25 (по-умолчанию 7)
ну и для более подробного освещения происходящего -
TFTP_VERBOSE=2

с этими настройками добится результата не удалось.
Тестирую работу tftp-сервера с помощью подключения к нему с другой станции - все прекрасно работает, файл сливается без проблем.

Единственное отличие, которое мне удалось заметить - это значения поля Target Hardware Address в ARP-запросах. В запросах, которые посылает Linux-host это значение равно 00-00-00-00-00-00 -так ведут себя большинство сетевых ОС, насколько мне известно.
В запросах от Cisco-маршрутизатора - равно ff-ff-ff-ff-ff-ff.
"Неужто за такие бабки они еще и позволяют генерить себе кривые ARP-запросы " -с возмущением думаю я и лезу на ietf.org.
Ан нет! Согласно rfc 826 никто не обязан устанавливать поле Target Hardware Address в нули. Более того, значение этого поля вообще строго не регламентируется.

It does not set ar$tha to anything in particular, because it is this value that it is trying to determine.

А уж в Ethernet так вообще  - бродкаст в этом поле нормальное явление - 

It could set ar$tha to the broadcast address for the hardware (all ones in the case of the 10Mbit Ethernet) if that makes it convenient for some aspect of the implementation.

Итого - блажит таки Linux, раз уж Cisco ведет себя вполне канонично.
 Из того же rfc следует логичный вывод - хост должен ответить на ARP-запрос, если у него есть интерфейс, обладающий IP -адресом , указанным в поле Target Protocol Address запроса, и если opcode = request. 
Запускаю на сервере tail -f /var/log/messages и еще раз даю команду tftpdnld в ROMMON маршрутизатора. 
Опаньки! Вот ты и попалось -
с приходом первого же ARP-запроса лог порадовал меня сообщением - eth2: link down
То есть при получении "неправильного" ,с его точки зрения , ARP-сообщения, Bubuntu запаниковал и слился :)
Благо ранее я выставил 25 попыток ARP-запроса на маршрутизаторе. Пока не истек таймаут - ввожу руками ifconfig eth2 192.168.1.1 up - интерфейс как  ни в чем не бывало  рапортует : eth2: link up и отдает ARP-ответ. Загрузка образа проходит как дети в школу.

Как я и обещал - плохих поймали и заставили исправиться. Но почему Ubuntu с ядром 2.6.31-14
так неадекватно реагирует на вполне соответствующий rfc ARP-запрос -я так и не понял..