Re: Передёрнуть cups из командной строки? (Или же GUI для CUPS)

2012-05-21 Пенетрантность Иван Лох
On Mon, May 21, 2012 at 07:57:27AM +0400, Artem Chuprina wrote:
 Mikhail Ramendik - Debian-russian List  @ Sun, 20 May 2012 21:57:14 +0100:
 
  MR Лучше всего было бы сделать команду, которая отменяет все задания и
  MR снимает все паузы. И повесить её на пункт меню icewm.
 
  MR Есть ли такая команда?
 
 Есть.  Только у меня сейчас не стоит cups, и я не могу сказать, какая
 именно.  Подозреваю, что на самом деле это две команды - lp и cancel.

Я не очень понимаю, что такое паузы... Для принтера по-умолчанию 

cancel -a
cupsenable 
cupsaccept

 Ну, скрипт на три строки по вкусу.

-- 
Иван Лох


-- 
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/20120521054408.ga29...@nano.ioffe.rssi.ru



Re: CLI vs. GUI

2012-05-21 Пенетрантность Artem Chuprina
Maksym Tiurin - debian-russian@lists.debian.org  @ Mon, 21 May 2012 08:38:35 
+0300:

Меню организуют структуру команд и
позволяют быстро найти нужную (они не заменяют горячих клавиш), без
использования справки...
 
   MT Представил себе меню emacs со всеми командами.
   MT Ужаснулся. Быстро там найти явно ниче нельзя будет.
 
  Да ладно!  Я иногда включаю menu-bar-mode, когда не помню комбинацию
  клавиш для операции.  И успешно там нахожу.

 MT Все? В меняю всех никогда ИМХО не было. Например режимы для работы с
 MT Version Control Systems очень куцо в меню представлены.

Может быть.  Но это недостаток данного меню, а не возможностей меню
вообще.  У gnus очень развесистые меню, и в них при этом неплохо ищется.


-- 
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/87obpi9hn7@wizzle.ran.pp.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: Запрос

2012-05-21 Пенетрантность Vladimir Kovalev
Здравствуйте .

скажите, новая версия Debian 6.0.5 устанавливается на русском языке ???

-- 
Best regards,
Vladimir Kovalev
skywa...@rambler.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/176682783.20120521200...@rambler.ru



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: Запрос

2012-05-21 Пенетрантность Артём Н.
21.05.2012 13:08, Vladimir Kovalev пишет:
 Здравствуйте .
 
 скажите, новая версия Debian 6.0.5 устанавливается на русском языке ???
http://s019.radikal.ru/i613/1205/d1/6685fc3d399b.png
(версия 6.0.3, но вряд ли они выпилили русский в 6.0.5)

P.S.:
Блин, рассылка аттачи с картинками не принимает?


-- 
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/4fba1b38.2090...@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


-- 
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/20120521104145.ge7...@protva.ru



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?
 
  Поиск вслепую... Изменение режима чипа на promisc может непредсказуемо
  изменить поведение трансивера, в частности, никто не гарантирует что
  чип не начнёт вдруг принимать пакеты, которые он раньше не принимал
  из-за рассогласования скоростей.
Хм... Надо же. А про конкретный чип это возможно сказать (ниже его данные)?

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

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

 В случае со включенным promisc (tcpdump без -p, 192.168.1.1 - модем):
 14:02:09.180374 ARP, Request who-has dana-0 tell 192.168.1.1, length 46
 14:02:09.180390 ARP, Reply dana-0 is-at aa:00:04:00:0a:04 (oui Unknown), 
 length 28
 
  Вот это именно то, что меня интересует, только link level опять не показан.
  Нужен tcpdump -n -e. Лучше пришлите файлик, записанный по -w.
Приложил с работающей системы (опустил интерфейс, поднял, запустил tcpdump -n -e
во время поднятия). С неработающей приложу позже (сегодня или завтра вечером).

  Кстати, мы всё рассуждаем про eth1, а что с eth0? Существует ли он,
  подключен ли к сети, если да, то не к той же случайно?
Кстати, хотел вас об этом спросить. :-)
Ядро самосборное (изначально с oldconfig). Всё, что не нужно выкинуто. Всё, в
чём сомневался, - оставил модулем.
Как я понял, есть PHY и M-II подсистемы.
Изначально (при установке на дистр. ядре) был eth0.
После какого-то из изменений стал eth1.
Я вкомпилил два драйвера (на всякий случай):
1. Drivers for Realtek PHYs. (Supports the Realtek 821x PHY.)
2. Realtek 8169 gigabit ethernet support (CONFIG_R8169) (Realtek 8169 PCI
Gigabit Ethernet adapter).

Очевидно, что PHY не работает. И я его сейчас убрал вообще.
Но вопрос: почему две подсистемы и в чём отличия (я мало знаю по адаптерам)?
И почему остался eth1?

Адаптер:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI
Express Gigabit Ethernet controller (rev 03)
Subsystem: ASUSTeK Computer Inc. M4A785TD Motherboard
Flags: bus master, fast devsel, latency 0, IRQ 45
I/O ports at b800 [size=256]
Memory at 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 из лога
  непонятны... :( К тому же присланный лог заканчивается на stage 2 of 5,
  возможно, на этом месте nm клинит и это есть бага.
 Что вообще делает nm? Запускает скрипты из networking, аналогично ifup?
 
  Я nm не щупал, и судя по его логу, видеть его у себя не очень-то желаю. :)
Мне он, в принципе, тоже не очень нужен.
Только для того, чтобы иконка в трэе отображалась.
И ещё хочется понять, что не так работает.


_tdlog
Description: Binary data


Re: testing обновился :) теперь сеть настраивается иначе

2012-05-21 Пенетрантность Mikhail A Antonov
21.05.2012 07:54, Artem Chuprina пишет:
  MAA auto lo
  MAA iface lo inet loopback
  MAA pre-up /sbin/iptables-restore /etc/iptables.conf

 Вот, кстати, недавно обсуждали.  Я считаю, что место этому вызову никак
 не в interfaces, это должен быть отдельный скрипт, запускаемый до
 networking, или, что более логично, для него должен быть предусмотрен
 штатный коллбэк в networking, а тут это типичный костыль.
