Сетевуха работает только в promisc режиме

["Артём Н."]

Есть ADSL модем D-Link 2600U. У него один порт Ethernet, к которому подключен
компьютер.

Проблема в том, что адаптер на компьютере приходится переводить в promisc режим.

Иначе, не проходит даже пинг:
"root@dana:~# ifconfig eth1 -promisc
root@dana:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
>From 192.168.1.3 icmp_seq=1 Destination Host Unreachable
>From 192.168.1.3 icmp_seq=2 Destination Host Unreachable
>From 192.168.1.3 icmp_seq=3 Destination Host Unreachable
^C
--- 192.168.1.1 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4008ms
pipe 3
root@dana:~# ifconfig eth1 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=2.45 ms
^C
--- 192.168.1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.453/2.453/2.453/0.000 ms"

ARP таблица на модеме:
"> arp show

IP address HW type Flags HW address Mask Device
192.168.1.3 0x1 0x2 AA:00:04:00:0A:04 * br0"

ARP таблица на компьютере:
"root@dana:~# arp
Address HWtype HWaddress Flags Mask Iface
192.168.1.1 ether 00:22:b0:be:bf:e3 C eth1"

Таблица маршрутизации:
"root@dana:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth1
192.168.1.0 * 255.255.255.0 U 0 0 0 eth1"

В модеме, для LAN:
"192.168.1.0 * 255.255.255.0 U 0 0 0 br0"


Почему адаптер не работает в обычном режиме (ЧЯДНТ)?
Какие могут быть причины?
Как это исправить?


P.S.:
При этом, нетбук по wi-fi подключается нормально (но на нетбуке win7).


--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4FB8963D...@yandex.ru

["Артём Н."]

Блин. Это прямой путь в психушку.
После установки ifupdown всё снова заработало без promisc.

"root@dana:~# ifconfig
eth1 Link encap:Ethernet HWaddr aa:00:04:00:0a:04
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::a800:4ff:fe00:a04/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:27239 errors:0 dropped:0 overruns:0 frame:0
TX packets:15175 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:40620467 (38.7 MiB) TX bytes:1077630 (1.0 MiB)
Interrupt:45 Base address:0x8000 "

Кто-нибудь может объяснить что они такого делают, чего не делает network-manager?

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FB8A450...@yandex.ru

[Dmitry A. Zhiglov]

2012/5/20 "Артём Н." <arti...@yandex.ru>:

> Блин. Это прямой путь в психушку.
> После установки ifupdown всё снова заработало без promisc.

> Кто-нибудь может объяснить что они такого делают, чего не делает network-manager?

Это в testing?

["Артём Н."]

20.05.2012 12:32, Dmitry A. Zhiglov пишет:

Угу. Причём, с nm я извращался, как мог. В interfaces отключал eth, всё-равно,
да и вручную не поднимается.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FB8AF7D...@yandex.ru

["Артём Н."]

20.05.2012 12:46, "Артём Н." пишет:

> 20.05.2012 12:32, Dmitry A. Zhiglov пишет:
>> 2012/5/20 "Артём Н." <arti...@yandex.ru>:
>>> Блин. Это прямой путь в психушку.
>>> После установки ifupdown всё снова заработало без promisc.
>>> Кто-нибудь может объяснить что они такого делают, чего не делает network-manager?
>>
>> Это в testing?
> Угу. Причём, с nm я извращался, как мог. В interfaces отключал eth, всё-равно,
> да и вручную не поднимается.

Да, на всякий случай отключал. Знаю, что ни на что не влияет. Может дело в том,
что ifconfig устанавливает broadcast адрес? К сожалению, вывод ifconfig без
ifupdown я не сохранил, а повторять неохота. Куплю бубен. o.O

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FB8B0D1...@yandex.ru

["Артём Н."]

20.05.2012 12:32, Dmitry A. Zhiglov пишет:

Проверил без ifupdown.

Вопрос остаётся открытым.
В чём разница между nm и ifup?

Во-первых, broadcast адрес и маска не устанавливаются:
root@dana:~# ifconfig -a

eth1 Link encap:Ethernet HWaddr aa:00:04:00:0a:04

inet6 addr: fe80::a800:4ff:fe00:a04/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:53 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:9270 (9.0 KiB)

Interrupt:45 Base address:0x8000

Во-вторых, после установки вручную, всё-равно ничего не работает:
root@dana:~# ifconfig eth1

eth1 Link encap:Ethernet HWaddr aa:00:04:00:0a:04
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::a800:4ff:fe00:a04/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:159 errors:0 dropped:0 overruns:0 frame:0
TX packets:330 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:102937 (100.5 KiB) TX bytes:38117 (37.2 KiB)

Interrupt:45 Base address:0x8000

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 ---

2 packets transmitted, 0 received, 100% packet loss, time 1007ms

Ещё раз, продублирую, вывод с установленным ifupdown:

"root@dana:~# ifconfig
eth1 Link encap:Ethernet HWaddr aa:00:04:00:0a:04
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::a800:4ff:fe00:a04/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:27239 errors:0 dropped:0 overruns:0 frame:0
TX packets:15175 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:40620467 (38.7 MiB) TX bytes:1077630 (1.0 MiB)
Interrupt:45 Base address:0x8000 "

С ifupdown всё работает. Когда используется nm - нет.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FB8B88E...@yandex.ru

["Артём Н."]

Кто-нибудь может объяснить, как поднимается эта хренова сеть?
Я поставил ifupdown и, всё-равно, ничего не заработало.
После перезагрузки всё заработало снова.
В интернетах ничего толкового я не нашёл.
Вот вывод:

"root@dana:~# ifconfig eth1 -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 ---

2 packets transmitted, 0 received, 100% packet loss, time 1008ms

root@dana:~# ifup eth1
Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/aa:00:04:00:0a:04
Sending on LPF/eth1/aa:00:04:00:0a:04
Sending on Socket/fallback
DHCPREQUEST on eth1 to 255.255.255.255 port 67
DHCPNAK from 192.168.1.1
Reloading /etc/samba/smb.conf: smbd only.
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4
^C
root@dana:~# ifdown eth1
Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/aa:00:04:00:0a:04
Sending on LPF/eth1/aa:00:04:00:0a:04
Sending on Socket/fallback
DHCPRELEASE on eth1 to 192.168.1.1 port 67
send_packet: Network is unreachable
send_packet: please consult README file regarding broadcast address.
Reloading /etc/samba/smb.conf: smbd only.
root@dana:~# ifup eth1
Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/aa:00:04:00:0a:04
Sending on LPF/eth1/aa:00:04:00:0a:04
Sending on Socket/fallback
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 13
^C
root@dana:~# service network-manager stop
[ ok ] Stopping network connection manager: NetworkManager.
root@dana:~# ifdown eth1
Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/aa:00:04:00:0a:04
Sending on LPF/eth1/aa:00:04:00:0a:04
Sending on Socket/fallback
DHCPRELEASE on eth1 to 192.168.1.1 port 67
send_packet: Network is unreachable
send_packet: please consult README file regarding broadcast address.
Reloading /etc/samba/smb.conf: smbd only.
root@dana:~# ifup eth1
Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/aa:00:04:00:0a:04
Sending on LPF/eth1/aa:00:04:00:0a:04
Sending on Socket/fallback
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 6

^C
root@dana:~# service network
networking network-manager
root@dana:~# service networking restart
[warn] Running /etc/init.d/networking restart is deprecated because it may not
re-enable some interfaces ... (warning).
[....] Reconfiguring network interfaces...Internet Systems Consortium DHCP
Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/aa:00:04:00:0a:04
Sending on LPF/eth1/aa:00:04:00:0a:04
Sending on Socket/fallback
DHCPRELEASE on eth1 to 192.168.1.1 port 67
send_packet: Network is unreachable
send_packet: please consult README file regarding broadcast address.
Reloading /etc/samba/smb.conf: smbd only.
Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/aa:00:04:00:0a:04
Sending on LPF/eth1/aa:00:04:00:0a:04
Sending on Socket/fallback
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4
No DHCPOFFERS received.
Unable to obtain a lease on first try. Exiting.
Failed to bring up eth1.
Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/aa:00:04:00:0a:04
Sending on LPF/eth1/aa:00:04:00:0a:04
Sending on Socket/fallback
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 18
No DHCPOFFERS received.
Unable to obtain a lease on first try. Exiting.
Failed to bring up eth1.
done."

