22.05.2012 12:58, Eugene Berdnikov пишет: > On Mon, May 21, 2012 at 10:05:24PM +0400, "Артём Н." wrote: >>> Чувствую, это капитальная клиника. Но давайте всё же дождёмся дампа. >> Для _tdlog0 (там что-то не очень понятное): >> root@dana:~# ping 192.168.1.1 >> connect: Network is unreachable >> root@dana:~# ping 192.168.1.1 >> connect: Network is unreachable >> root@dana:~# ifconfig eth0 promisc >> root@dana:~# ping 192.168.1.1 >> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. >> 64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=1.03 ms >> 64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=0.943 ms >> ^C >> --- 192.168.1.1 ping statistics --- >> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms >> rtt min/avg/max/mdev = 0.943/0.990/1.038/0.056 ms >> root@dana:~# ifconfig eth0 -promisc >> root@dana:~# ping 192.168.1.1 >> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. >> ^C >> --- 192.168.1.1 ping statistics --- >> 5 packets transmitted, 0 received, 100% packet loss, time 4006ms > > В файлике _tdlog0 этого нет. Вообще, там только исходящие пакеты, > если не считать обмен arp-ами между 192.168.1.3 и 192.168.1.2. > А обмена по icmp с 192.168.1.1 вовсе нет. Есть лишь исходящие > пакеты 192.168.1.3 > 192.168.1.2 (ICMP echo request). Так я не дампил в promisc режиме. Надо?
> > Такая же странность со вторым файлом. Вы сами смотрели записанные дампы, > такая ситуация не удивляет? Вы же не видите того трафика, который > генерите своими ручками. Не вижу. Но не удивляет. o.O Меня бы удивило, если бы я его там увидел. >> Для чистоты эксперимента, во втором случае (_tdlog1), я отключил файрволл: > Наличие файрвола на дамп влиять не должно, но лучше действительно выключить. На всякий случай. Вдруг ICMP режутся неправильно (а режутся ответы для внешней сети, в первом логе я заметил какие-то непотребные адреса)? > Итак, можно предположить, что есть некий клинический случай асимметричного > роутинга, когда пакеты почему-то идут не через eth, а иным путём... > Какие ещё сетевые интерфейсы есть на машине? Петля и виртуальная сеть VMWare vmnet0. > Выключите все виртуалки, > приведите машину к проблемному состоянию и покажите результат работы > такого скрипта: > > ip addr list > ip route list > ip link set dev eth0 promisc off > ip route flush cache > ip route get 192.168.1.1 > tcpdump -nlUevvp -i any arp or icmp & > ping -n -c2 192.168.1.1 > killall tcpdump > ip link set dev eth0 promisc on > ip route flush cache > ip route get 192.168.1.1 > tcpdump -nlUevvp -i any arp or icmp & > ping -n -c2 192.168.1.1 > killall tcpdump > ip link set dev eth0 promisc off Хорошо. Попозже пришлю результат. >>> К сожалению, драйвер r8169 не поддерживает >>> чтение eeprom'a, можно лишь посмотреть ethtool -d, но это может оказаться >>> искажённой информацией. >> root@dana:~# ethtool -d eth0 >> Unknown RealTek chip (mask: 0xfcc00000) > > Вот те раз... А должно быть что-то вроде этого: > > # ethtool -d mon > RealTek RTL-8169/8110SB registers: > -------------------------------------------------------- > 0x00: MAC Address 00:14:d1:15:49:b6 > 0x08: Multicast Address Filter 0x84000080 0x40000200 > 0x10: Dump Tally Counter Command 0x00000000 0x00000000 > 0x20: Tx Normal Priority Ring Addr 0x3448b000 0x00000000 > 0x28: Tx High Priority Ring Addr 0xbbcdff00 0xbfffffff > 0x30: Flash memory read/write 0x00000000 > 0x34: Early Rx Byte Count 0 > 0x36: Early Rx Status 0x00 > 0x37: Command 0x00 > Rx off, Tx off > 0x3C: Interrupt Mask 0x0000 > > 0x3E: Interrupt Status 0x0000 > > 0x40: Tx Configuration 0x10000000 > 0x44: Rx Configuration 0x00000002 > 0x48: Timer count 0x3c59f6ae > 0x4C: Missed packet counter 0x000000 > 0x50: EEPROM Command 0x00 > 0x51: Config 0 0x05 > 0x52: Config 1 0x4d > 0x53: Config 2 0x10 > 0x54: Config 3 0xa1 > 0x55: Config 4 0x80 > 0x56: Config 5 0x01 > 0x58: Timer interrupt 0x00000000 > 0x5C: Multiple Interrupt Select 0x0000 > 0x60: PHY access 0x800541e1 > 0x64: TBI control and status 0x00000000 > 0x68: TBI Autonegotiation advertisement (ANAR) 0x0000 > 0x6A: TBI Link partner ability (LPAR) 0x0000 > 0x6C: PHY status 0x0b > 0x84: PM wakeup frame 0 0xbdddc0bd 0xd65dafbf > 0x8C: PM wakeup frame 1 0xb7c72a6e 0xee1af5ff > 0x94: PM wakeup frame 2 (low) 0x9ffff64d 0x9e9fde5f > 0x9C: PM wakeup frame 2 (high) 0xbac35dfd 0x5f5fda79 > 0xA4: PM wakeup frame 3 (low) 0x776ef7df 0xbc7beebf > 0xAC: PM wakeup frame 3 (high) 0xff4f2d7f 0x8f8ffddf > 0xB4: PM wakeup frame 4 (low) 0xbf3cbbff 0xb3b6bc9e > 0xBC: PM wakeup frame 4 (high) 0xfff4bdbf 0xf82bfb7f > 0xC4: Wakeup frame 0 CRC 0x7df1 > 0xC6: Wakeup frame 1 CRC 0xfbfc > 0xC8: Wakeup frame 2 CRC 0xb7ff > 0xCA: Wakeup frame 3 CRC 0xf5de > 0xCC: Wakeup frame 4 CRC 0x5bef > 0xDA: RX packet maximum size 0x4000 > 0xE0: C+ Command 0x2068 > VLAN de-tagging > RX checksumming > PCI Multiple RW > 0xE2: Interrupt Mitigation 0x0000 > TxTimer: 0 > TxPackets: 0 > RxTimer: 0 > RxPackets: 0 > 0xE4: Rx Ring Addr 0x32e8e000 0x00000000 > 0xEC: Early Tx threshold 0x3f > 0xF0: Func Event 0x00008000 > 0xF4: Func Event Mask 0x00000000 > 0xF8: Func Preset State 0x00000002 > 0xFC: Func Force Event 0x00000000 > > Возможно, карточка была повреждена при перепрошивке. > Хотя я пока не знаю, может ли это как-то объяснять чудеса, > которые мы наблюдаем в дампе. Возможно ли такое, что карточку повредил flashrom, который не поддерживал мать (а man я не посмотрел и опцию -l не использовал перед прошивкой)? Ещё и прошивку не ту залил. Окончилось печально: пришлось искать нормальную прошивку и везти микросхему BIOS на программатор. Адаптер, понятное дело, встроенный. Мог ли он быть повреждён? И как лечить? :-( -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fbba9a0.8080...@yandex.ru
