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).
Такая же странность со вторым файлом. Вы сами смотрели записанные дампы,
такая ситуация не удивляет? Вы же не видите того трафика, который
генерите своими ручками.
> Для чистоты эксперимента, во втором случае (_tdlog1), я отключил файрволл:
Наличие файрвола на дамп влиять не должно, но лучше действительно выключить.
Итак, можно предположить, что есть некий клинический случай асимметричного
роутинга, когда пакеты почему-то идут не через eth, а иным путём...
Какие ещё сетевые интерфейсы есть на машине? Выключите все виртуалки,
приведите машину к проблемному состоянию и покажите результат работы
такого скрипта:
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
Возможно, карточка была повреждена при перепрошивке.
Хотя я пока не знаю, может ли это как-то объяснять чудеса,
которые мы наблюдаем в дампе.
--
Eugene Berdnikov
--
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/20120522085837.gj7...@protva.ru