* Английский - определен
* Английский
* Русский

* Английский
* Русский

<javascript:void(0);>

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FB8BC11...@yandex.ru

[Eugene Berdnikov]

On Sun, May 20, 2012 at 01:40:33PM +0400, "Артём Н." wrote:
> Кто-нибудь может объяснить, как поднимается эта хренова сеть?
> Я поставил ifupdown и, всё-равно, ничего не заработало.
> После перезагрузки всё заработало снова.

Запишите в файлики выдачу "sysctl -a | fgrep eth1" и "ip route list"
и сравните для вариантов с nm и ifupdown.

Для случая с nm ещё хорошо бы записать дамп трафика на eth1,
чтобы убедиться, что пакеты (не) вылетают из eth1, а обратные
пакеты идут на mac интерфейса (или на другой mac). Учтите, что
tcpdump, запущенный без -p, сам переводит интерфейс в promisc.
--
Eugene Berdnikov

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2012052011...@sie.protva.ru

["Артём Н."]

20.05.2012 15:41, Eugene Berdnikov О©╫О©╫О©╫О©╫О©╫:
> On Sun, May 20, 2012 at 01:40:33PM +0400, "О©╫О©╫тёО©╫ О©╫." wrote:
>> О©╫О©╫О©╫-О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫?
>> О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ ifupdown О©╫, О©╫сё-О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.
>> О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫сё О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫.
>
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ "sysctl -a | fgrep eth1" О©╫ "ip route list"
> О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ nm О©╫ ifupdown.
>
> О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ nm О©╫щё О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ eth1,
> О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ (О©╫О©╫) О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ eth1, О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
> О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫ mac О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ (О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ mac). О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫
> tcpdump, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ -p, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ promisc.

О©╫сё-О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫:
< net.ipv6.conf.eth1.accept_ra = 2
---
> net.ipv6.conf.eth1.accept_ra = 0
85,88d84
< net.decnet.conf.eth1.priority = 0
< net.decnet.conf.eth1.t2 = 1
< net.decnet.conf.eth1.t3 = 10
< net.decnet.default_device = eth1
92,93d87
< default via 192.168.1.1 dev eth1 proto static
< 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.3

О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

О©╫О©╫О©╫О©╫О©╫ tcpdump:
"root@dana:~# tcpdump -vv -p -i eth1
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
19:40:10.805729 IP6 (hlim 1, next-header Options (0) payload length: 36) :: >
ff02::16: HBH (rtalert: 0x0000) (padn)[icmp6 sum ok] ICMP6, multicast listener
report v2, 1 group record(s) [gaddr ff02::1:ff00:a04$
19:40:10.805990 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1
tell 192.168.62.1, length 28
19:40:10.819293 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP
(17), length 328)
0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request
from aa:00:04:00:0a:04 (oui Unknown), length 300, xid 0x6ce4164e, Flags [none]
(0x0000)
Client-Ethernet-Address aa:00:04:00:0a:04 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Requested-IP Option 50, length 4: dana-0
Hostname Option 12, length 4: "dana"
Parameter-Request Option 55, length 17:
Subnet-Mask, BR, Time-Zone, Default-Gateway
Domain-Name, Domain-Name-Server, Option 119, Hostname
Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
NTP, Classless-Static-Route, Classless-Static-Route-Microsoft,
Option 252
NTP
19:40:10.935751 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) :: >
ff02::1:ff00:a04: [icmp6 sum ok] ICMP6, neighbor solicitation, length 24, who
has fe80::a800:4ff:fe00:a04"

О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫: О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ (О©╫О©╫ О©╫
О©╫О©╫О©╫О©╫ О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ - О©╫сё-О©╫О©╫О©╫О©╫О©╫).

* О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ - О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
* О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
* О©╫О©╫О©╫О©╫О©╫О©╫О©╫

* О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
* О©╫О©╫О©╫О©╫О©╫О©╫О©╫

<javascript:void(0);>

[Eugene Berdnikov]

On Sun, May 20, 2012 at 07:58:40PM +0400, "Артём Н." wrote:
> 20.05.2012 15:41, Eugene Berdnikov пишет:

> > Запишите в файлики выдачу "sysctl -a | fgrep eth1" и "ip route list"
> > и сравните для вариантов с nm и ifupdown.
> >
> > Для случая с nm ещё хорошо бы записать дамп трафика на eth1,
> > чтобы убедиться, что пакеты (не) вылетают из eth1, а обратные
> > пакеты идут на mac интерфейса (или на другой mac). Учтите, что
> > tcpdump, запущенный без -p, сам переводит интерфейс в promisc.
>

> Всё-равно не понятно.
>
> Различия:

> < net.ipv6.conf.eth1.accept_ra = 2
> ---
> > net.ipv6.conf.eth1.accept_ra = 0
> 85,88d84
> < net.decnet.conf.eth1.priority = 0
> < net.decnet.conf.eth1.t2 = 1
> < net.decnet.conf.eth1.t3 = 10
> < net.decnet.default_device = eth1
> 92,93d87
> < default via 192.168.1.1 dev eth1 proto static
> < 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.3

Прежде всего, в случае nm нет никаких маршрутов через eth1.
Сеть в такой конфигурации работать не будет, это и ежу понятно.

Хотя меня удивляет то, что в дампе видны arp-request'ы, как будто
кто-то пытается послать юникастовый пакет через eth1 при
отсутствии маршрута на этот интерфейс... но может быть, я какой-то
простой причины для arp'а не вспоминаю.

Кроме того, в дампе только исходящие пакеты. Вероятно, связи со шлюзом
просто нет, несмотря на флаги интерфейса UP и RINNING. Хотелось бы
проверить, правильно ли выставлен duplex или скорость передачи,
сравните выдачу "mii-tool -v eth1" и "ethtool eth1".

В целом, конечно, клиника... А nm'у поднять какой-нибудь log level можно?

--
Eugene Berdnikov


--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2012052017...@sie.protva.ru

["Артём Н."]

20.05.2012 21:00, Eugene Berdnikov пишет:

> On Sun, May 20, 2012 at 07:58:40PM +0400, "Артём Н." wrote:
>> 20.05.2012 15:41, Eugene Berdnikov пишет:
>>> Запишите в файлики выдачу "sysctl -a | fgrep eth1" и "ip route list"
>>> и сравните для вариантов с nm и ifupdown.
>>>
>>> Для случая с nm ещё хорошо бы записать дамп трафика на eth1,
>>> чтобы убедиться, что пакеты (не) вылетают из eth1, а обратные
>>> пакеты идут на mac интерфейса (или на другой mac). Учтите, что
>>> tcpdump, запущенный без -p, сам переводит интерфейс в promisc.
>>
>> Всё-равно не понятно.
>>
>> Различия:
>> < net.ipv6.conf.eth1.accept_ra = 2
>> ---
>>> net.ipv6.conf.eth1.accept_ra = 0
>> 85,88d84
>> < net.decnet.conf.eth1.priority = 0
>> < net.decnet.conf.eth1.t2 = 1
>> < net.decnet.conf.eth1.t3 = 10
>> < net.decnet.default_device = eth1
>> 92,93d87
>> < default via 192.168.1.1 dev eth1 proto static
>> < 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.3
>
> Прежде всего, в случае nm нет никаких маршрутов через eth1.
> Сеть в такой конфигурации работать не будет, это и ежу понятно.

Я добавлял вручную (в случае с nm), по крайней мере, маршрут по умолчанию.
Всё-равно не работало. Маршруты же должны сами установиться, если работает DHCP?
И ещё до этого я задавал настройки конфигурации nm и вручную (в случае с одним
модемом там сложно ошибиться).

> Хотя меня удивляет то, что в дампе видны arp-request'ы, как будто
> кто-то пытается послать юникастовый пакет через eth1 при
> отсутствии маршрута на этот интерфейс... но может быть, я какой-то
> простой причины для arp'а не вспоминаю.

Кстати, модем его видит и arp таблице модема появляется запись.

