скорее всего - проблема в кабеле

Как раз сработал 0,1%. У меня 804 три дня назад так глюкнул.
Вот логи провайдера (00:0f:3d:1a:37:4e - arp 804hv):
Dec 10 22:38:03 stone /kernel: arp: 00:0f:3d:1a:37:4e attempts to modify permanent entry for 212.17.28.147 on rl1
Dec 10 22:43:22 stone /kernel: arp: 00:0f:3d:1a:37:4e attempts to modify permanent entry for 212.17.28.149 on rl1
Dec 10 22:43:53 stone /kernel: arp: 00:0f:3d:1a:37:4e attempts to modify permanent entry for 212.17.28.149 on rl1
Dec 10 22:44:12 stone /kernel: arp: 00:0f:3d:1a:37:4e attempts to modify permanent entry for 212.17.28.149 on rl1

Одновременно такое же безобразие творилось на lan интерфейсе.

есть два варианта для выяснения ситуации
1. Поставить другое устройство - и посмотреть,измениться ли ситуация ?
2. включить хаб в разрыв кабеля до провайдера и половить пакеты снифером (только пакеты ARP) и сохр. буфер прислать для анализа нам.

В том то и дело, что воспроизведению трудно поддается. За 2 месяца работы такое первый раз.


факт в том, что устройство рассылает arp-пакеты cо своим mac-адресом и чужими IP. Остальные устройства это дело глотают и перестраивают свою arp таблицу. В результате весь локальный трафик идет на lan-интерфейс.
2004-12-10 19:12:17 User.Warning 192.168.2.2 Blocked access attempt from 192.168.2.30:137 to 192.168.2.136:137 proto=17 rule=3
2004-12-10 19:16:39 User.Warning 192.168.2.2 Blocked access attempt from 192.168.2.30:137 to 192.168.2.136:137 proto=17 rule=3
2004-12-10 19:17:18 User.Warning 192.168.2.2 Blocked access attempt from 192.168.2.24:138 to 192.168.2.0:138 proto=17 rule=3
2004-12-10 19:28:42 User.Warning 192.168.2.2 Blocked access attempt from 192.168.2.30:137 to 192.168.2.136:137 proto=17 rule=3
2004-12-10 19:32:18 User.Warning 192.168.2.2 Blocked access attempt from 192.168.2.30:137 to 192.168.2.136:137 proto=17 rule=3
2004-12-10 19:40:46 User.Warning 192.168.2.2 Blocked access attempt from 192.168.2.30:137 to 192.168.2.136:137 proto=17 rule=3
2004-12-10 19:52:17 User.Warning 192.168.2.2 Blocked access attempt from 192.168.2.30:137 to 192.168.2.136:137 proto=17 rule=3


А весь трафик подсети провайдера - на wan.

Вот еще от провайдера:
Dec 10 18:58:02 stone /kernel: arp: 212.17.6.151 moved from 00:0d:9d:5e:42:b0 to 00:0f:3d:1a:37:4e on rl1
Dec 10 19:02:28 stone /kernel: arp: 212.17.6.157 moved from 00:0a:01:ac:07:57 to 00:0f:3d:1a:37:4e on rl1
Dec 10 19:05:00 stone /kernel: arp: 212.17.6.151 moved from 00:0d:9d:5e:42:b0 to 00:0f:3d:1a:37:4e on rl1
Dec 10 19:08:04 stone /kernel: arp: 212.17.6.149 moved from 00:0d:9d:5d:ea:58 to 00:0f:3d:1a:37:4e on rl1
Dec 10 19:08:44 stone /kernel: arp: 212.17.6.147 moved from 00:50:22:b5:9d:10 to 00:0f:3d:1a:37:4e on rl1
Dec 10 19:09:07 stone /kernel: arp: 212.17.6.151 moved from 00:0d:9d:5e:42:b0 to 00:0f:3d:1a:37:4e on rl1
Dec 10 19:13:09 stone /kernel: arp: 212.17.6.151 moved from 00:0d:9d:5e:42:b0 to 00:0f:3d:1a:37:4e on rl1
Dec 10 19:14:53 stone /kernel: arp: 212.17.6.148 moved from 00:04:61:57:fa:4f to 00:0f:3d:1a:37:4e on rl1

Для того, что бы разобраться со 100% уверенностью - другого варианта, кроме снифера, нет !

Вовсе не факт, что эти пакеты посылает именно 804, а не какой-то ломальщик. При желании можно сформировать любой пакет.

Был в форуме пост с такой же проблемой, но там несколько раз в день происходило такое чудо. Я просил мне прислать буфер захваченных пакетов - но что-то тишина. Видимо, разобрались сами.

Тогда как минимум два ломальщика: первый - какой-то полтергейст в локальной сети, который проник в закрытый и сданный на сигнализацию офис, а второй в ЭТО ЖЕ время - в сети провайдера. И все для того, чтобы дискредитировать 804HV.

Если серьезно, то пакеты рассылались именно 804. У провайдера управляемый коммутатор, и пакеты шли с порта, к которому подключен только 804hv.

подтверждаю такую же ситуацию с переборами адресов
на любых прошивках, а миенно работали родна(не помню уж екакая), 1.34b01, 1.38, 1.40, 1.41
причем у нас еще файяволл включен, все правила, мы пытаемся не пускать такие пакеты во вне, а ему пофигу.