Linux-приложение не получает UDP-сообщения от 169.254.x.x (локальная ссылка) - PullRequest
1 голос
/ 21 апреля 2011

Мое приложение (написанное на C ++, работающее в Ubuntu 9.10) прослушивает сокет UDP для широковещательных сообщений от внешних устройств.Эти устройства могут иметь любой IP-адрес, поскольку идея заключается в том, чтобы обмениваться данными за пределами диапазона IP-адресов.

Когда устройства имеют IP-адреса, такие как 99.99.1.2, 1.2.3.4, 0.0.0.1, 192.168.2.77 и т. Д., Этоработает нормально (сам ПК 192.168.1.110).Но: он не работает, когда устройство имеет 169.254.xx (блок локальной ссылки), приложение не получает сообщение.Брандмауэр не работает, и Wireshark показывает сообщение, поэтому соединение в порядке.Я предполагаю, что проблема где-то в стеке IP (я открываю устройство / dev / eth2 и получаю сокет, так что ничего особенного).

Есть идеи по причине или решению?Большое спасибо.

Ответы [ 4 ]

0 голосов
/ 07 января 2014

Убедитесь, что rp_filter отключен на всех интерфейсах, для которых вы хотите получать широковещательный UDP, когда ваш ip равен 169.254.xx

# sysctl -A | grep '\.rp_filter'
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.lo.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0

Чтобы установить rp_filter, используйте

# sysctl -w net.ipv4.conf.eth0.rp_filter=0
0 голосов
/ 21 апреля 2011

Вы захотите перепроверить, если у вас есть брандмауэр, блокирующий их.В Linux вы, вероятно, используете iptables .Используйте эту команду, чтобы составить список своих правил.Многие дистрибутивы используют межсетевые экраны, используя iptables, но скрывают этот факт от вас.

Маршрутизаторы не должны пересылать пакеты с 192. . . *, Потому что это не «маршрутизируемая» подсеть.Предполагается, что он будет использоваться только для внутреннего / локального использования.Если между источником и пунктом назначения есть маршрутизатор или мост, это может быть проблемой.Если у вас есть wireshark на той же машине, которая прослушивает пакеты, и вы можете видеть их, то это не проблема.

Вы можете использовать netstat , чтобы убедиться, что ваша программа действительно прослушивает.Введите 'netstat -an -p UDP ", чтобы увидеть все программы, которые прослушивают пакеты udp.


0 голосов
/ 04 мая 2011

похоже, я нашел причину. В любом случае, спасибо тем, кто предложил решения.

Я не упомянул, что мой Ubuntu работает на виртуальной машине (что, в принципе, не является проблемой, поскольку Wireshark получил сообщения)

Интерфейсы: eth2 - это интерфейс, о котором я говорил выше (таким образом, который осуществляет внешнюю связь через трансляции). Это " соединенный " один.

Кроме того, я реализовал внутренний сетевой интерфейс " только для хоста " eth4 для связи с другими виртуальными машинами.

Я также добавил маршрут " default " для eth2, иначе широковещательная связь не работала бы вообще.

Однако я не заметил автоматически вставленный маршрут link-local , который указывал на eth4 . Поэтому я пришел к выводу, что система использует это для обработки всех сообщений 169.254.x.x, и мое приложение больше их не получает.

Два способа решили мою проблему:

  • Отключить eth4 вообще или
  • удаление маршрута "link-local" с помощью

    route del -net 169.254.0.0 маска сети 255.255.0.0 dev eth4

Вот таблица маршрутизации перед удалением маршрута:

Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.230.0   *               255.255.255.0   U     1      0        0 eth4
192.168.1.0     *               255.255.255.0   U     1      0        0 eth2
link-local      *               255.255.0.0     U     1000   0        0 eth4
default         *               0.0.0.0         U     10     0        0 eth2

Теперь я могу с радостью получать все пакеты с устройств, которые мне нужны.

0 голосов
/ 21 апреля 2011

Убедитесь, что eth2 имеет IP-адрес и маску сети и что этот IP-адрес и маска сети помещают его в ту же IP-сеть, что и устройство.Используйте команду ifconfig, чтобы увидеть эти детали.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...