Eu tenho um programa que tenta entrar em contato com um dispositivo incorporado pelo UDP. O dispositivo incorporado possui apenas um endereço de link local (169.254. . ); o host Linux possui um endereço normal (DHCP, RFC1918), gerenciado pelo NetworkManager no ubuntu natty. Esta conexão local é configurada para 'usar esta conexão apenas para recursos na rede local'. Meu programa envia um pacote de difusão em um soquete e, em seguida, espera em um soquete unicast (ligado ao endereço local, não conectado () ed) para um pacote de beacon de entrada
Por vezes, descubro que o programa Linux não recebe pacotes do endereço local de ligação do dispositivo incorporado. O Wireshark mostra que eles estão chegando na interface de entrada e estão bem formados, mas não são recebidos. Os pacotes enviados localmente de e para o endereço local RFC1918 são, no entanto recebidos, assim como os pacotes de outros hosts RFC1918 no mesmo netowrk.
Eu também acho que, ao reiniciar, essa condição geralmente se corrige espontaneamente; Eu posso mais uma vez receber pacotes de endereços locais de link. Às vezes, ele também se corrige espontaneamente depois de apenas esperar algum tempo.
Existe alguma configuração de rota obscura ou algo que poderia causar a perda dos pacotes recebidos? Os pacotes de saída funcionam bem (provavelmente porque estou ignorando o roteamento ao enviar pacotes).
Correlacionando o último caso de restauração espontânea, acho isso nos logs:
Jul 13 20:58:01 hakase NetworkManager[933]: <info> (eth0): DHCPv4 state changed preinit -> reboot
Jul 13 20:58:01 hakase NetworkManager[933]: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) scheduled...
Jul 13 20:58:01 hakase NetworkManager[933]: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) started...
Jul 13 20:58:01 hakase NetworkManager[933]: <info> address 192.168.0.148
Jul 13 20:58:01 hakase NetworkManager[933]: <info> prefix 24 (255.255.255.0)
Jul 13 20:58:01 hakase NetworkManager[933]: <info> gateway 192.168.0.1
Jul 13 20:58:01 hakase NetworkManager[933]: <info> nameserver '192.168.0.1'
Jul 13 20:58:01 hakase NetworkManager[933]: <info> domain name 'mshome.net'
Jul 13 20:58:01 hakase NetworkManager[933]: <info> Scheduling stage 5
Jul 13 20:58:01 hakase NetworkManager[933]: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) scheduled...
Jul 13 20:58:01 hakase NetworkManager[933]: <info> Done scheduling stage 5
Jul 13 20:58:01 hakase NetworkManager[933]: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) complete.
Jul 13 20:58:01 hakase NetworkManager[933]: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) started...
Jul 13 20:58:01 hakase avahi-daemon[862]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.0.148.
Jul 13 20:58:01 hakase avahi-daemon[862]: New relevant interface eth0.IPv4 for mDNS.
Jul 13 20:58:01 hakase avahi-daemon[862]: Registering new address record for 192.168.0.148 on eth0.IPv4.
Jul 13 20:58:02 hakase NetworkManager[933]: <info> Policy set 'Auto dfn3' (wlan0) as default for IPv4 routing and DNS.
Jul 13 20:58:02 hakase NetworkManager[933]: <info> (eth0): device state change: 7 -> 8 (reason 0)
Jul 13 20:58:02 hakase NetworkManager[933]: <info> Activation (eth0) successful, device activated.
Jul 13 20:58:02 hakase NetworkManager[933]: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) complete.
Jul 13 20:58:03 hakase postfix/master[1245]: reload -- version 2.8.2, configuration /etc/postfix
[these next two lines are likely associated with the wireshark session I have running]
Jul 13 20:58:09 hakase kernel: [37294.962058] device eth0 left promiscuous mode
Jul 13 20:58:10 hakase kernel: [37295.323279] device eth0 entered promiscuous mode
Jul 13 20:58:11 hakase ntpdate[23459]: adjust time server 91.189.94.4 offset -0.024960 sec
Jul 13 21:02:40 hakase dhclient: DHCPREQUEST of 192.168.0.148 on eth0 to 192.168.0.1 port 67
Jul 13 21:02:40 hakase dhclient: DHCPACK of 192.168.0.148 from 192.168.0.1
Jul 13 21:02:40 hakase dhclient: bound to 192.168.0.148 -- renewal in 248 seconds.
Jul 13 21:02:40 hakase NetworkManager[933]: <info> (eth0): DHCPv4 state changed reboot -> renew
Jul 13 21:02:40 hakase NetworkManager[933]: <info> address 192.168.0.148
Jul 13 21:02:40 hakase NetworkManager[933]: <info> prefix 24 (255.255.255.0)
Jul 13 21:02:40 hakase NetworkManager[933]: <info> gateway 192.168.0.1
Jul 13 21:02:40 hakase NetworkManager[933]: <info> nameserver '192.168.0.1'
Jul 13 21:02:40 hakase NetworkManager[933]: <info> domain name 'mshome.net'
[at approximately one second later the connection to the link-local device was established]
Este estado de 'reinicialização' pode estar ligado ao problema de alguma forma?
Atribua estaticamente o endereço local no host Linux e veja se isso desaparece. Tire o DHCP da imagem. Na pior das hipóteses, você não obterá o efeito de "restauração espontânea" quando parar de funcionar, mas pelo menos poderá cruzar as preocupações sobre o DHCP na sua lista.
E, se você quiser, tente atribuir um endereço 169.254 / 16 além disso e veja se isso ajuda.
Há muitas informações complicadas lá, e a única pergunta que eu vejo é: "Existe alguma configuração de rota obscura ou algo que poderia causar a perda dos pacotes recebidos?"
Qual é a sua verdadeira pergunta? Vou abordar a questão: "Estou tentando entrar em contato com 169.254.100.15 de 192.168.1.101. Por que não posso contatá-lo?"
Comunicação de soquete funciona sobre TCP, certo?
Para que dois hosts em sub-redes separadas falem entre si, eles precisam ser roteados.
Os endereços locais com link (169.254.0.0/16) não são roteados nunca ( link ).
Você não pode falar com um endereço em 169.254.0.0/16 de qualquer outra sub-rede. De jeito nenhum, não como. Não agora, nem nunca.
Além disso: Eu apenas pensei que você pode olhar para o uso de um loopback e endereçar pacotes para a interface desse jeito.
O que me impressiona na sua saída é a renovação do seu IP em 248 segundos.
Então, seus problemas começam depois desses 248 segundos?
Nesse caso, o dhcp-client pode fazer algumas alterações de configuração indesejadas quando a renovação chegar.
Existe alguma razão para este período de tempo muito curto?
Tente executar avahi-autoipd para que sua máquina atribua a si própria um endereço 169.254 / 16, então você deve poder conversar com outros hosts em 169.254 / 16 em sua rede local.
Tags networking linux udp link-local