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

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

2012-06-12 Пенетрантность Артём Н.

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


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fd7099a.2050...@yandex.ru

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

2012-05-28 Пенетрантность 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
Блин. Не посмотрел, что вы ноут пинговать пытались. Он был выключен.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120528090440.ge11...@protva.ru

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

2012-05-28 Пенетрантность Артём Н.

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
(потому что, такого быть не должно, в любом случае).

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

2012-05-26 Пенетрантность Артём Н.

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

  Второй будет поставить в машину дополнительную сетевушку и попробовать её.
 
  Наконец, предлагаю ещё раз получить нерабочее состояние системы и
  запустить немного изменённый скрипт.
 
   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.
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
inet 192.168.1.3/24 brd 192.168.1.255 scope global eth0
inet6 fe80::a800:4ff:fe00:a04/64 scope link
   valid_lft forever preferred_lft forever
dnet 1.10/16 scope global eth0
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.3
192.168.1.1 dev eth0  ref 482 used 57/29/11 probes 1 FAILED
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 
bytes
192.168.1.1 dev eth0  src 192.168.1.3
cache
22:09:01.761817708
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

--- 192.168.1.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1007ms
pipe 2
192.168.1.1 dev eth0  ref 484 used 1/33/0 probes 6 FAILED
22:09:05.772485453
PING 192.168.1.2 (192.168.1.2) 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

--- 192.168.1.2 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 999ms
pipe 2
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.3
192.168.1.1 dev eth0  ref 484 used 6/37/4 probes 6 FAILED
192.168.1.2 dev eth0  ref 2 used 2/63/0 probes 6 FAILED
192.168.1.1 dev eth0  src 192.168.1.3
cache
22:09:08.788413224
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.87 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=0.929 ms

--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.929/1.402/1.876/0.474 ms
192.168.1.1 dev eth0 lladdr 00:22:b0:be:bf:e3 ref 488 used 0/0/0 probes 4 
REACHABLE
192.168.1.2 dev eth0  ref 2 used 3/64/1 probes 6 FAILED
17 packets captured
17 packets received by filter
0 packets dropped by kernel


P.S.:
Что это за фигня в логе?

22:09:09.826493 IP dana-0  pppoe-212.104.114.140.armageddon-bg.com: ICMP
dana-0 udp port 6881 unreachable, length 134
22:09:10.281225 IP dana-0  220.172.12.72: ICMP dana-0 udp port 6881
unreachable, length 137
22:09:10.427993 IP dana-0  202.171.254.21: ICMP dana-0 udp port 6881
unreachable, length 171
22:09:10.524994 IP dana-0  n058152219168.netvigator.com: ICMP dana-0 udp port
6881 unreachable, length 137


dump.pcap
Description: application/vnd.tcpdump.pcap
Timestamp: Sat May 26 22:09:04 2012 770055 usec
[NEIGH]192.168.1.1 dev eth0  ref 485 used 1/33/0 probes 6 FAILED
Timestamp: Sat May 26 22:09:08 2012 783409 usec
[NEIGH]192.168.1.2 dev eth0  ref 3 used 2/63/0 probes 6 FAILED
Timestamp: Sat May 26 22:09:08 2012 784265 usec
[LINK]2: eth0: BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP 
link/ether aa:00:04:00:0a:04 brd ff:ff:ff:ff:ff:ff
Timestamp: Sat May 26 22:09:08 2012 790021 usec
[NEIGH]192.168.1.1 dev eth0 lladdr 00:22:b0:be:bf:e3 ref 488 used 0/0/0 probes 4 REACHABLE
Timestamp: Sat May 26 22:09:10 2012 793814 usec
[LINK]2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP 
link/ether aa:00:04:00:0a:04 brd ff:ff:ff:ff:ff:ff

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

2012-05-26 Пенетрантность Артём Н.

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


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fc11e6d.2000...@yandex.ru

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

2012-05-24 Пенетрантность Артём Н.

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). Во втором логе я привёл уже рабочую.

По логам: тяжёлый случай. Первой рекомендацией будет поставить ядро 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.
В пятницу-субботу сделаю (сейчас просто не до этого).

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

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

2012-05-24 Пенетрантность 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

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

2012-05-23 Пенетрантность Артём Н.

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. Пинга не было.
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 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
inet 192.168.1.3/24 brd 192.168.1.255 scope global eth0
inet 192.168.1.4/24 brd 192.168.1.255 scope global secondary eth0
inet6 fe80::a800:4ff:fe00:a04/64 scope link 
   valid_lft forever preferred_lft forever
