Ver status da rede e atualizações automáticas

ignacho disse:

+    tristate "Silan SC92031 PCI Fast Ethernet Adapter driver (EXPERIMENTAL)"

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bf345707299b34de90fbae062eff51e76561eb40

Se puder, tente usar o Linux 3.14, que está disponível no repositórios dos backports. Na verdade, eu não teria muita esperança, só existem 4 commits de diferença...

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=sc92031



Está sim. Tente o seguinte:

sudo rm -Rfv /etc/modprobe.d/via-rhine.conf

sudo nano /etc/default/grub

Na linha GRUB_CMDLINUX você adiciona:

modprobe.blacklist=via-rhine

Salva o arquivo e depois executa:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Renicie e cheque.

lspci -k



00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78)

        Subsystem: VIA Technologies, Inc. VT6102 [Rhine II] Embeded Ethernet Controller on VT8235

        Kernel driver in use: via-rhine

Marcos FRM disse:

Há muuuitos anos, eu usei algumas Silan com Linux e funcionavam tranquilo com o driver nativo. Essa sua placa pode estar bichada.

Essas Silan foram clássicas aqui no Brasil. Fazem companhia às PC-Chips M598LMR na história!

Olha aí (2007):
https://www.hardware.com.br/comunidade/placa-rede/792834/#post3265000 (..."já que recém saiu o 2.6.23"... )
https://www.hardware.com.br/comunidade/realtek8139c-driver/797185/#post3291532

[main]

plugins=ifupdown,keyfile



[ifupdown]

managed=false

Marcos FRM disse:

Se o plugin ifupdown do NM estiver em bom estado (tipo o ifcfg-rh), eu faria:

1 - Desativaria os scripts de configuração de rede. update-rc.d alguma coisa. Veja aí.

sudo service --status-all

[ ? ]  networking

sudo service networking status

sudo service networking status

Usage: /etc/init.d/networking {start|stop|reload|restart|force-reload}

ls /etc/rc5.d

Marcos FRM disse:

Depois, habilitaria o daemon do NM a iniciar com o sistema (se não estivesse assim configurado).

Marcos FRM disse:

Caso o plugin ifupdown não preste, deixaria apenas o plugin keyfile ativo (formato nativo de configuração do NM) e esqueceria o arquivo /etc/network/interfaces. Algum dia esses quirks específicos das distribuições desaparecerão. Quero estar vivo para ver -- pelo menos no Debian 8 já poderemos dizer para rodar o systemctl. Um passo de cada vez.

# update-rc.d -f networking remove

# systemctl status systemd-networkd.service

● systemd-networkd.service - Network Service

   Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; enabled)

   Active: active (running) since Seg 2014-06-02 18:37:43 BRT; 1min 58s ago

     Docs: man:systemd-networkd.service(8)

 Main PID: 225 (systemd-network)

   Status: "Processing requests..."

   CGroup: /system.slice/systemd-networkd.service

           └─225 /usr/lib/systemd/systemd-networkd



Jun 02 18:37:44 PLUTO systemd-networkd[225]: enp12s0: link is up

Jun 02 18:38:49 PLUTO systemd-networkd[225]: enp12s0: carrier on

Jun 02 18:38:55 PLUTO systemd-networkd[225]: enp12s0: IPv4 link-local address 169.254.166.174

Jun 02 18:38:55 PLUTO systemd-networkd[225]: enp12s0: link configured

Marcos FRM disse:

Haha, muito bom, hein? Tipo: hei, init, a quantas anda este serviço aqui? Resposta: não tenho a mínima ideia, malandro. Se vira!

Viva os scripts SysV/LSB/whatever!

Um

# update-rc.d -f networking remove

dá conta do recado, não?

update-rc.d: using dependency based boot sequencing

update-rc.d: error: not enough arguments

usage: update-rc.d [-n] [-f] <basename> remove

       update-rc.d [-n] <basename> defaults [NN | SS KK]

       update-rc.d [-n] <basename> start|stop NN runlvl [runlvl] [...] .

       update-rc.d [-n] <basename> disable|enable [S|2|3|4|5]

        -n: not really

        -f: force



The disable|enable API is not stable and might change in the future.

