2011-02-01 2 views
0

У нас мало сетевых устройств, которые поставляются с IP-адресом от 0.0.0.1 до , обеспечивают, что они никогда не сталкиваются с каким-либо другим устройством в своей новой среде (таким образом, ни одна из 10.xxx, 172.16.xx или 192.168.xx) до конфигурации. DHCP не является решением, поскольку в поле не может быть DHCP-сервер.Windows 7 не принимает трансляции с IP-адреса 0.0.0.1

Устройства будут слушать широковещательные передачи UDP и отвечать широковещательными сообщениями до тех пор, пока они не получат свой новый IP-адрес таким образом.

Это отлично работало с Windows XP, но отстой с Windows 7: программа конфигурации не получает пакеты ответов с устройств, которые все еще имеют 0.0.0.1. Wireshark видит пакеты, затем они сбрасываются системой.

Вопрос: Есть ли причина (RFC?), Что на самом деле запрещает, используя этот адрес в локальной среде? Или это просто MS, который был слишком осторожен? Где могу ли я прочитать, почему они относятся к этому адресу «недействительным»? Какие диапазоны действительно «недействительный» сейчас тоже?

Любая идея обходного пути на стороне ПК (Win 7)?

Я знаю, что не рекомендуется использовать адреса 0.xxx для рабочих мест, но по этой причине - имея не использованный адрес - он отлично работает.

Редактировать: есть устройство, называемое «Netburner», которое, возможно, столкнулось с подобной проблемой, согласно их форуму. См .: http://forum.embeddedethernet.com/viewtopic.php?f=5&t=612&p=2198 Делает - по совпадению - кто-нибудь знает какую-то справочную информацию?

+0

У вас есть эта подсеть в конфигурации вашей сетевой карты? Многие системы будут передавать широковещательные пакеты, которые поступают из нелокальной подсети. – thkala

+0

Не могли бы вы переключиться на использование широковещательных пакетов Ethernet? Казалось бы, удаление всего стека маршрутизации TCP/IP будет выгодным. – sarnold

+0

@thkala: мы проверим это. спасибо за подсказку. Тем не менее - RFC1918 позволяет использовать адрес _any_ ip локально, они не рекомендуют его из-за недостатков. – minastaros

ответ

1

Звучит так, как будто ваше приложение настройки прослушивает широковещательные пакеты на всех сетевых интерфейсах и ожидает получения пакетов из зарубежных подсет.

Это должно быть не работа - OS должна только передавать широковещательные пакеты из подсетей, на которые подключен каждый сетевой интерфейс, а не от всех подсетей в одном физическом сегменте (например, Ethernet). Я вполне уверен, что в противном случае нарушено поведение WRT протокола IP.

Существуют два способа решения этой:

  • Убедитесь, что сетевой интерфейс имеет IP-адрес в целевой подсети. Вы можете иметь more than one IP addresses для каждой сетевой карты, чтобы не мешать обычным сетевым операциям.

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

+0

thkala, имейте большое спасибо за все ваши усилия, написав ответы. Мы обсудим ваши идеи и сделаем еще несколько тестов. Возможно, использование другого подхода возможно и способ думать о будущем - однако проблема заключается в том, что мы не можем легко изменить все устройства, которые уже развернуты. Поэтому с этой точки зрения лучшим решением было придерживаться того же подхода и заставить его работать как-то. Что касается вашего 1-го предложения: согласно моему последнему комментарию выше, нам нужно найти устройства из _any_ подсети. Поэтому добавление интерфейса с 0.0.0.x будет выполнять только половину работы. В любом случае, спасибо за это. – minastaros

+0

сделали несколько исследований: во-первых, тесты показали, что сообщения с устройства с IP 1.0.0.1 _are_ получены. Таким образом: ** это не вопрос другой подсети **. RFC922 четко заявляет в главе 4, что «широковещательная передача для всех хостов в локальной аппаратной сети» возможна, в главе 7 упоминается адрес получателя 255.255.255.255. Я заключаю, что, когда вы можете отправлять _to_ все хосты, вы также можете получить от них. Проблема есть в начале 0.x. RFC1700 стр. 4 (b) говорит, что 0.x.x.x являются «указанным хостом в этой сети. Может использоваться только как адрес источника». Это то, что мы делаем - должно быть хорошо. – minastaros

0

Можете ли вы добавить новые записи таблицы маршрутизации в машины Windows легко? Windows должна знать, какой интерфейс использовать при маршрутизации широковещательного пакета в сеть 0.0.0.x.

Машины Unix, с которыми я знаком, имеют таблицу маршрутизации, которая отображает записи сети/сетевой маски на любые шлюзы или интерфейсы (если сеть является локальной сетью). Локальная сеть (192.168.0.0/16 для моей домашней сети) отправляется на интерфейс eth0. Все остальное 0.0.0.0/0 отправляется на конкретную шлюзовую машину 192.168.0.1.

Если мой аппарат отправил широковещательное сообщение UDP в сеть 0.0.0.0/24 (другими словами, широковещательная передача UDP отправлена ​​на номер 0.0.0.255, тогда моя машина переадресует пакет на шлюз (который он может искать через arp). средний не будет распространять пакет на другие сетевые устройства, поскольку MAC-адрес задан.

Если у моего устройства была другая запись маршрутизации для 0.0.0.0/24 для локального интерфейса, моя машина отправила бы пакет на провод, используя ethernet, и коммутаторы будут перенаправлять пакет на все соединения (Yay! Также как хабы в 90-е годы!)

Итак, я полагаю, вам нужно добавить запись маршрутизации для 0.0.0.0/24 на ваши клиентские компьютеры, чтобы они могли правильно адресовать пакет вещания.

+0

Проблема заключается не в том, что ПК не может _send_ трансляции. Он может, но он не принимает их. Фактически, это происходит, потому что Wireshark видит, что они прибывают, но тогда приложение не получает его (и это было с XP). – minastaros

Смежные вопросы