3: vmnet0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state 
UNKNOWN qlen 1000
link/ether 00:50:56:c0:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.62.1/24 brd 192.168.62.255 scope global vmnet0
inet6 fe80::250:56ff:fec0:0/64 scope link 
   valid_lft forever preferred_lft forever
default via 192.168.1.1 dev eth0  proto static 
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.3 
192.168.62.0/24 dev vmnet0  proto kernel  scope link  src 192.168.62.1 
192.168.1.1 dev eth0  src 192.168.1.3 
cache  ipid 0xaa1c rtt 17ms rttvar 20ms cwnd 10
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 
65535 bytes
19:29:50.631596 Out aa:00:04:00:0a:04 ethertype ARP (0x0806), length 44: 
Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.3, 
length 28
19:29:51.634945 Out aa:00:04:00:0a:04 ethertype ARP (0x0806), length 44: 
Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.3, 
length 28
From 192.168.1.3 icmp_seq=1 Destination Host Unreachable
From 192.168.1.3 icmp_seq=2 Destination Host Unreachable

--- 192.168.1.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1007ms
pipe 2
19:29:52.638311  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 128: (tos 
0xc0, ttl 64, id 21585, offset 0, flags [none], proto ICMP (1), length 112)
192.168.1.3  192.168.1.3: ICMP host 192.168.1.1 unreachable, length 92
(tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.1.3  192.168.1.1: ICMP echo request, id 15456, seq 1, length 64
19:29:52.638320  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 128: (tos 
0xc0, ttl 64, id 21586, offset 0, flags [none], proto ICMP (1), length 112)
192.168.1.3  192.168.1.3: ICMP host 192.168.1.1 unreachable, length 92
(tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.1.3  192.168.1.1: ICMP echo request, id 15456, seq 2, length 64

4 packets captured
6 packets received by filter
0 packets dropped by kernel
192.168.1.1 dev eth0  src 192.168.1.3 
cache  ipid 0xaa1c rtt 17ms rttvar 20ms cwnd 10
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.41 ms
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 
65535 bytes
19:29:53.656411 Out aa:00:04:00:0a:04 ethertype IPv4 (0x0800), length 100: (tos 
0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.1.3  192.168.1.1: ICMP echo request, id 15462, seq 2, length 64
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=0.919 ms

---

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

2012-05-23 Пенетрантность Артём Н.

23.05.2012 06:03, Andrey Lyubimets пишет:
22.05.2012 21:58, Артём Н. написал:

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

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

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

2012-05-23 Пенетрантность 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 нет...

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

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

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

2012-05-22 Пенетрантность 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: 0xfcc0)

 Вот те раз... А должно быть что-то вроде этого:

# ethtool -d mon
RealTek RTL-8169/8110SB registers:

0x00: MAC Address  00:14:d1:15:49:b6
0x08: Multicast Address Filter 0x8480 0x4200
0x10: Dump Tally Counter Command   0x 0x
0x20: Tx Normal Priority Ring Addr 0x3448b000 0x
0x28: Tx High Priority Ring Addr   0xbbcdff00 0xbfff
0x30: Flash memory read/write 0x
0x34: Early Rx Byte Count  0
0x36: Early Rx Status   0x00
0x37: Command   0x00
  Rx off, Tx off
0x3C: Interrupt Mask  0x
  
0x3E: Interrupt Status0x
  
0x40: Tx Configuration0x1000
0x44: Rx Configuration0x0002
0x48: Timer count 0x3c59f6ae
0x4C: Missed packet counter 0x00
0x50: EEPROM Command0x00
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 0x
0x5C: Multiple Interrupt Select   0x
0x60: PHY access  0x800541e1
0x64: TBI control and status  0x
0x68: TBI Autonegotiation advertisement (ANAR)0x
0x6A: TBI Link partner ability (LPAR) 0x
0x6C: PHY status0x0b
0x84: PM wakeup frame 00xbdddc0bd 0xd65dafbf
0x8C: PM wakeup frame 10xb7c72a6e 0xee1af5ff
0x94: PM wakeup frame 2 (low)  0x964d 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

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

2012-05-22 Пенетрантность Артём Н.

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: 0xfcc0)
 
  Вот те раз... А должно быть что-то вроде этого:
 
 # ethtool -d mon
 RealTek RTL-8169/8110SB registers:
 
 0x00: MAC Address  00:14:d1:15:49:b6
 0x08: Multicast Address Filter 0x8480 0x4200
 0x10: Dump Tally Counter Command   0x 0x
 0x20: Tx Normal Priority Ring Addr 0x3448b000 0x
 0x28: Tx High Priority Ring Addr   0xbbcdff00 0xbfff
 0x30: Flash memory read/write 0x
 0x34: Early Rx Byte Count  0
 0x36: Early Rx Status   0x00
 0x37: Command   0x00
   Rx off, Tx off
 0x3C: Interrupt Mask  0x
   
 0x3E: Interrupt Status0x
   
 0x40: Tx Configuration0x1000
 0x44: Rx Configuration0x0002
 0x48: Timer count 0x3c59f6ae
 0x4C: Missed packet counter 0x00
 0x50: EEPROM Command0x00
 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 0x
 0x5C: Multiple Interrupt Select   0x
 0x60: PHY access  0x800541e1
 0x64: TBI control and status  0x
 0x68: TBI Autonegotiation advertisement (ANAR)0x
 0x6A: TBI Link partner ability (LPAR) 0x
 0x6C: PHY status0x0b
 0x84: PM wakeup frame 00xbdddc0bd 0xd65dafbf
 0x8C: PM wakeup frame 10xb7c72a6e 0xee1af5ff
 0x94: PM wakeup frame 2 (low)  0x964d 0x9e9fde5f
 0x9C: PM wakeup frame 2 (high) 0xbac35dfd 0x5f5fda79
 0xA4: PM wakeup frame 3 (low)  0x776ef7df 0xbc7beebf
 0xAC: PM

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

2012-05-22 Пенетрантность Andrey Lyubimets

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

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

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


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fbc4571.2020...@nskes.ru

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

2012-05-21 Пенетрантность Артём Н.

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: 0x0033 (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,

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

2012-05-21 Пенетрантность Артём Н.

20.05.2012 23:37, Aleksandr Sytar пишет:
 20 мая 2012 г., 22:50 пользователь Артём Н. artio...@yandex.ru написал:
 Я добавлял вручную (в случае с nm), по крайней мере, маршрут по умолчанию.
 Всё-равно не работало. Маршруты же должны сами установиться, если работает 
 DHCP?
 И ещё до этого я задавал настройки конфигурации nm и вручную (в случае с 
 одним
 модемом там сложно ошибиться).
 
 Я бы на вашем месте посмотрел бы еще через dhcpdump что там присылает сервер.
Когда я запускаю dhcpdump, он подключается. Возможно он его в promisc 
переключает.
Последовательность действий:
ifconfig eth1 -promisc
Обрываю подключение.
Нажимаю иконку подключения в апплете.
Дохнет на 'Setting up address'.
dchpdump -i eth1
Получает адрес и подключается.
Лог прикладываю.
  TIME: 2012-05-21 14:05:52.353
IP: 0.0.0.0 (aa:0:4:0:a:4)  255.255.255.255 (ff:ff:ff:ff:ff:ff)
OP: 1 (BOOTPREQUEST)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 5ebba93a
  SECS: 0
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: aa:00:04:00:0a:04:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type 3 (DHCPREQUEST)
OPTION:  50 (  4) Request IP address192.168.1.3
OPTION:  12 (  4) Host name dana
OPTION:  55 ( 17) Parameter Request List  1 (Subnet mask)
	 28 (Broadcast address)
	  2 (Time offset)
	  3 (Routers)
	 15 (Domainname)
	  6 (DNS server)
	119 (Domain Search)
	 12 (Host name)
	 44 (NetBIOS name server)
	 47 (NetBIOS scope)
	 26 (Interface MTU)
	121 (Classless Static Route)
	 42 (NTP servers)
	121 (Classless Static Route)
	249 (MSFT - Classless route)
	252 (MSFT - WinSock Proxy Auto Detect)
	 42 (NTP servers)
	
---

  TIME: 2012-05-21 14:05:52.366
IP: 192.168.1.1 (0:22:b0:be:bf:e3)  192.168.1.3 (aa:0:4:0:a:4)
OP: 2 (BOOTPREPLY)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 5ebba93a
  SECS: 0
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 192.168.1.3
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: aa:00:04:00:0a:04:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type 5 (DHCPACK)
OPTION:  54 (  4) Server identifier 192.168.1.1
OPTION:  51 (  4) IP address leasetime  86400 (24h)
OPTION:   1 (  4) Subnet mask   255.255.255.0
OPTION:   3 (  4) Routers   192.168.1.1
OPTION:   6 (  4) DNS server192.168.1.1
---

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

2012-05-21 Пенетрантность Артём Н.

21.05.2012 01:52, Eugene Berdnikov пишет:
  К сожалению, причины переходов между различными состояниями nm из лога
  непонятны... :( К тому же присланный лог заканчивается на stage 2 of 5,
  возможно, на этом месте nm клинит и это есть бага.
Да, замечу, что соединения нет, если вырубить promisc, при уже налаженном
(видимо, не до конца) соединении с помощью nm.
Т.е.: включаю promisc, соединение есть, отправляю почту, выключаю promisc,
соединения нет (ничего даже не пингуется). Удобства. :-\
С ifup - всё отлично работает без promisc.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fba15eb.50...@yandex.ru

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

2012-05-21 Пенетрантность Артём Н.

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-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fba1744.4060...@yandex.ru

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

2012-05-21 Пенетрантность 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

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

2012-05-21 Пенетрантность Артём Н.

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?

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

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

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

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

Вот это именно то, что меня интересует, только 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 d000 (64-bit, prefetchable) [size=4K]
Memory at dfff8000 (64-bit, prefetchable) [size=16K]
Expansion ROM at f5ef [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 не щупал, и судя по его логу, видеть его у себя не очень-то желаю. :)
Мне он, в принципе, тоже не очень нужен.
Только для того, чтобы иконка в трэе отображалась.
И ещё хочется понять, что не так работает.

_tdlog
Description: Binary data

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

2012-05-21 Пенетрантность Eugene Berdnikov

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

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

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

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

Кстати, мы всё рассуждаем про 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.

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

2012-05-21 Пенетрантность Артём Н.

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

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

Очевидно, что PHY не работает. И я его сейчас убрал вообще.
Но вопрос: почему две подсистемы и в чём отличия (я мало знаю по адаптерам)?
Чипы 8168/8169 сильно непохожи на другие риалтеки. У них свой драйвер.

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

# 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 не показывает.

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

2012-05-21 Пенетрантность 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-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120521124706.gg7...@protva.ru

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

2012-05-21 Пенетрантность 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 не работает. И я его сейчас убрал вообще.

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

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

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

--
Илья

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

2012-05-21 Пенетрантность Артём Н.

21.05.2012 16:47, Eugene Berdnikov пишет:
 Модем D-Link 2600U. Один порт LAN. Ноут подключен по wi-fi, адрес ему
 назначается по MAC (всегда 192.168.1.2), поскольку он прописан в hosts.
 wlan и lan интерфейсы объединены в одну группу, между ними проброс пакетов.
 LAN подключается к br0 (в модеме ещё есть eth0).
 
  То есть комп через модем работает, а сам модем нет? Класс! :))
В смысле? Ноут, подключенный по wi-fi, под управлением w7 имеет доступ в
Интернет и пингует модем.
В arp таблице ноута тоже корректный mac компа (ну, понятно, что и у модема).
Arp-таблица на компе:
root@dana:~# arp -a
? (192.168.1.1) at incomplete on eth0
user-pc (192.168.1.2) at incomplete on eth0

  Чувствую, это капитальная клиника. Но давайте всё же дождёмся дампа.
Для _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
root@dana:~# tcpdump -w _tdlog -vv -e -n -i eth0
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 
bytes
^C23 packets captured
23 packets received by filter
0 packets dropped by kernel
root@dana:~# tcpdump -w _tdlog -vv -e -n -i eth0 -p
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 
bytes
^C54 packets captured
54 packets received by filter
0 packets dropped by kernel

При этом, я попытался пропинговать комп с модема, затем с ноута.
Пинги, естественно, не прошли.

Для чистоты эксперимента, во втором случае (_tdlog1), я отключил файрволл:
root@dana:~# ifconfig eth0 -promisc
root@dana:~# service rc.firewall stop
[ ok ] Stopping firewall (/etc/firewall/localfw.fw)...done.
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 ---
11 packets transmitted, 0 received, 100% packet loss, time ms

root@dana:~# tcpdump -w _tdlog -vv -p -e -n -i eth0
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 
bytes
^C70 packets captured
70 packets received by filter
0 packets dropped by kernel

Пинговал с модема и с ноутбука.

 Запись отличается 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...
Но сейчас MAC не меняется между перезагрузками.

  Хотя возможна и порча eeprom'а.
И что, в этом случае, делать?

Кстати, что вообще могло менять скрипт udev?

 К сожалению, драйвер r8169 не поддерживает
  чтение eeprom'a, можно лишь посмотреть ethtool -d, но это может оказаться
  искажённой информацией.
root@dana:~# ethtool -d eth0
Unknown RealTek chip (mask: 0xfcc0)
root@dana:~# ethtool -e eth0
Cannot get EEPROM data: Operation not supported


_tdlog0
Description: Binary data


_tdlog1
Description: Binary data

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

2012-05-21 Пенетрантность Артём Н.

21.05.2012 17:07, Ilya Yanok пишет:
On 21.05.2012 15:08, Артём Н. wrote:
Кстати, мы всё рассуждаем про eth1, а что с eth0? Существует ли он,
подключен ли к сети, если да, то не к той же случайно?
Кстати, хотел вас об этом спросить. :-)
Ядро самосборное (изначально с oldconfig). Всё, что не нужно выкинуто. Всё, в
чём сомневался, - оставил модулем.
Как я понял, есть PHY и M-II подсистемы.

