Ответы от многоадресной рассылки 255.255.255.255

В одном конкретном поле я не могу получить ответы на широковещательные сообщения (255.255.255.255). Например

Отправка DHCPDISCOVER

DHCPREQUEST на wlan0 до 255.255.255.255

И посмотрите даже ответы от DHCP-сервера в этой сети

DHCPOFFER из 10.0.1.1

Но фактический интерфейс не получает его. Он работает на всех других интерфейсах, а также на других блоках в той же сети. В этом поле есть свежий минимальный Debian, без брандмауэра.

Что это может быть?

PS: Проблема заключается не только в DHCP (даже если клиент не получает ip из-за этого). Но любое сообщение, отправленное в 255.255.255.255 и получившее ответ, попадает в поле, но не может быть прочитано из интерфейса.

Здесь вывод на netstat -g для этого интерфейса

wlan0 1 224.0.0.251 wlan0 1 all-systems.mcast.net 

Обновление 1 : в соответствии с запросом здесь отображаются таблицы маршрутизации этого интерфейса

 **me@host:~ $ ip address show dev wlan0** 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether *[MAC]* brd ff:ff:ff:ff:ff:ff inet 192.168.10.3/24 brd 192.168.10.255 scope global wlan0 valid_lft forever preferred_lft forever **me@host:~ $ ip route show dev wlan0** 192.168.10.0/24 proto kernel scope link src 192.168.10.3 **me@host:~ $ ip route show dev wlan0 table local** broadcast 192.168.10.0 proto kernel scope link src 192.168.10.3 local 192.168.10.3 proto kernel scope host src 192.168.10.3 broadcast 192.168.10.255 proto kernel scope link src 192.168.10.3 

Но когда удаленная конечная точка отвечает на нулевую многоадресную сеть (например, 255.255.255.255 или 192.168.10.255), я вижу, что пакеты поступают и не могут ее обрабатывать (например, netcat -ul 192.168.10.3 68 не отвечает)

 IP (tos 0x0, ttl 64, id 11512, offset 0, flags [DF], proto UDP (17), length 76) 192.168.10.3.68 > 192.168.10.255.67: UDP, length 48 IP (tos 0x0, ttl 64, id 509, offset 0, flags [none], proto UDP (17), length 156) 192.168.10.1.67 > 192.168.10.3.68: UDP, length 128 

  • Какие порты необходимы и, как правило, должны быть разрешены в системе Linux?
  • Как netcat знает, открыт ли порт UDP?
  • как перенаправить весь UDP-трафик на VPN-клиент VPN с помощью UFW
  • Как использовать netperf для конкретного порта NIC?
  • Как заблокировать широковещательные сообщения (mDNS-трафик Apple)
  • Делает ли / proc / net / udp все капли, которые происходят между подключением Ethernet и моим приложением?
  • Сброс многоадресного потока UDP с помощью socat
  • UDP NAT Punching
  • One Solution collect form web for “Ответы от многоадресной рассылки 255.255.255.255”

    Ну, проблема решена. Это было связано с чем-то, чего я не совсем понимаю. В принципе, в дополнение к регулярному маршруту, по какой-то причине, чтобы включить чтение из конечной точки одноадресной рассылки, я должен добавить маршрут по умолчанию, источник и метрики. Таким образом, после полного решения проблемы для сети 192.168.10.3/24

     ip route add default via 192.168.10.1 src 192.168.10.3 metric 303 dev wlan0 ip route add 192.168.10.0/24 via 192.168.10.1 src 192.168.10.3 metric 303 dev wlan0 

    Не уверен, хотя, почему маршрут ядра недостаточно …

    Linux и Unix - лучшая ОС в мире.