> Кроме того, в дампе только исходящие пакеты. Вероятно, связи со шлюзом
> просто нет, несмотря на флаги интерфейса UP и RINNING. Хотелось бы
> проверить, правильно ли выставлен duplex или скорость передачи,
> сравните выдачу "mii-tool -v eth1" и "ethtool eth1".

В случае с интерфейсом, поднятым через ifup (с nm проверю завтра):
"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"

> В целом, конечно, клиника... А nm'у поднять какой-нибудь log level можно?

Есть опция log-level...
Вот, что он писал в syslog (где successfull, там уже, видимо, интерфейс был
поднят через ifup на этапе загрузки):
"May 20 11:20:47 dana NetworkManager[3070]: SCPlugin-Ifupdown: init!
May 20 11:20:47 dana NetworkManager[3070]: SCPlugin-Ifupdown:
update_system_hostname
May 20 11:20:47 dana NetworkManager[3070]: SCPluginIfupdown: guessed
connection type (eth1) = 802-3-ethernet
May 20 11:20:47 dana NetworkManager[3070]: SCPlugin-Ifupdown:
update_connection_setting_from_if_block: name:eth1, type:802-3-ethernet,
id:Ifupdown (eth1), uuid: 7b635ed6-2640-7ad8-675d-744db12dd9fa
May 20 11:20:47 dana NetworkManager[3070]: SCPlugin-Ifupdown: adding eth1 to
iface_connections
May 20 11:20:47 dana NetworkManager[3070]: SCPlugin-Ifupdown: adding iface
eth1 to well_known_interfaces
May 20 11:20:47 dana NetworkManager[3070]: SCPlugin-Ifupdown: autoconnect
May 20 11:20:47 dana NetworkManager[3070]: SCPluginIfupdown: management mode:
unmanaged
May 20 11:20:47 dana NetworkManager[3070]: SCPlugin-Ifupdown: devices added
(path: /sys/devices/pci0000:00/0000:00:1c.7/0000:01:00.0/net/eth1, iface: eth1)
May 20 11:20:47 dana NetworkManager[3070]: SCPluginIfupdown: locking wired
connection setting
May 20 11:20:47 dana NetworkManager[3070]: SCPlugin-Ifupdown: devices added
(path: /sys/devices/virtual/net/lo, iface: lo)
May 20 11:20:47 dana NetworkManager[3070]: SCPlugin-Ifupdown: device added
(path: /sys/devices/virtual/net/lo, iface: lo): no ifupdown configuration found.
May 20 11:20:47 dana NetworkManager[3070]: SCPlugin-Ifupdown: end _init.
May 20 11:20:47 dana NetworkManager[3070]: <info> Loaded plugin ifupdown: (C)
2008 Canonical Ltd. To report bugs please use the NetworkManager mailing list.
May 20 11:20:47 dana NetworkManager[3070]: <info> Loaded plugin keyfile: (c)
2007 - 2010 Red Hat, Inc. To report bugs please use the NetworkManager mailing
list.
May 20 11:20:47 dana NetworkManager[3070]: Ifupdown: get unmanaged devices
count: 1
May 20 11:20:47 dana NetworkManager[3070]: SCPlugin-Ifupdown: (26970928) ...
get_connections.
May 20 11:20:47 dana NetworkManager[3070]: SCPlugin-Ifupdown: (26970928) ...
get_connections (managed=false): return empty list.
May 20 11:20:47 dana NetworkManager[3070]: keyfile: parsing eth1 ...
May 20 11:20:47 dana NetworkManager[3070]: keyfile: read connection 'eth1'
May 20 11:20:47 dana NetworkManager[3070]: Ifupdown: get unmanaged devices
count: 1
May 20 11:20:47 dana NetworkManager[3070]: <info> trying to start the modem
manager...
May 20 11:20:47 dana dbus[2099]: [system] Activating service
name='org.freedesktop.ModemManager' (using servicehelper)
May 20 11:20:47 dana NetworkManager[3070]: <info> monitoring kernel firmware
directory '/lib/firmware'.
May 20 11:20:47 dana NetworkManager[3070]: <info> WiFi enabled by radio
killswitch; enabled by state file
May 20 11:20:47 dana NetworkManager[3070]: <info> WWAN enabled by radio
killswitch; enabled by state file
May 20 11:20:47 dana NetworkManager[3070]: <info> WiMAX enabled by radio
killswitch; enabled by state file
May 20 11:20:47 dana NetworkManager[3070]: <info> Networking is enabled by state
file
May 20 11:20:47 dana NetworkManager[3070]: <warn> failed to allocate link cache:
(-10) Operation not supported
May 20 11:20:47 dana NetworkManager[3070]: <info> (eth1): carrier is ON
May 20 11:20:47 dana NetworkManager[3070]: <info> (eth1): new Ethernet device
(driver: 'r8169' ifindex: 2)
May 20 11:20:47 dana NetworkManager[3070]: <info> (eth1): exported as
/org/freedesktop/NetworkManager/Devices/0
May 20 11:20:47 dana NetworkManager[3070]: <info> (eth1): now managed
May 20 11:20:47 dana NetworkManager[3070]: <info> (eth1): device state change:
unmanaged -> unavailable (reason 'managed') [10 20 2]
May 20 11:20:47 dana NetworkManager[3070]: <info> (eth1): preparing device.
May 20 11:20:47 dana NetworkManager[3070]: <info> (eth1): deactivating device
(reason 'managed') [2]
May 20 11:20:47 dana NetworkManager[3070]: <warn> bluez error getting default
adapter: The name org.bluez was not provided by any .service files
May 20 11:20:47 dana NetworkManager[3070]: <info> (eth1): device state change:
unavailable -> disconnected (reason 'none') [20 30 0]
May 20 11:20:47 dana NetworkManager[3070]: <info> Auto-activating connection 'eth1'.
May 20 11:20:47 dana NetworkManager[3070]: <info> Activation (eth1) starting
connection 'eth1'
May 20 11:20:47 dana NetworkManager[3070]: <info> (eth1): device state change:
disconnected -> prepare (reason 'none') [30 40 0]
May 20 11:20:47 dana NetworkManager[3070]: <info> Activation (eth1) Stage 1 of 5
(Device Prepare) scheduled...
May 20 11:20:47 dana NetworkManager[3070]: <info> Activation (eth1) Stage 1 of 5
(Device Prepare) started...
May 20 11:20:47 dana NetworkManager[3070]: <info> Activation (eth1) Stage 2 of 5
(Device Configure) scheduled...
May 20 11:20:47 dana NetworkManager[3070]: <info> Activation (eth1) Stage 1 of 5
(Device Prepare) complete.
May 20 11:20:47 dana NetworkManager[3070]: <info> Activation (eth1) Stage 2 of 5
(Device Configure) starting...
May 20 11:20:47 dana NetworkManager[3070]: <info> (eth1): device state change:
prepare -> config (reason 'none') [40 50 0]
May 20 11:20:47 dana NetworkManager[3070]: <info> Activation (eth1) Stage 2 of 5
(Device Configure) successful."

Ещё, я заметил интересную запись (device state change: ip-config -> failed
(reason 'ip-config-unavailable')):
"May 20 10:36:46 dana NetworkManager[2855]: <warn> (eth1): DHCPv4 request timed out.
May 20 10:36:46 dana NetworkManager[2855]: <info> (eth1): canceled DHCP
transaction, DHCP client pid 2949
May 20 10:36:46 dana NetworkManager[2855]: <info> Activation (eth1) Stage 4 of 5
(IPv4 Configure Timeout) scheduled...
May 20 10:36:46 dana NetworkManager[2855]: <info> Activation (eth1) Stage 4 of 5
(IPv4 Configure Timeout) started...
May 20 10:36:46 dana NetworkManager[2855]: <info> (eth1): device state change:
ip-config -> failed (reason 'ip-config-unavailable') [70 120 5]
May 20 10:36:46 dana NetworkManager[2855]: <warn> Activation (eth1) failed.
May 20 10:36:46 dana NetworkManager[2855]: <info> Activation (eth1) Stage 4 of 5
(IPv4 Configure Timeout) complete.
May 20 10:36:46 dana NetworkManager[2855]: <info> (eth1): device state change:
failed -> disconnected (reason 'none') [120 30 0]
May 20 10:36:46 dana NetworkManager[2855]: <info> (eth1): deactivating device
(reason 'none') [0]
May 20 10:36:47 dana kernel: [ 79.468614] audit_printk_skb: 78 callbacks
suppressed
May 20 10:36:47 dana kernel: [ 79.468616] type=1400 audit(1337495807.763:38):
apparmor="DENIED" operation="file_lock" parent=4273
profile="/usr/lib/iceweasel/iceweasel" name="/home/artiom/.nv/GLCache/0d4f411$
May 20 10:36:49 dana NetworkManager[2855]: <info> Auto-activating connection 'eth1'.
May 20 10:36:49 dana NetworkManager[2855]: <info> Activation (eth1) starting
connection 'eth1'
May 20 10:36:49 dana NetworkManager[2855]: <info> (eth1): device state change:
disconnected -> prepare (reason 'none') [30 40 0]"

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FB93D00...@yandex.ru

