У меня есть робот под управлением Linux с проводными и беспроводными адаптерами. Когда я загружаюсь, он подключается к беспроводной сети нормально. Когда я назначаю IP для проводного (статически или с DHCP), это выглядит как работает. Как ifconfigпоказано , показывает правильный IP и routeпоказывает правильные маршруты. Однако, когда я делаю запрос ARP для проводного IP, ответ ARP содержит беспроводной MAC.
??? На роботе нет моста, так почему я не могу получить проводной MAC ???
Когда провод отключен, проводной IP отвечает на пинг ...
Почему робот отвечает по беспроводному интерфейсу на IP-запросы в проводной сети ???
РЕДАКТИРОВАТЬ: проводной и беспроводной адаптеры в одной IP-подсети. Я делаю запрос ARP с компьютера (пробовал на разных компьютерах) в той же IP-подсети.
соответствующий вывод ifconfig:
eth0 Link encap:Ethernet HWaddr 00:01:C0:04:BD:F7
inet addr:192.168.0.110 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
ra0 Link encap:Ethernet HWaddr 24:3C:20:06:3E:6D
inet addr:192.168.0.101 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:59 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:31023598 (29.5 MiB) TX bytes:85640627 (81.6 MiB)
соответствующий вывод маршрута:
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ra0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Это очень урезанный Linux, поэтому у меня нет таких инструментов, как artptables, iptables, sysctl, brctl и т. Д.
РЕДАКТИРОВАТЬ: диаграмма в соответствии с просьбой
РЕДАКТИРОВАТЬ: я сбрасываю трафик и смотрю на таблицу ARP. Запрос ARP 192.168.0.110 возвращает ответ ARP, содержащий 24: 3C: 20: 06: 3E: 6D. MAC-адрес исходного пакета ответа ARP также составляет 24: 3C: 20: 06: 3E: 6D. Я пробовал возиться с _filter, _ignore и _announce, как упоминалось здесь , но безрезультатно.
РЕДАКТИРОВАТЬ: установка шлюза (на любом интерфейсе) не имеет значения (как это не должно).
РЕДАКТИРОВАТЬ: это работало нормально на предыдущей версии ОС (на основе openembedded). Возможно, они что-то изменили?
Ответы:
То, что вы видите, - это нормальное поведение, когда у вас есть два интерфейса в одной сети. Это описано в этой статье LWN .
источник
Когда вы говорите, что получаете ответ ARP для неправильного интерфейса, вы на самом деле сбрасываете трафик или просто просматриваете итоговую таблицу ARP? Возможно, вы получаете ARP-ответы для обоих интерфейсов ...
Во всяком случае, я считаю, что ответ на вашу проблему заключается в правильном манипулировании
rp_filterиarp_filter. Документация для каждого из них включена ниже.Я предлагаю сначала попробовать это:
Возможно, вам также потребуется внести это изменение:
rp_filter - BOOLEAN 1 - выполнить проверку источника по обратному пути, как указано в RFC1812 Рекомендуемая опция для одиночных хостов и заглушки сети маршрутизаторы. Может вызвать проблемы для сложных (не без петель) сети с медленным ненадежным протоколом (вроде RIP), или используя статические маршруты. 0 - Нет проверки источника. conf / all / rp_filter также должен быть установлен в TRUE для проверки исходного кода на интерфейсе Значение по умолчанию равно 0. Обратите внимание, что некоторые дистрибутивы включают его в скриптах запуска. arp_filter - BOOLEAN 1 - Позволяет иметь несколько сетевых интерфейсов на одном подсеть, и есть ARP для каждого интерфейса отвечено в зависимости от того, будет ли ядро маршрутизировать пакет из ARP'd IP из этого интерфейса (поэтому вы должны использовать источник на основе маршрутизации, чтобы это работало). Другими словами, это позволяет контролировать из которых карты (обычно 1) будут отвечать на запрос arp. 0 - (по умолчанию) Ядро может отвечать на запросы arp с адресами с других интерфейсов. Это может показаться неправильным, но обычно смысл, потому что это увеличивает вероятность успешного общения. IP-адреса принадлежат всему хосту в Linux, а не конкретные интерфейсы. Только для более сложных установок, таких как load- балансировка, это поведение вызывает проблемы. arp_filter для интерфейса будет включен, если хотя бы один из conf / {all, interface} / arp_filter установлен в TRUE, иначе он будет отключенДля более тщательного лечения, см. Эту статью:
http://www.embedded-bits.co.uk/tag/rp_filter/
источник
Я знаю, что это старая проблема, но недавно я столкнулся с точно такой же ситуацией со встроенным устройством. Устройство имеет как интерфейс Ethernet, так и интерфейс Wi-Fi, и требования состоят в том, чтобы оба интерфейса были активными и находились в одной и той же сети в любое время, но сетевой трафик должен направляться через «предпочтительный» интерфейс.
Большинство пользователей не будут настраивать свои устройства таким образом, но теоретически это должно быть возможно.
Сначала мы обнаружили проблемы с маршрутизаторами Netgear, поскольку они сообщали о конфликте IP-адресов - 2 MAC-адреса совместно использовали один IP-адрес. Очевидно, что в этом случае маршрутизатор начнет плохо себя вести и испортит сеть пользователей.
Я создал частную сеть, которая содержала только маршрутизатор (ethernet + wifi), ноутбук с Windows (только Ethernet) и встроенное устройство (ethernet + wifi). Используя wireshark, tcpdump на устройстве и arp на окнах, я вижу следующее поведение:
Я полагаю, что пункт 3 вызван пунктом 5. Таблицы arp запутаны, потому что wln отвечает на сообщения arp, на которые должен отвечать только eth0. Я полагаю, что пункт 4 также вызван пунктом 5. Пинг отправляется на основе MAC-адреса, и поскольку последнее полученное сообщение arp было получено от wln, сообщившим, что у него есть eth0 IP, эхо-запросы неправильно маршрутизируются в интерфейс wln.
После долгих копаний и испытаний решение было на самом деле очень простым. Смотрите эту статью - http://blog.cj2s.de/archives/29-Preventing-ARP-flux-on-Linux.html
Сетевые драйверы ядра Linux сконфигурированы таким образом, что при получении запроса arp для известного интерфейса (даже если он получен на другом интерфейсе) он отвечает на arp.
Этот параметр решает проблему:
echo 1 > /proc/sys/net/ipv4/conf/wln/arp_ignore echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignoreОбъяснение:
источник
Так как это работало нормально в предыдущей версии ОС (на основе openembedded), моим решением было дождаться следующей версии ОС. Мое лучшее предположение было то, что модуль беспроводного ядра был глючным.
источник
В продолжение комментария Инсайта.
Давайте сделаем несколько имен:
Поскольку ваш робот доступен с 3 ПК через проводную и беспроводную связь. И поскольку они находятся в одной подсети, вы не можете точно сказать, каким образом был выполнен запрос arp для вашего проводного носителя. Под этим я имею в виду, когда переключатель передач для запроса агр, робот получает его на обоих интерфейсах [ со ссылкой на диаграмму] поэтому для него принимает запрос на агр для IP на проводных средств массовой информации на беспроводные среды тоже скорее всего , он ответил с физическим адресом беспроводного носителя, для которого действительно настроен IP
У меня была эта проблема в прошлом, она не была точно вашей, но была похожа. По умолчанию Linux отвечает физическим адресом интерфейса, на который он получает запрос arp, независимо от того, на какой интерфейс настроен IP-адрес. Так что в вашем случае подключите PC3 к интерфейсу eth0 робота напрямую и выполните запрос arp для 192.168.0.101, он ответит вам физическим адресом интерфейса eth0 вместо ra0.
Мой сценарий развертывания был:
[RTR] | ------------ eth0 --- [сервер]
| -------- | switch1 | ----- eth1 ----- [сервер]
Это тот же коммутатор, к которому подключаются оба интерфейса. Надеюсь, что это поможет вам.
Маршрутизатор имел первичный и вторичный IP-адрес, настроенный на его интерфейсе для двух разных сетей на двух разных интерфейсах на сервере. Но, получив запрос arp на eth1 для IP-адреса eth0, он ответил с физическим адресом eth1
Чтобы предотвратить это, у меня до сих пор работало следующее
положите его где-нибудь на своего робота, чтобы вы могли применить его при загрузке.
Рекомендации: Я бы порекомендовал вам настроить две разные подсети (скажем, 192.168.1.x / 24 для ra0 и 192.168.2.x / 24 для eth0), вы можете использовать псевдонимы IP на своих ПК, и ваш робот будет доступен через любую из двух IP-адресов. Вы не можете иметь два исходящих пути для одной подсети на одном хосте. Нет, если нет чего-то, что заставляет вашего робота отдавать предпочтение одному другому. Ваш робот может выбрать только один путь для отправки пакетов.
Некоторые чтения: arp_announce , arp_ignore
источник
я думаю, что есть неправильная конфигурация между вашей беспроводной точкой доступа и коммутатором. коммутатор и AP запутываются, куда отправлять пакеты. не уверен в этом, хотя. Кроме того, я думаю, вы должны попытаться определить шлюз, где программы могут знать, куда отправлять пакеты. что-то вроде
route add default gw 192.168.0.1источник