ignacio@debian:~$ sudo service --status-all

 [ + ]  acpi-fakekey

 [ - ]  acpi-support

 [ + ]  acpid

 [ ? ]  alsa-utils

 [ - ]  anacron

 [ + ]  apparmor

 [ + ]  atd

 [ + ]  avahi-daemon

 [ ? ]  binfmt-support

 [ + ]  bluetooth

 [ - ]  bootlogs

 [ ? ]  bootmisc.sh

 [ ? ]  checkfs.sh

 [ ? ]  checkroot-bootclean.sh

 [ - ]  checkroot.sh

 [ - ]  console-setup

 [ ? ]  cpufrequtils

 [ + ]  cron

 [ + ]  cups

 [ + ]  dbus

 [ + ]  ebtables

 [ + ]  exim4

 [ + ]  gdm3

 [ ? ]  hdparm

 [ - ]  hostname.sh

 [ ? ]  hwclock.sh

 [ - ]  kbd

 [ - ]  keyboard-setup

 [ ? ]  killprocs

 [ ? ]  kmod

 [ + ]  libvirt-bin

 [ + ]  libvirt-guests

 [ ? ]  loadcpufreq

 [ - ]  lvm2

 [ + ]  minissdpd

 [ - ]  motd

 [ ? ]  mountall-bootclean.sh

 [ ? ]  mountall.sh

 [ ? ]  mountdevsubfs.sh

 [ ? ]  mountkernfs.sh

 [ ? ]  mountnfs-bootclean.sh

 [ ? ]  mountnfs.sh

 [ ? ]  mtab.sh

 [ + ]  network-manager

 [ ? ]  networking

 [ + ]  nfs-common

 [ - ]  nvidia-kernel

 [ ? ]  plymouth

 [ ? ]  plymouth-log

 [ ? ]  pppd-dns

 [ - ]  procps

 [ + ]  pulseaudio

 [ ? ]  qemu-kvm

 [ ? ]  rc.local

 [ - ]  rmnologin

 [ + ]  rpcbind

 [ + ]  rsyslog

 [ + ]  saned

 [ ? ]  sendsigs

 [ ? ]  speech-dispatcher

 [ - ]  sudo

 [ + ]  udev

 [ ? ]  udev-mtab

 [ + ]  ufw

 [ ? ]  umountfs

 [ ? ]  umountnfs.sh

 [ ? ]  umountroot

 [ - ]  unattended-upgrades

 [ - ]  urandom

 [ - ]  x11-common

Marcos FRM disse:

# systemctl status systemd-networkd.service

● systemd-networkd.service - Network Service

   Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; enabled)

   Active: active (running) since Seg 2014-06-02 18:37:43 BRT; 1min 58s ago

     Docs: man:systemd-networkd.service(8)

 Main PID: 225 (systemd-network)

   Status: "Processing requests..."

   CGroup: /system.slice/systemd-networkd.service

           └─225 /usr/lib/systemd/systemd-networkd



Jun 02 18:37:44 PLUTO systemd-networkd[225]: enp12s0: link is up

Jun 02 18:38:49 PLUTO systemd-networkd[225]: enp12s0: carrier on

Jun 02 18:38:55 PLUTO systemd-networkd[225]: enp12s0: IPv4 link-local address 169.254.166.174

Jun 02 18:38:55 PLUTO systemd-networkd[225]: enp12s0: link configured

ignacho disse:

O último que resta. Joga no blacklist.conf
[code=rich]install via_rhine /bin/false[/code]https://wiki.archlinux.org/index.php/Kernel_modules#Blacklisting

Agora se nem isso funcionar, sei lá...

________________________

ignacho disse:

Quanto à placa de rede não gerenciável, eu tenho uma outra pista... Poste a saída disto aqui:

[code=rich]less /etc/network/interfaces[/code]

Marcos FRM disse:

Há muuuitos anos, eu usei algumas Silan com Linux e funcionavam tranquilo com o driver nativo. Essa sua placa pode estar bichada.

Essas Silan foram clássicas aqui no Brasil. Fazem companhia às PC-Chips M598LMR na história!