[Aleksandr Sytar]

20 мая 2012 г., 22:50 пользователь "Артём Н." <arti...@yandex.ru> написал:

> Я добавлял вручную (в случае с nm), по крайней мере, маршрут по умолчанию.
> Всё-равно не работало. Маршруты же должны сами установиться, если работает DHCP?
> И ещё до этого я задавал настройки конфигурации nm и вручную (в случае с одним
> модемом там сложно ошибиться).

Я бы на вашем месте посмотрел бы еще через dhcpdump что там присылает сервер.

[Eugene Berdnikov]

On Sun, May 20, 2012 at 10:50:40PM +0400, "Артём Н." wrote:
> 20.05.2012 21:00, Eugene Berdnikov пишет:

> > Прежде всего, в случае nm нет никаких маршрутов через eth1.
> > Сеть в такой конфигурации работать не будет, это и ежу понятно.
> Я добавлял вручную (в случае с nm), по крайней мере, маршрут по умолчанию.
> Всё-равно не работало. Маршруты же должны сами установиться, если работает DHCP?

Он не работает, в том смысле что никаких входящих пакетов в дампе не видно.
Собственно, это и наводит на подозрения о нестыковке скорости/дуплекса.

> > Хотя меня удивляет то, что в дампе видны arp-request'ы, как будто
> > кто-то пытается послать юникастовый пакет через eth1 при
> > отсутствии маршрута на этот интерфейс... но может быть, я какой-то
> > простой причины для arp'а не вспоминаю.
> Кстати, модем его видит и arp таблице модема появляется запись.

Кстати, модем умеет хотя бы пинговать соседний хост?
Если да, пустите пинг на 192.168.1.3 и посмотрите, видны ли эти
пакеты в дампе. Если да, пришлите кусок этого дампа (желательно
в виде файла, записанного по -w, а не распечатки).

> > В целом, конечно, клиника... А nm'у поднять какой-нибудь log level можно?
> Есть опция log-level...
> Вот, что он писал в syslog (где successfull, там уже, видимо, интерфейс был

К сожалению, причины переходов между различными состояниями nm из лога
непонятны... :( К тому же присланный лог заканчивается на "stage 2 of 5",
возможно, на этом месте nm клинит и это есть бага.
--
Eugene Berdnikov

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2012052021...@sie.protva.ru

["Артём Н."]

20.05.2012 23:37, Aleksandr Sytar пишет:

Когда я запускаю dhcpdump, он подключается. Возможно он его в promisc переключает.
Последовательность действий:
"ifconfig eth1 -promisc
Обрываю подключение.
Нажимаю иконку подключения в апплете.
Дохнет на 'Setting up address'.
dchpdump -i eth1
Получает адрес и подключается."
Лог прикладываю.

["Артём Н."]

21.05.2012 01:52, Eugene Berdnikov пишет:

> К сожалению, причины переходов между различными состояниями nm из лога
> непонятны... :( К тому же присланный лог заканчивается на "stage 2 of 5",
> возможно, на этом месте nm клинит и это есть бага.

Да, замечу, что соединения нет, если вырубить promisc, при уже "налаженном"
(видимо, не до конца) соединении с помощью nm.
Т.е.: включаю promisc, соединение есть, отправляю почту, выключаю promisc,
соединения нет (ничего даже не пингуется). Удобства. :-\
С ifup - всё отлично работает без promisc.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FBA15E...@yandex.ru

["Артём Н."]

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 из лога
> непонятны... :( К тому же присланный лог заканчивается на "stage 2 of 5",
> возможно, на этом месте nm клинит и это есть бага.

И ещё (после перезагрузки всё работает):

"root@dana:~# ifconfig eth1 -promisc

root@dana:~# chmod +x /etc/init.d/network
networking network-manager
root@dana:~# chmod +x /etc/init.d/networking

root@dana:~# service network-manager stop
[ ok ] Stopping network connection manager: NetworkManager.

root@dana:~# service networking start
[....] Configuring network interfaces...Internet Systems Consortium DHCP Client

4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/aa:00:04:00:0a:04
Sending on LPF/eth1/aa:00:04:00:0a:04
Sending on Socket/fallback
DHCPREQUEST on eth1 to 255.255.255.255 port 67
DHCPNAK from 192.168.1.1
Reloading /etc/samba/smb.conf: smbd only.
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 3

DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 5

DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 19

DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 14

DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 2

No DHCPOFFERS received.
Unable to obtain a lease on first try. Exiting.
Failed to bring up eth1.
Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/aa:00:04:00:0a:04
Sending on LPF/eth1/aa:00:04:00:0a:04
Sending on Socket/fallback
DHCPREQUEST on eth1 to 255.255.255.255 port 67
DHCPNAK from 192.168.1.1
Reloading /etc/samba/smb.conf: smbd only.

DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8

DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 9

DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 10

^C^C
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 16
^C^C^CTerminated

Failed to bring up eth1.

root@dana:~# # Тут я убил dhclient

root@dana:~# ifconfig eth1 promisc

root@dana:~# service networking restart
[warn] Running /etc/init.d/networking restart is deprecated because it may not
re-enable some interfaces ... (warning).
[....] Reconfiguring network interfaces...Internet Systems Consortium DHCP
Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/aa:00:04:00:0a:04
Sending on LPF/eth1/aa:00:04:00:0a:04
Sending on Socket/fallback
DHCPREQUEST on eth1 to 255.255.255.255 port 67
DHCPNAK from 192.168.1.1
Reloading /etc/samba/smb.conf: smbd only.

DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8

DHCPREQUEST on eth1 to 255.255.255.255 port 67

DHCPOFFER from 192.168.1.1
DHCPACK from 192.168.1.1
Reloading /etc/samba/smb.conf: smbd only.
bound to 192.168.1.3 -- renewal in 38542 seconds.
ifup: interface eth1 already configured
done.
root@dana:~# ping ya.ru
PING ya.ru (213.180.204.3) 56(84) bytes of data.
64 bytes from www.yandex.ru (213.180.204.3): icmp_req=1 ttl=52 time=30.8 ms
^C
--- ya.ru ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 30.820/30.820/30.820/0.000 ms

root@dana:~# ifconfig eth1 -promisc

root@dana:~# ping ya.ru
^C
root@dana:~# ping ya.ru
ping: unknown host ya.ru"

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FBA1744...@yandex.ru

[Eugene Berdnikov]

On Mon, May 21, 2012 at 02:04:05PM +0400, "Артём Н." wrote:
> 21.05.2012 01:52, Eugene Berdnikov пишет:

> > Собственно, это и наводит на подозрения о нестыковке скорости/дуплекса.

> Да, я понимаю. Я про то, что если бы работал DHCP, всё бы установилось.

Да.

> А если нестыковки на физическом уровне, почему работает promisc?

Поиск вслепую... Изменение режима чипа на promisc может непредсказуемо
изменить поведение трансивера, в частности, никто не гарантирует что
чип не начнёт вдруг принимать пакеты, которые он раньше не принимал
из-за рассогласования скоростей.

> Да и модем его видит (в arp таблице модема правильный MAC).

Модем может ловить бродкасты и заполнять по ним таблицу mac'ов.
Так свитчи работают. Странно то, что от модема никаких пакетов не видно.

> Пинг не прошёл, я перезапустил tcpdump и повторно попытался пропинговать, лог
> приложил (tcpdump -w).

В нём ни одного пакета от 192.168.1.1. Хотя есть от 192.168.1.2,
и это удивительно, потому что изернетина фактически работает.

> В случае со включенным 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.

Кстати, мы всё рассуждаем про eth1, а что с eth0? Существует ли он,
подключен ли к сети, если да, то не к той же случайно?

> > К сожалению, причины переходов между различными состояниями nm из лога
> > непонятны... :( К тому же присланный лог заканчивается на "stage 2 of 5",
> > возможно, на этом месте nm клинит и это есть бага.

> Что вообще делает nm? Запускает скрипты из networking, аналогично ifup?

Я nm не щупал, и судя по его логу, видеть его у себя не очень-то желаю. :)

--
Eugene Berdnikov


--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2012052110...@protva.ru

[Eugene Berdnikov]

On Mon, May 21, 2012 at 03:08:01PM +0400, "Артём Н." wrote:
> 21.05.2012 14:41, Eugene Berdnikov пишет:

> > чип не начнёт вдруг принимать пакеты, которые он раньше не принимал
> > из-за рассогласования скоростей.

> Хм... Надо же. А про конкретный чип это возможно сказать (ниже его данные)?

Не скажу. Вообще это из области глюков. К сожалению, с оборудованием
по объективным причинам сложно работать: в микросхему щупы не очень-то
вставишь и осциллограф не подключишь, как там перекашивает каскады
при включении какого-то регистра не узнаешь... поэтому глюки железа
на порядок сложнее глюков программ, иногда просто мозги выносит.

> > В нём ни одного пакета от 192.168.1.1. Хотя есть от 192.168.1.2,
> > и это удивительно, потому что изернетина фактически работает.

> Да, 192.168.1.2 - ноут с w7 (самба пытается с ним состыковаться).

А как он подключен? Между 192.168.1.3 и 192.168.1.2 есть свитч,
в него вставлен модем? Или это встроенный свитч в модеме?

> >> В случае со включенным 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

Интересует с неработающей. Наверное, там будет полная иллюзия рабочей
системы, но хочется искренне этому удивиться. :)

> > Кстати, мы всё рассуждаем про eth1, а что с eth0? Существует ли он,
> > подключен ли к сети, если да, то не к той же случайно?

> Кстати, хотел вас об этом спросить. :-)
...
> Я вкомпилил два драйвера (на всякий случай):
> 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 не работает. И я его сейчас убрал вообще.
> Но вопрос: почему две подсистемы и в чём отличия (я мало знаю по адаптерам)?

Чипы 8168/8169 сильно непохожи на другие риалтеки. У них свой драйвер.

> И почему остался eth1?

Посмотрите содержимое файлика /etc/udev/rules.d/70-persistent-net.rules.
Думаю, там должна быть старая запись для eth0, тогда udev считает, что
имя "eth0" уже занято. Интересно, запись для eth0 отличается от eth1.

У меня, кстати, одно из старых ядер неправильно считывало мак карточки
на r8169 (бился последний октет). В результате слетело назначение имени
интерфейсу. К счастью, интерфейс был мониторинговый, но осадочек остался...

--
Eugene Berdnikov


--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2012052112...@protva.ru

["Артём Н."]

21.05.2012 16:04, Eugene Berdnikov пишет:

> On Mon, May 21, 2012 at 03:08:01PM +0400, "Артём Н." wrote:
>> 21.05.2012 14:41, Eugene Berdnikov пишет:
>>> чип не начнёт вдруг принимать пакеты, которые он раньше не принимал
>>> из-за рассогласования скоростей.
>> Хм... Надо же. А про конкретный чип это возможно сказать (ниже его данные)?
>
> Не скажу. Вообще это из области глюков. К сожалению, с оборудованием
> по объективным причинам сложно работать: в микросхему щупы не очень-то
> вставишь и осциллограф не подключишь, как там перекашивает каскады
> при включении какого-то регистра не узнаешь... поэтому глюки железа
> на порядок сложнее глюков программ, иногда просто мозги выносит.

Есть же наверное средства самотестирования и интерфейсы для отладки?

>>> В нём ни одного пакета от 192.168.1.1. Хотя есть от 192.168.1.2,
>>> и это удивительно, потому что изернетина фактически работает.
>> Да, 192.168.1.2 - ноут с w7 (самба пытается с ним состыковаться).
>
> А как он подключен? Между 192.168.1.3 и 192.168.1.2 есть свитч,
> в него вставлен модем? Или это встроенный свитч в модеме?

Модем D-Link 2600U. Один порт LAN. Ноут подключен по wi-fi, адрес ему
назначается по MAC (всегда 192.168.1.2), поскольку он прописан в hosts.
wlan и lan интерфейсы объединены в одну группу, между ними проброс пакетов.
LAN подключается к br0 (в модеме ещё есть eth0).

>>>> В случае со включенным 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
>
> Интересует с неработающей. Наверное, там будет полная иллюзия рабочей
> системы, но хочется искренне этому удивиться. :)

Сейчас пока мне ещё кое-что надо доделать. Потом скину дамп.

>>> Кстати, мы всё рассуждаем про eth1, а что с eth0? Существует ли он,
>>> подключен ли к сети, если да, то не к той же случайно?
>> Кстати, хотел вас об этом спросить. :-)
> ...
>> Я вкомпилил два драйвера (на всякий случай):
>> 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 не работает. И я его сейчас убрал вообще.
>> Но вопрос: почему две подсистемы и в чём отличия (я мало знаю по адаптерам)?
> Чипы 8168/8169 сильно непохожи на другие риалтеки. У них свой драйвер.

