21.05.2012 01:52, Eugene Berdnikov пишет:
> On Sun, May 20, 2012 at 10:50:40PM +0400, "Артём Н." wrote:
>> 20.05.2012 21:00, Eugene Berdnikov пишет:
>>> Прежде всего, в случае nm нет никаких маршрутов через eth1.
>>> Сеть в такой конфигурации работать не будет, это и ежу понятно.
>> Я добавлял вручную (в случае с nm), по крайней мере, маршрут по умолчанию.
>> Всё-равно не работало. Маршруты же должны сами установиться, если работает DHCP?
>
> Он не работает, в том смысле что никаких входящих пакетов в дампе не видно.
> Собственно, это и наводит на подозрения о нестыковке скорости/дуплекса.
Да, я понимаю. Я про то, что если бы работал DHCP, всё бы установилось.
А если нестыковки на физическом уровне, почему работает promisc?
Да и модем его видит (в arp таблице модема правильный MAC).
Вот вывод ethtools:
"root@dana:~# ethtool eth1
Settings for eth1:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
drv probe ifdown ifup
Link detected: yes
root@dana:~# mii-tool -v eth1
eth1: negotiated 100baseTx-FD flow-control, link ok
product info: vendor 00:07:32, model 17 rev 2
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD
10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD
10baseT-HD flow-control"
>>> Хотя меня удивляет то, что в дампе видны arp-request'ы, как будто
>>> кто-то пытается послать юникастовый пакет через eth1 при
>>> отсутствии маршрута на этот интерфейс... но может быть, я какой-то
>>> простой причины для arp'а не вспоминаю.
>> Кстати, модем его видит и arp таблице модема появляется запись.
>
> Кстати, модем умеет хотя бы пинговать соседний хост?
> Если да, пустите пинг на 192.168.1.3 и посмотрите, видны ли эти
> пакеты в дампе. Если да, пришлите кусок этого дампа (желательно
> в виде файла, записанного по -w, а не распечатки).
Соединение есть, когда включен promisc. С выключенным promisc модем не получает
ответа на пинг.
Я запустил tcpdump и пошёл к другому компу, с модема пропинговать 192.168.1.3
(это мой):
"root@dana:~# tcpdump -vv -i eth1 -p
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
13:46:26.416159 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has dana-0 tell
192.168.1.1, length 46
13:46:26.416175 ARP, Ethernet (len 6), IPv4 (len 4), Reply dana-0 is-at
aa:00:04:00:0a:04 (oui Unknown), length 28
13:46:26.416572 IP (tos 0x0, ttl 64, id 3253, offset 0, flags [DF], proto UDP
(17), length 70)
dana-0.45610 > 192.168.1.1.domain: [udp sum ok] 52766+ PTR?
1.1.168.192.in-addr.arpa. (42)
13:46:31.421706 IP (tos 0x0, ttl 64, id 3254, offset 0, flags [DF], proto UDP
(17), length 70)
dana-0.45610 > 192.168.1.1.domain: [udp sum ok] 52766+ PTR?
1.1.168.192.in-addr.arpa. (42)
13:46:31.426340 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1
tell dana-0, length 28
13:46:32.429678 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1
tell dana-0, length 28
13:46:33.433010 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1
tell dana-0, length 28
13:46:50.019508 IP (tos 0x0, ttl 128, id 21719, offset 0, flags [none], proto
UDP (17), length 236)
user-pc.netbios-dgm > 192.168.1.255.netbios-dgm: [udp sum ok]
>>> NBT UDP PACKET(138) Res=0x1102 ID=0xEDF8 IP=192 (0xc0).168 (0xa8).1 (0x1).2
(0x2) Port=138 (0x8a) Length=194 (0xc2) Res2=0x0
SourceName=USER-PC NameType=0x00 (Workstation)
DestName=__MSBROWSE__ NameType=0x01 (Unknown)"
Сейчас пишу почту в icedove (promisc выключен), он изредка пытается обратиться к
серверу по IMAP. И запущена SAMBA (ну, там видно он netbios пакеты пытается
послать).
Пинг не прошёл, я перезапустил tcpdump и повторно попытался пропинговать, лог
приложил (tcpdump -w).
В случае со включенным 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
14:02:21.062556 IP 192.168.1.1 > dana-0: ICMP echo request, id 1933, seq 0,
length 64
14:02:21.062594 IP dana-0 > 192.168.1.1: ICMP echo reply, id 1933, seq 0, length 64
14:02:22.062043 IP 192.168.1.1 > dana-0: ICMP echo request, id 1933, seq 1,
length 64
14:02:22.062073 IP dana-0 > 192.168.1.1: ICMP echo reply, id 1933, seq 1, length 64
14:02:23.062096 IP 192.168.1.1 > dana-0: ICMP echo request, id 1933, seq 2,
length 64
14:02:23.062131 IP dana-0 > 192.168.1.1: ICMP echo reply, id 1933, seq 2, length 64
14:02:24.062204 IP 192.168.1.1 > dana-0: ICMP echo request, id 1933, seq 3,
length 64
14:02:24.062236 IP dana-0 > 192.168.1.1: ICMP echo reply, id 1933, seq 3, length 64"
>>> В целом, конечно, клиника... А nm'у поднять какой-нибудь log level можно?
>> Есть опция log-level...
>> Вот, что он писал в syslog (где successfull, там уже, видимо, интерфейс был
>
> К сожалению, причины переходов между различными состояниями nm из лога
> непонятны... :( К тому же присланный лог заканчивается на "stage 2 of 5",
> возможно, на этом месте nm клинит и это есть бага.
Что вообще делает nm? Запускает скрипты из networking, аналогично ifup? Или нет?
Т.е., вы думаете это бага в NM? С модемом, вероятно, м.б. проблемы.
Брат пытался подконнектиться по wi-fi. Сбрасывало. Причём, сбрасывало на Debian,
на Win7 и на Android. Но у меня ноут и нетбук на Win7 нормально подключаются...
Хотя, в данном случае, вряд ли это глюк модема.
Attachment:
_tdlog
Description: Binary data