Изначально (при установке на дистр. ядре) был 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?

Всё это заставляет меня думать, что неправильно идентифицировали
источник проблемы, как 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

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

vmnet0Link 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

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

2012-05-21 Пенетрантность Артём Н.

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


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fba8b37.1070...@yandex.ru

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

2012-05-20 Пенетрантность Артём Н.

Есть 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 addressMask Device
192.168.1.3  0x1 0x2 AA:00:04:00:0A:04 *br0

ARP таблица на компьютере:
root@dana:~# arp
Address  HWtype  HWaddress   Flags MaskIface
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 RefUse Iface
default 192.168.1.1 0.0.0.0 UG0  00 eth1
192.168.1.0 *   255.255.255.0   U 0  00 eth1

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


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


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


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fb8963d.8060...@yandex.ru

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

2012-05-20 Пенетрантность Артём Н.

Блин. Это прямой путь в психушку.
После установки 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-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fb8a450.5040...@yandex.ru

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

2012-05-20 Пенетрантность Dmitry A. Zhiglov

2012/5/20 Артём Н. artio...@yandex.ru:
 Блин. Это прямой путь в психушку.
 После установки ifupdown всё снова заработало без promisc.
 Кто-нибудь может объяснить что они такого делают, чего не делает 
 network-manager?