>> И почему остался eth1?
>
> Посмотрите содержимое файлика /etc/udev/rules.d/70-persistent-net.rules.
> Думаю, там должна быть старая запись для eth0, тогда udev считает, что
> имя "eth0" уже занято. Интересно, запись для eth0 отличается от eth1.

Действительно - udev. o.O
Запись отличается MAC.

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="14:da:e9:24:b8:64", ATTR{dev_id}=="0x0", ATTR{type}=="1",
KERNEL=="eth*", NAME="eth0"

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:0b:e0:f0:00:ed", ATTR{dev_id}=="0x0", ATTR{type}=="1",
KERNEL=="eth*", NAME="eth1"

Но ещё более интересно, что MAC сейчас:
eth1 Link encap:Ethernet HWaddr aa:00:04:00:0a:04

И что это? Почему MAC разные? И почему создаётся eth1, что MAC переназначается?

> У меня, кстати, одно из старых ядер неправильно считывало мак карточки
> на r8169 (бился последний октет). В результате слетело назначение имени
> интерфейсу. К счастью, интерфейс был мониторинговый, но осадочек остался...

Ядро 3.2.17. Вроде, всё правильно... Ошибок не заметил, скорость соединения 6-7
Мбит (для текущего ADSL - более ли менее). Модем в статистике ни дропов, ни
ошибок LAN не показывает.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FBA343A...@yandex.ru

[Eugene Berdnikov]

On Mon, May 21, 2012 at 04:25:30PM +0400, "Артём Н." wrote:
> 21.05.2012 16:04, Eugene Berdnikov пишет:
> > On Mon, May 21, 2012 at 03:08:01PM +0400, "Артём Н." wrote:
> >> 21.05.2012 14:41, Eugene Berdnikov пишет:
> >>> чип не начнёт вдруг принимать пакеты, которые он раньше не принимал
> >>> из-за рассогласования скоростей.
> >> Хм... Надо же. А про конкретный чип это возможно сказать (ниже его данные)?
> >
> > Не скажу. Вообще это из области глюков. К сожалению, с оборудованием
> > по объективным причинам сложно работать: в микросхему щупы не очень-то
> > вставишь и осциллограф не подключишь, как там перекашивает каскады
> > при включении какого-то регистра не узнаешь... поэтому глюки железа
> > на порядок сложнее глюков программ, иногда просто мозги выносит.
> Есть же наверное средства самотестирования и интерфейсы для отладки?

Боюсь, там даже для разработчиков чипов мало что сделано...

> Модем D-Link 2600U. Один порт LAN. Ноут подключен по wi-fi, адрес ему
> назначается по MAC (всегда 192.168.1.2), поскольку он прописан в hosts.
> wlan и lan интерфейсы объединены в одну группу, между ними проброс пакетов.
> LAN подключается к br0 (в модеме ещё есть eth0).

