У меня есть программа, которая пытается связаться со встроенным устройством через UDP. Встроенное устройство имеет только локальный адрес канала (169.254..); хост Linux имеет обычный (DHCP, RFC1918) адрес, управляемый NetworkManager на ubuntu natty. Это локальное соединение настроено так, чтобы «использовать это соединение только для ресурсов в локальной сети». Моя программа отправляет широковещательный пакет на один сокет, а затем ожидает на одноадресном сокете (привязанном к локальному адресу, а не к connect () ed) входящего пакета маяка.
Иногда я обнаруживаю, что программа Linux не принимает пакеты с локального адреса канала встроенного устройства. Wireshark показывает, что они поступают на входящий интерфейс и правильно сформированы, но не принимаются. Однако пакеты, отправленные локально как с локального адреса RFC1918, так и на него, принимаются, как и пакеты от других хостов RFC1918 в том же netowrk.
Я также обнаружил, что после перезагрузки это состояние обычно самопроизвольно исправляется; Я снова могу получать пакеты с локальных адресов. Иногда он также самопроизвольно исправляется после некоторого ожидания.
Есть ли какие-то неясные настройки маршрута или что-то, что может привести к потере входящих пакетов? Исходящие пакеты работают нормально (вероятно, потому, что я обхожу маршрутизацию при отправке пакетов).
Сопоставляя последний случай самопроизвольного восстановления, нахожу в логах:
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]
Может ли состояние перезагрузки как-то быть связано с проблемой?
Там много запутанной информации, и единственный вопрос, который я вижу: «Есть ли какие-то неясные настройки маршрута или что-то, что может привести к потере входящих пакетов?»
В чем ваш настоящий вопрос? Я отвечу на вопрос: «Я пытаюсь связаться с 169.254.100.15 с 192.168.1.101. Почему я не могу с ним связаться?»
Связь сокетов работает по TCP, верно?
Чтобы два хоста в разных подсетях могли общаться друг с другом, их необходимо маршрутизировать.
Адреса локальных каналов (169.254.0.0/16) никогда не маршрутизируются (http://en.wikipedia.org/wiki/Link-local_address).
Вы не можете разговаривать по адресу 169.254.0.0/16 из любой другой подсети. Ни за что, ни как. Ни сейчас, ни когда-либо.
Дополнительно: я просто подумал, что вы можете изучить возможность использования обратной петли и адресовать пакеты к такому интерфейсу.
Статически назначьте локальный адрес на хосте Linux и посмотрите, исчезнет ли это. Уберите DHCP из поля зрения. В худшем случае вы не получите эффекта «самопроизвольного восстановления», когда он перестанет работать, но, по крайней мере, вы можете исключить беспокойство о DHCP из своего списка.
И, если хотите, попробуйте дополнительно назначить адрес 169.254 / 16 и посмотрите, поможет ли это.
Попробуйте бежать avahi-autoipd чтобы ваша машина присвоила себе адрес 169.254 / 16, тогда вы должны иметь возможность разговаривать с другими хостами в 169.254 / 16 в вашей локальной сети.
Что меня поражает в вашем выводе, так это обновление вашего IP за 248 секунд.
Итак, ваши проблемы начинаются после этих 248 секунд?
В таком случае dhcp-клиент может вносить некоторые нежелательные изменения конфигурации при обновлении.
Есть ли причина для столь коротких сроков?