Это в testing?

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

2012-05-20 Пенетрантность Артём Н.

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


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fb8af7d.9000...@yandex.ru

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

2012-05-20 Пенетрантность Артём Н.

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

 Это в testing?
 Угу. Причём, с nm я извращался, как мог. В interfaces отключал eth, всё-равно,
 да и вручную не поднимается.
Да, на всякий случай отключал. Знаю, что ни на что не влияет. Может дело в том,
что ifconfig устанавливает broadcast адрес? К сожалению, вывод ifconfig без
ifupdown я не сохранил, а повторять неохота. Куплю бубен. o.O


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fb8b0d1.4090...@yandex.ru

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

2012-05-20 Пенетрантность Артём Н.

20.05.2012 12:32, Dmitry A. Zhiglov пишет:
 2012/5/20 Артём Н. artio...@yandex.ru:
 Блин. Это прямой путь в психушку.
 После установки ifupdown всё снова заработало без promisc.
 Кто-нибудь может объяснить что они такого делают, чего не делает 
 network-manager?
 
 Это в testing?
Проверил без 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-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fb8b88e.5040...@yandex.ru

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

2012-05-20 Пенетрантность Артём Н.

Кто-нибудь может объяснить, как поднимается эта хренова сеть?
Я поставил 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

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

2012-05-20 Пенетрантность 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-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120520114120.gb3...@sie.protva.ru

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