То есть комп через модем работает, а сам модем нет? Класс! :))
Чувствую, это капитальная клиника. Но давайте всё же дождёмся дампа.

> Запись отличается MAC.
>
> # PCI device 0x10ec:0x8168 (r8169)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="14:da:e9:24:b8:64", ATTR{dev_id}=="0x0", ATTR{type}=="1",
> KERNEL=="eth*", NAME="eth0"
>
> # PCI device 0x10ec:0x8168 (r8169)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:0b:e0:f0:00:ed", ATTR{dev_id}=="0x0", ATTR{type}=="1",
> KERNEL=="eth*", NAME="eth1"
>
> Но ещё более интересно, что MAC сейчас:
> eth1 Link encap:Ethernet HWaddr aa:00:04:00:0a:04
>
> И что это? Почему MAC разные? И почему создаётся eth1, что MAC переназначается?

Скорее всего это баги драйвера, который при разных вариантах компиляции
ядра показывает разный мусор вместо того, что написано в eeprom...
Хотя возможна и порча eeprom'а. К сожалению, драйвер r8169 не поддерживает
чтение eeprom'a, можно лишь посмотреть ethtool -d, но это может оказаться
искажённой информацией.
--
Eugene Berdnikov

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2012052112...@protva.ru

[Ilya Yanok]

On 21.05.2012 15:08, "Артём Н." wrote:
>> Кстати, мы всё рассуждаем про eth1, а что с eth0? Существует ли он,
>> подключен ли к сети, если да, то не к той же случайно?

> Кстати, хотел вас об этом спросить. :-)

> Ядро самосборное (изначально с oldconfig). Всё, что не нужно выкинуто. Всё, в
> чём сомневался, - оставил модулем.
> Как я понял, есть PHY и M-II подсистемы.

Нет.
Подсистема PHY одна. Почти все (а может и вообще все) современные
Эзернеты состоят из двух чипов: MAC и PHY, связанных между собой шиной
MDIO (конфигурация и служебная информация) и (каким-нибудь вариантов)
MII (данные). При этом чипы вовсе не должны быть одного производителя.

> Изначально (при установке на дистр. ядре) был eth0.
> После какого-то из изменений стал eth1.

Это, скорее всего, значит, что у карточки поменялся MAC. Повод задуматься.

> Я вкомпилил два драйвера (на всякий случай):
> 1. "Drivers for Realtek PHYs". (Supports the Realtek 821x PHY.)

PHY у Вас может быть совершенно другого производителя.

> 2. "Realtek 8169 gigabit ethernet support" (CONFIG_R8169) (Realtek 8169 PCI
> Gigabit Ethernet adapter).
>
> Очевидно, что PHY не работает. И я его сейчас убрал вообще.

Очевидно как раз обратное. При неработающем PHY у Вас не прошла бы
негоциация, да и вообще карта не смогла бы ничего не отправить, не
получить. Другое дело, что, возможно, работает оно вовсе не
реалтековским драйвером, а с generic.

> Но вопрос: почему две подсистемы и в чём отличия (я мало знаю по адаптерам)?

> И почему остался eth1?

Как я уже написал: это уж точно не из-за драйвера PHY. Драйвер PHY -- не
есть драйвер сетевой карты, он не может появиться, как интерфейс. Скорее
всего, интерфейс Вам переименовывает udev. Насколько мне известно, это
может быть только при смене MAC адреса. Это факт No1.
Факт No2: где-то в Ваших логах был кусок вида
DHCPREQUEST
DHCPNACK
то есть
а. Обмен пакетами прошёл успешно.
б. Сервер отказался выдать адрес, который хост запомнил с прошлого
раза, т.е. скорее всего, сервер считает, что этот адрес отдан другому MAC'у.
Факт No3: Promisc помогает.
Факт No4: Как Вы сами пишете, точно так же может не работать и ifupdown,
а после перезагрузки снова работать.

Всё это заставляет меня думать, что неправильно идентифицировали
источник проблемы, как nm, а реально у вас глючит карточка (возможно,
"плавает" MAC адрес в EEPROM'е). Попробуйте задавать MAC руками.

--
Илья

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/jpdem9$r23$1...@dough.gmane.org

["Артём Н."]

21.05.2012 17:07, Ilya Yanok пишет:

> On 21.05.2012 15:08, "Артём Н." wrote:
>>> Кстати, мы всё рассуждаем про eth1, а что с eth0? Существует ли он,
>>> подключен ли к сети, если да, то не к той же случайно?
>> Кстати, хотел вас об этом спросить. :-)
>> Ядро самосборное (изначально с oldconfig). Всё, что не нужно выкинуто. Всё, в
>> чём сомневался, - оставил модулем.
>> Как я понял, есть PHY и M-II подсистемы.
>
> Нет.
> Подсистема PHY одна. Почти все (а может и вообще все) современные
> Эзернеты состоят из двух чипов: MAC и PHY, связанных между собой шиной
> MDIO (конфигурация и служебная информация) и (каким-нибудь вариантов)
> MII (данные). При этом чипы вовсе не должны быть одного производителя.

>> Изначально (при установке на дистр. ядре) был eth0.
>> После какого-то из изменений стал eth1.
>
> Это, скорее всего, значит, что у карточки поменялся MAC. Повод задуматься.

Задуматься о чём? Вероятно проблемы с EEPROM? Или ещё есть причины?
Почему он мог поменяться?
У меня были следующие "события":
1. Я неудачно перепрошил BIOS, используя flashrom (не почитал ман и вывод
flashrom -l). Микросхему пришлось нести на программатор.
2. Был dist-upgrade на testing (обновлённый в stable драйвер для видюхи у меня
не компилился на обновлённом ведре).

>> Я вкомпилил два драйвера (на всякий случай):
>> 1. "Drivers for Realtek PHYs". (Supports the Realtek 821x PHY.)
>
> PHY у Вас может быть совершенно другого производителя.
>
>> 2. "Realtek 8169 gigabit ethernet support" (CONFIG_R8169) (Realtek 8169 PCI
>> Gigabit Ethernet adapter).
>>
>> Очевидно, что PHY не работает. И я его сейчас убрал вообще.
>
> Очевидно как раз обратное. При неработающем PHY у Вас не прошла бы
> негоциация, да и вообще карта не смогла бы ничего не отправить, не
> получить. Другое дело, что, возможно, работает оно вовсе не
> реалтековским драйвером, а с generic.

Хм... Т.е. драйвер для адаптера "разделяется" на два: для PHY (в моём случае -
это generic, поскольку "PHY Device support and infrastructure" выключен в ядре)
и драйвер для шины M-II (это драйвер r8169, он у меня вкомпилирован в ядро)?

>> Но вопрос: почему две подсистемы и в чём отличия (я мало знаю по адаптерам)?
>> И почему остался eth1?
>
> Как я уже написал: это уж точно не из-за драйвера PHY. Драйвер PHY -- не
> есть драйвер сетевой карты, он не может появиться, как интерфейс. Скорее
> всего, интерфейс Вам переименовывает udev. Насколько мне известно, это
> может быть только при смене MAC адреса. Это факт No1.
> Факт No2: где-то в Ваших логах был кусок вида
> DHCPREQUEST
> DHCPNACK
> то есть
> а. Обмен пакетами прошёл успешно.
> б. Сервер отказался выдать адрес, который хост запомнил с прошлого
> раза, т.е. скорее всего, сервер считает, что этот адрес отдан другому MAC'у.
> Факт No3: Promisc помогает.
> Факт No4: Как Вы сами пишете, точно так же может не работать и ifupdown,
> а после перезагрузки снова работать.
>
> Всё это заставляет меня думать, что неправильно идентифицировали
> источник проблемы, как nm

Это действительно не nm (я выключил nm и networking и попробовал запустить
networking на загруженной системе):
"root@dana:~# ping 192.168.1.1
connect: Network is unreachable

root@dana:~# chmod +x /etc/init.d/networking

root@dana:~# service networking start
[....] Configuring network interfaces...Internet Systems Consortium DHCP Client

4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/aa:00:04:00:0a:04
Sending on LPF/eth0/aa:00:04:00:0a:04
Sending on Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
^C
^CDHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
^CDHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
Terminated
Failed to bring up eth0.

