Estou usando um dispositivo Wandboard (imx6) executando o Ubuntu 15.04 para um propósito semelhante a um quiosque. Eu uso a rede zeroconf para configuração inicial e depois de mover entre redes (sem acesso ao teclado no campo). Estou tendo problemas com a interface de rede não está funcionando depois de mudar de rede para a configuração do zeroconf. Aqui estão minhas etapas de reprodução (deixe-me saber se há mais coisas úteis para colocar no meu script de diag):
- eu reconfigurei para as configurações do zeroconf e reiniciei com o dispositivo ainda conectado a lan
wandboard@lnm:~$ ./network-diag.sh
+ cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 169.254.254.254
netmask 255.255.0.0
gateway 1.1.1.1
+ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:1f:7b:b2:14:96 brd ff:ff:ff:ff:ff:ff
inet 169.254.254.254/16 brd 169.254.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::21f:7bff:feb2:1496/64 scope link
valid_lft forever preferred_lft forever
+ ip route
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.254.254
+ systemctl status sys-subsystem-net-devices-eth0.device
� sys-subsystem-net-devices-eth0.device - /sys/subsystem/net/devices/eth0
Loaded: loaded
Active: active (plugged) since Fri 2016-08-12 18:40:17 UTC; 1min 17s ago
Device: /sys/devices/soc0/soc.1/2100000.aips-bus/2188000.ethernet/net/eth0
- Desconecte o cabo, conecte-o à rede ad-hoc zeroconf
wandboard@lnm:~$ ./network-diag.sh
+ cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 169.254.254.254
netmask 255.255.0.0
gateway 1.1.1.1
+ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:1f:7b:b2:14:96 brd ff:ff:ff:ff:ff:ff
inet6 fe80::21f:7bff:feb2:1496/64 scope link
valid_lft forever preferred_lft forever
+ ip route
+ systemctl status sys-subsystem-net-devices-eth0.device
� sys-subsystem-net-devices-eth0.device - /sys/subsystem/net/devices/eth0
Loaded: loaded
Active: active (plugged) since Fri 2016-08-12 18:40:17 UTC; 5min ago
Device: /sys/devices/soc0/soc.1/2100000.aips-bus/2188000.ethernet/net/eth0
- O dispositivo está agora inacessível de uma máquina Windows no modo zeroconf. Pings retornam "host de destino inacessível". Mas com um rápido reinício de rede ...
wandboard@lnm:~$ sudo service networking restart
wandboard@lnm:~$ ./network-diag.sh
+ cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 169.254.254.254
netmask 255.255.0.0
gateway 1.1.1.1
+ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:1f:7b:b2:14:96 brd ff:ff:ff:ff:ff:ff
inet 169.254.254.254/16 brd 169.254.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::21f:7bff:feb2:1496/64 scope link
valid_lft forever preferred_lft forever
+ ip route
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.254.254
+ systemctl status sys-subsystem-net-devices-eth0.device
� sys-subsystem-net-devices-eth0.device - /sys/subsystem/net/devices/eth0
Loaded: loaded
Active: active (plugged) since Fri 2016-08-12 18:40:17 UTC; 7min ago
Device: /sys/devices/soc0/soc.1/2100000.aips-bus/2188000.ethernet/net/eth0
Então tudo está bem novamente. Pings da máquina do Windows começam imediatamente a ser concluídos.
Isso é confuso para o usuário no campo e eles acabam desligando a unidade até que ela responda. Como posso fazer a rede se reconectar como esperado no modo zeroconf após um evento de troca de cabo?
Atualização: allow-hotplug eth0
parece não mudar nada.
Atualização-atualização:
Seguindo a sugestão de maxf, muitos dos meus problemas desapareceram depois de instalar o ifplugd (e configurá-lo!). NB: Você deve configurar o ifplugd em / etc / default / ifplugd se quiser que ele monitore sua interface. Descobri que minha interface ficou on-line corretamente em todas as situações, exceto uma:
╔═══════════╦═══════════════╦═══════════╦═════════╗
║ Boot with ║ bad link ║ good link ║ no link ║
╠═══════════╬═══════════════╬═══════════╬═════════╣
║ dhcp ║ ok ║ ok ║ ok ║
║ zeroconf ║ needs restart ║ ok ║ ok ║
╚═══════════╩═══════════════╩═══════════╩═════════╝
Nesta tabela, eu inicializaria o dispositivo configurado com dhcp / zeroconf-static e com o cabo conectado à rede oposta à necessária (link inválido), a rede adequada (link bom) ou desconectada (sem link) . Eu conectá-lo à rede correta e ver se a interface ficou on-line corretamente. Descobri que apenas a configuração do zeroconf quando inicializado conectado à minha LAN não conseguiu se conectar à rede ad-hoc do laptop zeroconf.
Aqui está o meu script de ação em /etc/ifplugd/action.d /
#!/bin/sh
LNM_LOG=/tmp/ifplug.log
ZEROCONF_IP=169.254.254.254
date >> $LNM_LOG
echo $1 $2 >> $LNM_LOG
if [ "$1" = "eth0" -a "$2" = "up" -a $(grep -c $ZEROCONF_IP /etc/network/interfaces) -ne 0 ] ; then
echo "eth0 plugged in for zeroconf, restart networking" >> $LNM_LOG
service networking restart
echo "network restarted" >> $LNM_LOG
fi
Espero que isso ajude alguém no futuro!