Olha aí (2007):
https://www.hardware.com.br/comunidade/placa-rede/792834/#post3265000 (..."já que recém saiu o 2.6.23"... )
https://www.hardware.com.br/comunidade/realtek8139c-driver/797185/#post3291532

ignacho disse:

Eu tenho uma desconfiança que esse gerenciamento na verdade está sendo bloqueado devido ao uso dos infames scripts de ifupdown. O Debian não usa eles por padrão, mas desconfio que o autor do tópico tenha feito o uso deles e com isso acabou bloqueando o gerenciamento.

Por padrão, o NetworkManager no Debian é configurado para não gerenciar redes ativadas dessa forma. Olhe o que está no arquivo /etc/NetworkManager.conf

[code=rich][main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false[/code]Eu acho uma indecência alterar o valor nesse arquivo false para true, então ao meu ver o certo seria retirar a interface bloqueada (no caso, a eth0) do arquivo /etc/network/interfaces e com isso ele seria gerenciado diretamente pelo NetworkManager.

Freud jr disse:

[code=rich]The loopback network interface
auto lo
iface lo inet loopback

auto dsl-provider
iface dsl-provider inet ppp
pre-up /sbin/ifconfig eth0 up # line maintained by pppoeconf
provider dsl-provider

auto eth0
iface eth0 inet manual[/code]

ignacho disse:

Caramba, atropelei tudo. É, deve perder a configuração sim. Por via das dúvidas, faça um arquivo de backup do /etc/network/interfaces.

Bom, se sua configuração depende de PPPoE, ela pode ser feita via NetworkManager, mas eu não conheço nenhuma ferramenta de linha de comando para isso. A configuração nesse caso é feito via "Configurações de Rede" através do Configurações do sistema do KDE SC (que nada mais é que um frontend para o NetworkManager).

Gostaria de deixar de nota de rodapé aqui o quanto o item de rede das Configurações do sistema do GNOME 3 é ridiculamente incompleto e não permite configurar quase nada. O painel de controle do KDE SC nesse ponto é melhor. Tive que apagar o post anterior que eu eu tinha feito porque eu acabei ficando perdido graças à ineficiência dele (e à minha gripe também ). No GNOME o jeito é apelar para o nm-connection-editor.

Freud jr disse:

Entendi, sem stress .
Mas no meu caso em especial, deixar o NetworkManager como gerenciador fugiu um pouco do que eu queria, que era apenas uma "GUI" para mostrar o status de conexão, e nesse caso, ele vai gerenciar ela.

Mas eu ainda prefiro a boa e velha linha de comando. Mas eu vou testar usar o NetworkManager no pc do pessoal aqui.

Freud jr disse:

Mas além do backup da pasta /etc/network/interfaces, estava pensando em rodar um "dpkg -i pppoeconf-versão.deb". Talvés isso resolva, já que ele vai reinstalar tudo de novo e teoricamente criar novos arquivos. E o arquivo da pasta /etc/network/interfaces poderá ser criado de novo.

O que acha?

Freud jr disse:

Ah!
O Apper já que o sistema está sem sudo, ele para na hora de autenticar para atualizar. O Synaptic não testei, mas deve ocorrer a mesma coisa. OU seja, para o pessoal manter a máquina atualizada, vou precisar ativar o sudo. É a única coisa que sobrou fazer .

ignacho disse:

Adicione como uma conexão do sistema então.

ignacho disse:

Solução furada, ele vai deixar os arquivos de configuração do mesmo jeito. E /etc/network/interfaces não é uma pasta, é um arquivo.

ignacho disse:

Novamente: o Apper não usa nem depende do sudo. Ele depende do polkit. O polkit não depende e nem faz uso do sudo.

E novamente: a requisição de privilégios administrativos só não é feita nos casos de atualização dos programas já instalados. Se você abrir o Apper e clicar em Atualizações, ele não vai te pedir nada. Para instalação de novos programas, ele irá requisitar privilégios administrativos (e ter o sudo ativado significa ter privilégios administrativos).

E novamente (mais uma vez): não confuda o Apper com o update-notifier. O Debian acaba dando prioridade ao update-notifier, então tenha atenção. E o Synaptic não usa polkit, portanto, ele vai requerer que o usuário tenha privilégios administrativos (tanto faz se for su ou sudo).