root@dana:~# ifconfig -a
eth0 Link encap:Ethernet HWaddr aa:00:04:00:0a:04

inet6 addr: fe80::a800:4ff:fe00:a04/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:88 errors:0 dropped:0 overruns:0 frame:0
TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5280 (5.1 KiB) TX bytes:3170 (3.0 KiB)

Interrupt:45 Base address:0x8000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:46 errors:0 dropped:0 overruns:0 frame:0
TX packets:46 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2699 (2.6 KiB) TX bytes:2699 (2.6 KiB)

vmnet0 Link encap:Ethernet HWaddr 00:50:56:c0:00:00
inet addr:192.168.62.1 Bcast:192.168.62.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fec0:0/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

root@dana:~# ping 192.168.1.1
connect: Network is unreachable
root@dana:~# ifconfig eth0 promisc
root@dana:~# service networking start
[....] Configuring network interfaces...Internet Systems Consortium DHCP Client

4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/aa:00:04:00:0a:04
Sending on LPF/eth0/aa:00:04:00:0a:04
Sending on Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 192.168.1.1
Reloading /etc/samba/smb.conf: smbd only.
bound to 192.168.1.3 -- renewal in 39277 seconds.
Starting Samba daemons: nmbd smbd.
ifup: interface eth0 already configured
done.

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.01 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=0.956 ms

^C
--- 192.168.1.1 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.956/0.987/1.019/0.044 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 ---

3 packets transmitted, 0 received, 100% packet loss, time 2007ms

root@dana:~# ifconfig eth0 promisc
root@dana:~# ll /etc/init.d/network-manager
-rw-r--r-- 1 root root 1,8K Мар 11 2011 /etc/init.d/network-manager
root@dana:~# chmod +x /etc/init.d/network-manager
root@dana:~# service network-manager start
[ ok ] Starting network connection manager: NetworkManager."