2012-05-20 Пенетрантность Артём Н.

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: 0x) (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]
(0x)
  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);
# sysctl -a|fgrep eth1

net.ipv4.neigh.eth1.mcast_solicit = 3
net.ipv4.neigh.eth1.ucast_solicit = 3
net.ipv4.neigh.eth1.app_solicit = 0
net.ipv4.neigh.eth1.retrans_time = 99
net.ipv4.neigh.eth1.base_reachable_time = 30
net.ipv4.neigh.eth1.delay_first_probe_time = 5
net.ipv4.neigh.eth1.gc_stale_time = 60
net.ipv4.neigh.eth1.unres_qlen = 3
net.ipv4.neigh.eth1.proxy_qlen = 64
net.ipv4.neigh.eth1.anycast_delay = 99
net.ipv4.neigh.eth1.proxy_delay = 79
net.ipv4.neigh.eth1.locktime = 99
net.ipv4.neigh.eth1.retrans_time_ms = 1000
net.ipv4.neigh.eth1.base_reachable_time_ms = 3
net.ipv4.conf.eth1.forwarding = 0
net.ipv4.conf.eth1.mc_forwarding = 0
net.ipv4.conf.eth1.accept_redirects = 1
net.ipv4.conf.eth1.secure_redirects = 1
net.ipv4.conf.eth1.shared_media = 1
net.ipv4.conf.eth1.rp_filter = 0
net.ipv4.conf.eth1.send_redirects = 1
net.ipv4.conf.eth1.accept_source_route = 1
net.ipv4.conf.eth1.accept_local = 0
net.ipv4.conf.eth1.src_valid_mark = 0
net.ipv4.conf.eth1.proxy_arp = 0
net.ipv4.conf.eth1.medium_id = 0
net.ipv4.conf.eth1.bootp_relay = 0
net.ipv4.conf.eth1.log_martians = 0
net.ipv4.conf.eth1.tag = 0
net.ipv4.conf.eth1.arp_filter = 0
net.ipv4.conf.eth1.arp_announce = 0
net.ipv4.conf.eth1.arp_ignore = 0
net.ipv4.conf.eth1.arp_accept = 0
net.ipv4.conf.eth1.arp_notify = 0
net.ipv4.conf.eth1.proxy_arp_pvlan = 0
net.ipv4.conf.eth1.disable_xfrm = 0
net.ipv4.conf.eth1.disable_policy = 0
net.ipv4.conf.eth1.force_igmp_version = 0
net.ipv4.conf.eth1.promote_secondaries = 0
net.ipv6.neigh.eth1.mcast_solicit = 3
net.ipv6.neigh.eth1.ucast_solicit = 3
net.ipv6.neigh.eth1.app_solicit = 0
net.ipv6.neigh.eth1.retrans_time = 300
net.ipv6.neigh.eth1.base_reachable_time = 30
net.ipv6.neigh.eth1.delay_first_probe_time = 5
net.ipv6.neigh.eth1.gc_stale_time = 60
net.ipv6.neigh.eth1.unres_qlen = 3
net.ipv6.neigh.eth1.proxy_qlen = 64
net.ipv6.neigh.eth1.anycast_delay = 99
net.ipv6.neigh.eth1.proxy_delay = 79
net.ipv6.neigh.eth1.locktime = 0
net.ipv6.neigh.eth1.retrans_time_ms = 1000
net.ipv6.neigh.eth1.base_reachable_time_ms = 3
net.ipv6.conf.eth1.forwarding = 0
net.ipv6.conf.eth1.hop_limit = 64
net.ipv6.conf.eth1.mtu =

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

2012-05-20 Пенетрантность 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

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

2012-05-20 Пенетрантность Артём Н.

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: 0x0033 (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/pci:00/:00:1c.7/: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

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

2012-05-20 Пенетрантность Aleksandr Sytar

20 мая 2012 г., 22:50 пользователь Артём Н. artio...@yandex.ru написал:
 Я добавлял вручную (в случае с nm), по крайней мере, маршрут по умолчанию.
 Всё-равно не работало. Маршруты же должны сами установиться, если работает 
 DHCP?
 И ещё до этого я задавал настройки конфигурации nm и вручную (в случае с одним
 модемом там сложно ошибиться).

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

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

2012-05-20 Пенетрантность Eugene Berdnikov

On Sun, May 20, 2012 at 10:50:40PM +0400, Артём Н. wrote:
20.05.2012 21:00, Eugene Berdnikov пишет:
Прежде всего, в случае nm нет никаких маршрутов через eth1.
Сеть в такой конфигурации работать не будет, это и ежу понятно.
Я добавлял вручную (в случае с nm), по крайней мере, маршрут по умолчанию.
Всё-равно не работало. Маршруты же должны сами установиться, если работает
DHCP?

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

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

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

39 matches

Mail list logo