А у тебя где правила поднимаются? Так чтобы штатно удобно прикрутить к
любой тачке на debian.

  MAA auto wlan0
  MAA iface wlan0 inet dhcp
  MAA wpa-driver nl80211,wext
  MAA wpa-conf /etc/wpa_supplicant.conf

  MAA И куча сеток в /etc/wpa_supplicant.conf

 А у меня сетки прописаны в конфиге wicd, частью поднимаются
 автомагически, частью вручную (мне отнюдь не всегда надо поднимать
 автомагически интерфейс видимой знакомой сети, тем паче что их иногда
 бывает несколько одновременно.
Я через wpa_gui рулю куда мне прямо сейчас надо подключиться. Для
ненужной сетки можно и disable на неё поставить.
А несколько одновременно - это либо disable одну из них, либо там
роуминг и мне не важно к какой я прицеплен.


  MAA Для IPv4 везде есть dhcp, для IPv6 RA.
  MAA Если где-то нет - мне не сложно руками сказать ip a a 1.2.3.4/24 dev
  MAA eth0; ip r a default via 1.2.3.1
  MAA Если я туда пришёл работать на долго и буду появляться там часто - я с
  MAA высокой долей вероятности подниму dhcpd в одну из первых очередей.

 У меня нетбук.  Он со мной много где ездит.  В результате в большинстве
 мест, чьи сетки у меня прописаны, я не админ, и поднять там dhcpd я не
 могу.  Оно там, правда, почти везде есть, но.
Так и у меня нетбук. Я тоже с ним много где езжу. И почти везде dhcp.
Если его нет - руками поднять не сложно, и если я туда больше не
вернусь, или вернусь пару раз - я не буду заморачиваться, если вернусь -
я или сам подниму там dhcp, потому что админа уволили и теперь там я
админ, либо пообщавшись с вменяемым админом расскажу чем _ему_ dhcp
будет удобнее и помогу поднять.

 Собственно, важно не это.  Важно то, что у него нет неотключаемого или
 трудноотключаемого автоматического выбора там, где мне регулярно нужен
 ручной, и при этом легко и довольно удобно добавляется ранее неизвестная
 WLAN-точка.
Ранее неизвестная точка легко добавляется всё тем же wpa_gui.


-- 
Best regards,
Mikhail
-
WWW: http://www.antmix.pp.ru/
XMPP: ant...@stopicq.ru



signature.asc
Description: OpenPGP digital signature


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



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



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

Очевидно как раз обратное. При неработающем 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-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/jpdem9$r23$1...@dough.gmane.org



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 подсистемы.
 
 Нет.
 Подсистема 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

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



Missing translations for Russian

2012-05-21 Пенетрантность Christian PERRIER
Several packages are missing a proposed debconf translation for your language.

Indeed, if you folks  want to reach 100% in Wheezy for this, you need
to complete these translations:

lxc
condor

-- 



-- 
To UNSUBSCRIBE, email to debian-l10n-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120521053810.gg7...@mykerinos.kheops.frmug.org



Re: Missing translations for Russian

2012-05-21 Пенетрантность Yuri Kozlov
В Mon, 21 May 2012 07:38:10 +0200
Christian PERRIER bubu...@debian.org пишет:

 Several packages are missing a proposed debconf translation for your
 language.
 
 Indeed, if you folks  want to reach 100% in Wheezy for this, you need
 to complete these translations:

 lxc
lxc 90% (9t;1f;0u)
сделаю


 condor
#671510  09 May 2012
потеряли


-- 
Best Regards,
Yuri Kozlov


-- 
To UNSUBSCRIBE, email to debian-l10n-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120521200740.3cd21...@keeper.home.local



Re: collectd 4.10.7-1: Please update debconf PO translation for the package collectd

2012-05-21 Пенетрантность Yuri Kozlov
В Sun, 20 May 2012 22:03:15 +0400
Vladimir Zhbanov vzhba...@gmail.com пишет:

 Координаторы, посмотрите, пожалуйста, diff для перевода (во вложении).

Отлично. Отправите?

-- 
Best Regards,
Yuri Kozlov


-- 
To UNSUBSCRIBE, email to debian-l10n-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120521212452.1505e...@keeper.home.local



[BTS#671510] po-debconf://condor/ru.po

2012-05-21 Пенетрантность Yuri Kozlov
Hello.

Для учёта.

-- 
Best Regards,
Yuri Kozlov


-- 
To UNSUBSCRIBE, email to debian-l10n-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120521213438.56f6b...@keeper.home.local



[BTS#671053] po-debconf://lxc/ru.po

2012-05-21 Пенетрантность Yuri Kozlov
Hello.

Не стал создавать новое сообщение об ошибке.
Оказалось, что имеющий перевод вложили битым.

-- 
Best Regards,
Yuri Kozlov


-- 
To UNSUBSCRIBE, email to debian-l10n-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120521214436.129ed...@keeper.home.local



Re: [BTS#671053] po-debconf://lxc/ru.po

2012-05-21 Пенетрантность Stepan Golosunov
Yuri Kozlov yu...@komyakino.ru writes:
 Оказалось, что имеющий перевод вложили битым.

Это, кстати, грозит всем переводам, отправленным с
Content-Transfer-Encoding: 8bit.

bugs.debian.org замечен в том, что последнюю пару месяцев применяет
перекодировку latin1-utf8 к телу всех проходящих через него
писем. Причём иногда письма пересылаются нормальными, а иногда — уже
битыми. Но на сайт попадают битыми всегда. Вероятно, конкатенируют
письма со строками в utf8 где-нибудь в perl'е.
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666202, 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669097)


-- 
To UNSUBSCRIBE, email to debian-l10n-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pq9xmkkx@sghpc.hn.golosunov.pp.ru



Re: collectd 4.10.7-1: Please update debconf PO translation for the package collectd

2012-05-21 Пенетрантность Vladimir Zhbanov
On Mon, May 21, 2012 at 09:24:52PM +0400, Yuri Kozlov wrote:
...
 Отлично. Отправите?

Попробовал отправить, но, кажется, с кодировкой что-то не так. У меня в
почтовике вроде utf-8 показывается, а на странице
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673890 белиберда
какая-то. Отправлял с помощью reportbug.

-- 
VZh
http://vzhbanov.byethost33.com


-- 
To UNSUBSCRIBE, email to debian-l10n-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120521213751.GB16435@localhost.localdomain