> а реально у вас глючит карточка (возможно,
> "плавает" MAC адрес в EEPROM'е). Попробуйте задавать MAC руками.

Но MAC не меняется... И ARP таблице модема такой же MAC, как показывает ifconfig.
К тому же, ifup при загрузке поднимает интерфейс, а nm - нет. Почему?

В чём разница между запуском networking во время загрузки и после?
Могут ли "фенечки" (типа snort и подобного) менять MAC? o.O

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FBA87F...@yandex.ru

["Артём Н."]

21.05.2012 17:07, Ilya Yanok пишет:

> Факт No4: Как Вы сами пишете, точно так же может не работать и ifupdown,
> а после перезагрузки снова работать.
>
> Всё это заставляет меня думать, что неправильно идентифицировали
> источник проблемы, как nm, а реально у вас глючит карточка (возможно,
> "плавает" MAC адрес в EEPROM'е). Попробуйте задавать MAC руками.

Да, завтра попробую выключить службы выдернуть провод, загрузиться и сделать
ifup после загрузки. Хотя... Вряд ли поможет.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FBA8B37...@yandex.ru

[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).

Такая же странность со вторым файлом. Вы сами смотрели записанные дампы,
такая ситуация не удивляет? Вы же не видите того трафика, который
генерите своими ручками.

> Для чистоты эксперимента, во втором случае (_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-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2012052208...@protva.ru

["Артём Н."]

22.05.2012 12:58, Eugene Berdnikov пишет:

Так я не дампил в 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

Хорошо. Попозже пришлю результат.

Возможно ли такое, что карточку повредил flashrom, который не поддерживал мать
(а man я не посмотрел и опцию -l не использовал перед прошивкой)?
Ещё и прошивку не ту залил. Окончилось печально: пришлось искать нормальную
прошивку и везти микросхему BIOS на программатор.
Адаптер, понятное дело, встроенный.
Мог ли он быть повреждён? И как лечить? :-(

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FBBA9A0...@yandex.ru

[Andrey Lyubimets]

22.05.2012 21:58, "Артём Н." написал:

>> Возможно, карточка была повреждена при перепрошивке.
>> Хотя я пока не знаю, может ли это как-то объяснять чудеса,
>> которые мы наблюдаем в дампе.
> Возможно ли такое, что карточку повредил flashrom, который не поддерживал мать
> (а man я не посмотрел и опцию -l не использовал перед прошивкой)?
> Ещё и прошивку не ту залил. Окончилось печально: пришлось искать нормальную
> прошивку и везти микросхему BIOS на программатор.
> Адаптер, понятное дело, встроенный.
> Мог ли он быть повреждён? И как лечить? :-(
>
>

Попробуй перешить ещё раз инструментами от производителя платы

--
С уважением, Любимец Андрей Алексеевич

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FBC4571...@nskes.ru

["Артём Н."]

22.05.2012 12:58, Eugene Berdnikov пишет:

> Итак, можно предположить, что есть некий клинический случай асимметричного
> роутинга, когда пакеты почему-то идут не через 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

Логи приложил. Первый (log0), когда сеть не поднялась после hibernation.
Второй (log1), я перезагрузился (nm был включен, networking выключен),
сеть не работала. Установил адаптер в promisc и запустил networking.
Без этого:
"~# sh ss.sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether aa:00:04:00:0a:04 brd ff:ff:ff:ff:ff:ff
inet6 fe80::a800:4ff:fe00:a04/64 scope link
valid_lft forever preferred_lft forever
RTNETLINK answers: Network is unreachable
connect: Network is unreachable
RTNETLINK answers: Network is unreachable
connect: Network is unreachable"

Затем, убрал promisc. Пинга не было.

["Артём Н."]

23.05.2012 06:03, Andrey Lyubimets пишет:

> 22.05.2012 21:58, "Артём Н." написал:
>
>>> Возможно, карточка была повреждена при перепрошивке.
>>> Хотя я пока не знаю, может ли это как-то объяснять чудеса,
>>> которые мы наблюдаем в дампе.
>> Возможно ли такое, что карточку повредил flashrom, который не поддерживал мать
>> (а man я не посмотрел и опцию -l не использовал перед прошивкой)?
>> Ещё и прошивку не ту залил. Окончилось печально: пришлось искать нормальную
>> прошивку и везти микросхему BIOS на программатор.
>> Адаптер, понятное дело, встроенный.
>> Мог ли он быть повреждён? И как лечить? :-(
>>
>>
> Попробуй перешить ещё раз инструментами от производителя платы

Там есть встроенный в BIOS прошивальщик. Перешью старой прошивкой. Но как-то это
всё-равно напрягает после предыдущей прошивки (несмотря на то, что сейчас есть,
где быстро перешить, если что-то полетит). :-|

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FBD0775...@yandex.ru

[Eugene Berdnikov]

On Wed, May 23, 2012 at 07:48:36PM +0400, "Артём Н." wrote:
> Логи приложил. Первый (log0), когда сеть не поднялась после hibernation.
> Второй (log1), я перезагрузился (nm был включен, networking выключен),
> сеть не работала. Установил адаптер в promisc и запустил networking.
> Без этого:
> "~# sh ss.sh
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether aa:00:04:00:0a:04 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::a800:4ff:fe00:a04/64 scope link
> valid_lft forever preferred_lft forever
> RTNETLINK answers: Network is unreachable
> connect: Network is unreachable
> RTNETLINK answers: Network is unreachable
> connect: Network is unreachable"

Это совсем нерабочая конфигурация: даже ip-адреса на eth0 нет...

По логам: тяжёлый случай. Первой рекомендацией будет поставить ядро 3.2.0
из дистрибутива. Слишком много странностей, нужно сократить круг поиска.
Второй будет поставить в машину дополнительную сетевушку и попробовать её.

Наконец, предлагаю ещё раз получить нерабочее состояние системы и
запустить немного изменённый скрипт.

ip addr list
ip route list
ip link set dev eth0 promisc off
ip route flush cache

ip nei flush dev eth0
ip -s nei list
ip -s -t mon all > ipmon.log &
tcpdump -nUlep -i eth0 -w dump.pcap arp or icmp &
sleep 1
ip route get 192.168.1.1
date +%T.%N
ping -n -c2 192.168.1.1
ip -s nei list
sleep 1
date +%T.%N
ping -n -c2 192.168.1.2

ip link set dev eth0 promisc on
ip route flush cache

ip nei flush dev eth0
ip route list
ip -s nei list
ip route get 192.168.1.1
date +%T.%N
ping -n -c2 192.168.1.1
ip -s nei list
sleep 1

ip link set dev eth0 promisc off

killall tcpdump
killall ip

Пришлите выдачу этого скрипта, а также образовавшиеся файлики
ipmon.log и dump.pcap.

--
Eugene Berdnikov


--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2012052319...@sie.protva.ru

["Артём Н."]

23.05.2012 23:12, Eugene Berdnikov пишет:

> On Wed, May 23, 2012 at 07:48:36PM +0400, "Артём Н." wrote:
>> Логи приложил. Первый (log0), когда сеть не поднялась после hibernation.
>> Второй (log1), я перезагрузился (nm был включен, networking выключен),
>> сеть не работала. Установил адаптер в promisc и запустил networking.
>> Без этого:
>> "~# sh ss.sh
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
>> inet6 ::1/128 scope host
>> valid_lft forever preferred_lft forever
>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
>> qlen 1000
>> link/ether aa:00:04:00:0a:04 brd ff:ff:ff:ff:ff:ff
>> inet6 fe80::a800:4ff:fe00:a04/64 scope link
>> valid_lft forever preferred_lft forever
>> RTNETLINK answers: Network is unreachable
>> connect: Network is unreachable
>> RTNETLINK answers: Network is unreachable
>> connect: Network is unreachable"
>
> Это совсем нерабочая конфигурация: даже ip-адреса на eth0 нет...

Это было до запуска скрипта networking (точнее, после запуска, при отключенном
promisc). Во втором логе я привёл уже "рабочую".

В пятницу-субботу сделаю (сейчас просто не до этого).

А имеется ли техническая возможность повредить сетевуху, при перепрошивке BIOS
flashrom-ом?
Или это может быть глючный новый BIOS?

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FBE56E8...@yandex.ru

[Eugene Berdnikov]

On Thu, May 24, 2012 at 07:42:32PM +0400, "Артём Н." wrote:
> А имеется ли техническая возможность повредить сетевуху, при перепрошивке BIOS
> flashrom-ом? Или это может быть глючный новый BIOS?

Думаю, интегрированное оборудование повредить вполне возможно.
Я не удивлюсь, если eeprom той интегрированной карточки -- это
не отдельная микросхема, а часть eeprom'а материнской платы,
который хранит в себе BIOS.

Судя по тем макам, которые сохранились в кэше udev'а, изначально
чип был произведён ASUStek'ом (охотно верю), потом поле вендора
сменилось на "SercoNet Ltd, ISRAEL" (как-то стрёмно), а сейчас там
значится aa:00:04 -- это покойник, Digital Equipment Corporation,
который давно изернетин не производит, тем более риалтековских.
То, что ethtool не идентифицирует чип, тоже очень подозрительно.
--
Eugene Berdnikov

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2012052416...@sie.protva.ru

["Артём Н."]

23.05.2012 23:12, Eugene Berdnikov О©╫О©╫О©╫О©╫О©╫:
> ping -n -c2 192.168.1.2
О©╫О©╫О©╫О©╫. О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FC11E6D...@yandex.ru

[Eugene Berdnikov]

On Sat, May 26, 2012 at 10:16:29PM +0400, "Артём Н." wrote:
> 23.05.2012 23:12, Eugene Berdnikov пишет:

> > По логам: тяжёлый случай. Первой рекомендацией будет поставить ядро 3.2.0
> > из дистрибутива. Слишком много странностей, нужно сократить круг поиска.

> Поставил. Надо в initrd для него модули добавлять. Позже займусь.

По логам и дампам. Клиника, в том смысле, что так сеть в принципе работать
не может. Я почти полностью уверен, что записанный дамп не соответствует
тому, что в действительности пробегает через eth0. Вопрос почему. Думаю,
где-то 90% вероятности, что eeprom карты был так побит при перепрошивке,
что теперь даже угадать трудно, что происходит при включении promis'а...
Вероятность кривизны самосборного ядра я оцениваю в 5%, остальное --
неучтённые факторы, включая странности NetworkManager'а.

Поэтому приоритеты действий меняются так: [1] тестирование с другой
изернетовской карточкой, [2] смена ядра.

> 23.05.2012 23:12, Eugene Berdnikov пишет:
> > ping -n -c2 192.168.1.2
> Блин. Не посмотрел, что вы ноут пинговать пытались. Он был выключен.

Собственно, это уже не столь важно... Можно ковырять дальше, с целью
локализовать проблему: посмотреть дамп трафика на стороннем компьютере,
сравнить статистику захватываемых пакетов со счётчиками интерфейса, и т.п.
Но это долго, нудно, и вряд ли поменяет выводы.

--
Eugene Berdnikov


--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120528090...@protva.ru

["Артём Н."]

28.05.2012 13:04, Eugene Berdnikov пишет:

> On Sat, May 26, 2012 at 10:16:29PM +0400, "Артём Н." wrote:
>> 23.05.2012 23:12, Eugene Berdnikov пишет:
>>> По логам: тяжёлый случай. Первой рекомендацией будет поставить ядро 3.2.0
>>> из дистрибутива. Слишком много странностей, нужно сократить круг поиска.
>> Поставил. Надо в initrd для него модули добавлять. Позже займусь.
>
> По логам и дампам. Клиника, в том смысле, что так сеть в принципе работать
> не может. Я почти полностью уверен, что записанный дамп не соответствует
> тому, что в действительности пробегает через eth0. Вопрос почему. Думаю,
> где-то 90% вероятности, что eeprom карты был так побит при перепрошивке,
> что теперь даже угадать трудно, что происходит при включении promis'а...
> Вероятность кривизны самосборного ядра я оцениваю в 5%

Ну не знаю... Всё с патчами дебиановскими, через make-kpkg. С изначальным
.config от дистрибьютивного ядра.
Была правда одна фигня: я firmware забыл поставить. >< Потом в логах увидел, что
его сетевуха требует и подтянул.

> остальное -- неучтённые факторы, включая странности NetworkManager'а.

Вряд ли nm. Я его отключал. Не поднимается и с ifup после загрузки.
Попробую чуть позже в single-user, до полной загрузки поднять.

> Поэтому приоритеты действий меняются так: [1] тестирование с другой
> изернетовской карточкой, [2] смена ядра.

Лучше перепрошью BIOS. На этой неделе сделаю и отпишусь. На выходных, скорее (а
то после работы - не тянет).

> Собственно, это уже не столь важно... Можно ковырять дальше, с целью
> локализовать проблему: посмотреть дамп трафика на стороннем компьютере,
> сравнить статистику захватываемых пакетов со счётчиками интерфейса, и т.п.
> Но это долго, нудно, и вряд ли поменяет выводы.

Да проще прошивку поменять и посмотреть, что получится. Затем поменять ядро.
Если не прокатит, запустить LiveDVD и, в случае неудачи, радовать саппорт Asus
(потому что, такого быть не должно, в любом случае).

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FC3A391...@yandex.ru

["Артём Н."]

Короче, не фига не понятно.
Я заметил, что после hibernate поднялась сеть.
Когда была эта фигня, естественно, она не понималась.
Проверять не было времени.
Сейчас, когда оно появилось, я просто скачал тот же BIOS с офф. сайта, который
прошивали на программаторе (именно ту же версию). Прошил, используя встроенный
Asus EZ-Flash.
Выключил /etc/init.d/network* .
Загрузился. Сделал sh /etc/init.d/networking start .
Сеть поднялась. %-| Такими темпами, я скоро уйду в монастырь (или в психушку).
Что поменялось (и поменялось ли что-то вообще в результате перепрошивки), я не знаю.

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FD35893...@yandex.ru

["Артём Н."]

Кстати, у меня есть подозрение, что проблема была не в прошивке BIOS и не в
ядре, а в какой-то службе, запускающейся между networking и network-manager.
Следует из того, что ifup не работал, если не был запущен в процессе загрузки, а
n-m не работал вообще. Потом (вероятно после обновления) всё заработало (из
hibernate вышло и поднялась сеть).
Правда, пробовать откатываться я уже не хочу. :-) Однако, это тянет
задуматься... :-(

--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FD7099A...@yandex.ru