Re: Сетевуха работает только в promisc режиме
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 на программатор.
Адаптер, понятное дело, встроенный.
Мог ли он быть повреждён? И как лечить? :-(
Reply to: