Re: Передёрнуть cups из командной строки? (Или же GUI для CUPS)
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
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 режиме
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 режиме
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: Запрос
Здравствуйте . скажите, новая версия 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 режиме
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 режиме
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: Запрос
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 режиме
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 режиме
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 обновился :) теперь сеть настраивается иначе
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 режиме
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 режиме
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 режиме
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 режиме
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 режиме
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 режиме
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 режиме
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
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
В 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
В 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
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
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
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
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