21.05.2012 14:41, Eugene Berdnikov пишет:
> On Mon, May 21, 2012 at 02:04:05PM +0400, "Артём Н." wrote:
>> 21.05.2012 01:52, Eugene Berdnikov пишет:
>> А если нестыковки на физическом уровне, почему работает promisc?
>
> Поиск вслепую... Изменение режима чипа на promisc может непредсказуемо
> изменить поведение трансивера, в частности, никто не гарантирует что
> чип не начнёт вдруг принимать пакеты, которые он раньше не принимал
> из-за рассогласования скоростей.
Хм... Надо же. А про конкретный чип это возможно сказать (ниже его данные)?
>> Да и модем его видит (в arp таблице модема правильный MAC).
>
> Модем может ловить бродкасты и заполнять по ним таблицу mac'ов.
> Так свитчи работают. Странно то, что от модема никаких пакетов не видно.
Но ничего не посылается, даже ping (на модеме tcpdump, скорее всего, нет, не
проверю). Почему посылаются броадкасты (если посылаются)?
>> Пинг не прошёл, я перезапустил tcpdump и повторно попытался пропинговать, лог
>> приложил (tcpdump -w).
>
> В нём ни одного пакета от 192.168.1.1. Хотя есть от 192.168.1.2,
> и это удивительно, потому что изернетина фактически работает.
Да, 192.168.1.2 - ноут с w7 (самба пытается с ним состыковаться).
>> В случае со включенным promisc (tcpdump без -p, 192.168.1.1 - модем):
>> "14:02:09.180374 ARP, Request who-has dana-0 tell 192.168.1.1, length 46
>> 14:02:09.180390 ARP, Reply dana-0 is-at aa:00:04:00:0a:04 (oui Unknown), length 28
>
> Вот это именно то, что меня интересует, только link level опять не показан.
> Нужен tcpdump -n -e. Лучше пришлите файлик, записанный по -w.
Приложил с работающей системы (опустил интерфейс, поднял, запустил tcpdump -n -e
во время поднятия). С неработающей приложу позже (сегодня или завтра вечером).
> Кстати, мы всё рассуждаем про eth1, а что с eth0? Существует ли он,
> подключен ли к сети, если да, то не к той же случайно?
Кстати, хотел вас об этом спросить. :-)
Ядро самосборное (изначально с oldconfig). Всё, что не нужно выкинуто. Всё, в
чём сомневался, - оставил модулем.
Как я понял, есть PHY и M-II подсистемы.
Изначально (при установке на дистр. ядре) был eth0.
После какого-то из изменений стал eth1.
Я вкомпилил два драйвера (на всякий случай):
1. "Drivers for Realtek PHYs". (Supports the Realtek 821x PHY.)
2. "Realtek 8169 gigabit ethernet support" (CONFIG_R8169) (Realtek 8169 PCI
Gigabit Ethernet adapter).
Очевидно, что PHY не работает. И я его сейчас убрал вообще.
Но вопрос: почему две подсистемы и в чём отличия (я мало знаю по адаптерам)?
И почему остался eth1?
Адаптер:
"01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI
Express Gigabit Ethernet controller (rev 03)
Subsystem: ASUSTeK Computer Inc. M4A785TD Motherboard
Flags: bus master, fast devsel, latency 0, IRQ 45
I/O ports at b800 [size=256]
Memory at dffff000 (64-bit, prefetchable) [size=4K]
Memory at dfff8000 (64-bit, prefetchable) [size=16K]
Expansion ROM at f5ef0000 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [ac] MSI-X: Enable- Count=4 Masked-
Capabilities: [cc] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
Kernel driver in use: r8169"
>>> К сожалению, причины переходов между различными состояниями nm из лога
>>> непонятны... :( К тому же присланный лог заканчивается на "stage 2 of 5",
>>> возможно, на этом месте nm клинит и это есть бага.
>> Что вообще делает nm? Запускает скрипты из networking, аналогично ifup?
>
> Я nm не щупал, и судя по его логу, видеть его у себя не очень-то желаю. :)
Мне он, в принципе, тоже не очень нужен.
Только для того, чтобы иконка в трэе отображалась.
И ещё хочется понять, что не так работает.
Attachment:
_tdlog
Description: Binary data