wlan0 desce quando eth0 não é usado

Question

Eu tenho o Wheezy build carregado no meu Pi. Eu tenho o meu ethernet com fio configurado com um IP estático e fiz a mesma coisa com o wlan. Quando o fio está sendo usado, o wifi aparece e funciona. No entanto, quando eu desconecto o cabo com fio para que eu possa usar o Pi via Wi-Fi, ele pára de funcionar.

Eu configurei o arquivo de interfaces incorretamente? Parece realmente estranho que pare de funcionar porque o cabo não está conectado. Eu tentei reiniciar sem o cabo conectado ao Pi para confirmar que não era apenas algum tipo de falha quando eu o desconectei enquanto ele estava funcionando, mas só funcionaria se o cabo com fio fosse conectado primeiro.

Aqui está uma cópia do meu arquivo / etc / network / interfaces ...

        auto lo

    iface lo inet loopback

    auto eth0
    iface eth0 inet static
            address 10.0.42.111
            network 10.0.42.0
            netmask 255.255.255.0
            broadcast 10.0.42.255
            gateway 10.0.42.1

    allow-hotplug wlan0
    auto wlan0
    iface wlan0 inet static
            address 10.0.42.112
            network 10.0.42.0
            netmask 255.255.255.0
            broadcast 10.0.42.255
            gateway 10.0.42.1

    wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf

    

Answer 1

Acabei de ter o mesmo problema, DHCP, mas a mesma falha de WLAN0 até o ETH0 ter sido UP. No meu caso, @Jivings está correto. Quando você faz o ping da resposta de recebimento é via ETH0.

Agora, isso vai contra tudo que eu entendo, mas no meu caso com o cabo ethernet RPI conectado:

pi@raspberrypi ~ $ ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:b0:0c:39  
          inet addr:192.168.99.75  Bcast:192.168.99.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1


wlan0     Link encap:Ethernet  HWaddr 80:1f:02:82:33:24  
          inet addr:192.168.99.78  Bcast:192.168.99.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

Anote o HWaddr em cada cartão.

Então de outra estação de trabalho, neste caso estou usando o NMAP:

$ sudo nmap -sn 192.168.99.75  **<< - ETH0**

Starting Nmap 6.25 ( http://nmap.org ) at 2013-02-03 10:19 GMT
Nmap scan report for 192.168.99.75
Host is up (0.020s latency).
MAC Address: B8:27:EB:B0:0C:39 (Raspberry Pi Foundation)
Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds
Paul@lo-mbp-preg / $ sudo nmap -sn 192.168.99.78

$ sudo nmap -sn 192.168.99.78  **<< - ETH0**

Starting Nmap 6.25 ( http://nmap.org ) at 2013-02-03 10:19 GMT
Nmap scan report for 192.168.99.78
Host is up (0.0044s latency).
MAC Address: B8:27:EB:B0:0C:39 (Raspberry Pi Foundation)
Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds

Você pode ver que o Endereço MAC / HWAddr para ETH0 e WLAN0 é o mesmo e corresponde ao ETH0 HWAddr de ifconfig. Então, no meu caso, o Wireless não estava funcionando. Todo o tráfego estava passando via ETH0

Se você não tiver o ping NMAP e exibir a tabela ARP (IP < - > tabela MAC) mostrará as mesmas informações. Do CLI:

• Windows = arp -a
• Linux = arp

Eu na verdade não encontrei 'o motivo' para isso. No processo de depuração, ele começou a funcionar de maneira confiável. Que eu odeio. Mas esta configuração está funcionando agora:

/ etc / network / interfaces

auto lo

iface lo inet loopback
iface eth0 inet dhcp

allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

/etc/wpa_supplicant/wpa_supplicant.conf

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
        ssid="<ssid>"
        psk=<key>
}
network={
        ssid="<ssid>"
        psk=<key>
}
network={
        ssid="<ssid>"
        psk=<key>
}
network={
        ssid="<ssid>"
        key_mgmt=WPA-EAP
        pairwise=TKIP
        group=TKIP
        eap=PEAP
        identity="user@domain"
        password="xxxxxxxxxx"
        ca_cert="/etc/cert/ca.pem"
        phase1="peapver=0"
        phase2="MSCHAPV2"
}

Espero que isso ajude você a progredir ...

    

Answer 2

Você pode tentar ver o que "route -n" oferece antes e depois de desconectar o cabo. Se eth0 desce, remove a rota padrão. Portanto, você precisa criar uma nova rota padrão associada a wlan0. Adicione isto na sua seção eth0 de / etc / network / interfaces:

pre-up if [ 'ip route show|grep default|wc -l' -eq 1 ];then route del default gw xx.xx.xx.xx dev wlan0;fi
post-down if [ 'ip route show|grep wlan0|wc -l' -eq 1 ];then route add default gw xx.xx.xx.xx dev wlan0;fi

    

Answer 3

Eu tive exatamente o mesmo problema com o Debian Jessie no meu Raspberry Pi. Acabou que esqueci de instalar o pacote wpasupplicant . Use o seguinte comando para verificar os pacotes instalados:

dpkg -l | grep wpa

Isso deve pelo menos listar o pacote wpasupplicant . Se não, instale-o:

apt-get install wpasupplicant

Em seguida, calcule o hash WPA PSK correto para seu SSID (substitua <myssid> e <passphrase> de acordo):

wpa_passphrase <myssid> <passphrase>

Isso gera algumas linhas. Precisamos apenas do valor de hash de 64 caracteres. Abra o arquivo interfaces :

vi /etc/network/interfaces

... e adicione o SSID e o hash:

auto wlan0
iface wlan0 inet dhcp
    wpa-ssid myssid
    wpa-psk e71e118835ca1d72c61db51b9a0687df088f4952c27760cd2da05cfb2f3dad33

Salve suas alterações e restrinja o acesso a este arquivo para evitar a divulgação de chave pré-compartilhada (PSK):

chmod 600 /etc/network/interfaces

Pode ser útil adicionar wpa-debug-level 3 ao arquivo interfaces : isso grava muitas mensagens de depuração no arquivo de log /var/log/syslog .

Mais instruções podem ser encontradas em: link (seção "wpa_supplicant").

    

Answer 4

Eu tive o mesmo problema, embora, ao verificar os endereços MAC, eu pudesse descobrir que minhas conexões SSH foram realizadas através dos dispositivos certos. No entanto, não consegui SSH para wlan0 if eth0 estava inativo.

Eu resolvi isso definindo atribuições estáticas de DHCP no meu roteador. Agora eu tenho as duas interfaces trabalhando independentemente e os endereços IP que eu queria ter em cada uma delas (eu nem mudei o arquivo interfaces para configurar a configuração para iface XXX inet dhcp )

    

Answer 5

Eu tive sintomas quase idênticos. Descobri uma má interação entre meu roteador (Tomato) e meu rpi. Desligar o APSD no roteador fez com que o problema desaparecesse.