ARP-ответы содержат неверный MAC-адрес

У меня есть робот под управлением 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. Документация для каждого из них включена ниже.

Я предлагаю сначала попробовать это:

echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter

Возможно, вам также потребуется внести это изменение:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_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 на окнах, я вижу следующее поведение:

1. Ifconfig на устройстве показывает разные IP-адреса wln и Ethernet и разные MAC-адреса
2. Иногда (очень редко) и arp –a из окон показывает правильную комбинацию IP-MAC.
3. Большую часть времени arp –a из окон показывает, что и wln, и eth0 имеют одинаковый MAC-адрес
4. При пинге wln или eth0 из окон ответ на пинг приходит от wln и очень редко от eth0. tcpdump показывает, что wln ответил только на 1 из 4 пингов (например)
5. Когда windows отправляет arp сообщение «кто имеет» для eth0 IP - оба интерфейса eth0 и wln отвечают, что у них есть этот IP

Я полагаю, что пункт 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

Объяснение:

arp_ignore - INTEGER
Define different modes for sending replies in response to
received ARP requests that resolve local target IP addresses:
0 - (default): reply for any local target IP address, configured
on any interface
1 - reply only if the target IP address is local address
configured on the incoming interface
2 - reply only if the target IP address is local address
configured on the incoming interface and both with the
sender's IP address are part from same subnet on this interface
3 - do not reply for local addresses configured with scope host,
only resolutions for global and link addresses are replied

Так как это работало нормально в предыдущей версии ОС (на основе openembedded), моим решением было дождаться следующей версии ОС. Мое лучшее предположение было то, что модуль беспроводного ядра был глючным.

В продолжение комментария Инсайта.

Давайте сделаем несколько имен:

• ПК1 - вверху справа
• ПК2 - вверху слева
• PC3 - внизу слева

Поскольку ваш робот доступен с 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

Чтобы предотвратить это, у меня до сих пор работало следующее

# echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce
# echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
# echo 2 > /proc/sys/net/ipv4/conf/ra0/arp_announce
# echo 1 > /proc/sys/net/ipv4/conf/ra0/arp_ignore

положите его где-нибудь на своего робота, чтобы вы могли применить его при загрузке.

Рекомендации: Я бы порекомендовал вам настроить две разные подсети (скажем, 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