подключение устройства к ethernet Опции

[AlexY]

Всем добрый день,

В данный момент имеется устройство сбора информации, которое для ввода информации в PC использует плату PCI или ISA (не ругайте устройство старое).
Хотелось бы подключить все это хозяйство к ethernet дабы избавиться от необходимости что-то вставлять в компьютер у пользователя.
Устройство - это крейт с набором измерительных модулей. Соответственно, исходящий поток единицы Мбит, входящий на 1-2 порядока меньше.

Нужен совет или некий обзор по существующим решениям для подключения к ethernet.
Основной критерий - стоимость подключения.
Для начала хотелось бы понять самый простой с точки зрения реализации вариант.
Возможно ли обойтись без реализации TCP IP?

Заранее спасибо.

[zltigo]

Возможно ли обойтись без реализации TCP IP?

Разумеется да - на RAW Socket можете творить что угодно, ну или почти все, что угодно, если этим интерфейсом будет еще кто-то пользоваться.

[Aprox]

Разумеется да - на RAW Socket можете творить что угодно, ну или почти все, что угодно, если этим интерфейсом будет еще кто-то пользоваться.

Подскажите, где берут программную поддержку для RAW Socket-ов на стороне компьютера. В составе WinSock я ничего похожего не нашел.

[zltigo]

Подскажите, где берут программную поддержку для RAW Socket-ов на стороне компьютера.

Для Linux - нигде не берут

В составе WinSock я ничего похожего не нашел.

http://msdn2.microsoft.com/en-us/library/ms740548.aspx
WinSock 2.2 уже что-то было а вообще смотрите как ставят сниферы:
http://komsoft.ru/pma/sniffer.htm

[Aprox]

Спасибо за ссылки. Вникаю. Меня интересует возможность создать в Windows XP сокет, который работал бы с периферийными устройствами на канальном уровне, простейшими Ethernet фреймами по физическим МАС адресам и увеличенным размером пакета, без IP протокольных наворотов. Возможно такое в Windows? Если возможно, то куда посоветуете смотреть?

[zltigo]

создать в Windows XP сокет, который работал бы с периферийными устройствами на канальном уровне, простейшими Ethernet фреймами по физическим МАС адресам

Да.

и увеличенным размером пакета,

А вот про это лучше забудьте.

[Aprox]

создать в Windows XP сокет, который работал бы с периферийными устройствами на канальном уровне, простейшими Ethernet фреймами по физическим МАС адресам

Да.

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

[zltigo]

Интересно, как будут себя вести "умные" свичи в составе сети

Свитчи, естественно, работают по MAC адресам. IP им без надобности .

[Aprox]

Свитчи, естественно, работают по MAC адресам. IP им без надобности .

На каком этапе свитчи формируют у себя в памяти таблицу соответствия "порт - MAC адрес"? Сомневаюсь, ведь устройство, работающее на raw пакетах без IP, не будет отвечать на стандартные ARP запросы. Как же свитч поймет, что к данному порту подключено устройство с таким-то MAC адресом?

[Rst7]

На каком этапе свитчи формируют у себя в памяти таблицу соответствия "порт - MAC адрес"? Сомневаюсь, ведь устройство, работающее на raw пакетах без IP, не будет отвечать на стандартные ARP запросы. Как же свитч поймет, что к данному порту подключено устройство с таким-то MAC адресом?

На самом деле ему пофиг

8.2. Switch Core Functional Overview
8.2.1. Address Search, Learning, and Aging
When a packet is received, the RTL8309SB uses the least 10 bits of the destination MAC address to index the 1024-entry lookup table, and at the same time compares the destination MAC address with the contents of the 16-entry CAM. If the indexed entry is valid or the CAM comparison is matched, the received packet will be forwarded to the corresponding destination port. Otherwise, the RTL8309SB will broadcast the packet. This is the ‘Address Search’. The RTL8309SB then extracts the least 10 bits of the source MAC address to index the 1024-entry look-up table. If the entry is not already in the table it will record the source MAC address and add switching information. If this is an occupied entry, it will update the entry with new information. This is called ‘Learning’. If the indexed location has been occupied by a different MAC address (hash collision), the new source MAC address will be recorded into the 16-entry CAM. The 16-entry CAM reduces address hash collisions and improves switching performance. Address aging is used to keep the contents of the address table correct in a dynamic network topology. The look-up engine will update the time stamp information of an entry whenever the corresponding source MAC address appears. An entry will be invalid (aged out) if it’s time stamp information is not refreshed by the address learning process during the aging time period. The aging time of the RTL8309SB is around 300 seconds.

Как видите, он смотрит на ВСЕ пакеты, а не только на ARP

[Aprox]

Как видите, он смотрит на ВСЕ пакеты, а не только на ARP

Спасибо. Насколько я понял, на первом этапе, когда еще нет MAC таблица еще сформирована, или не соответсвует действительности, свитч рассылает поступившие пакеты во все порты. Далее, по мере прихода пакетов с других портов, по их source адресам заполняет таблицу "MAC-порт". Я правильно понял текст?

[Rst7]

Спасибо. Насколько я понял, на первом этапе, когда еще нет MAC таблица еще сформирована, или не соответсвует действительности, свитч рассылает поступившие пакеты во все порты. Далее, по мере прихода пакетов с других портов, по их source адресам заполняет таблицу "MAC-порт". Я правильно понял текст?

Безусловно. Допустим, у нас безмозглая железка генерирует RAW-пакеты с правильными MAC-адресами (заранее задаными). В результате, первый же пакет от железки установит соответствие MAC<->PORT для железки, хотя, если не нужно принимать пакеты, это не особо и надо. А куда же отроутится пакет? Полетит он скорее всего в нужный порт, к которому подключен комп, т.к. стек сетевых протоколов на компе тоже проявляет некоторую активность (особенно виндозный, всякие девайсы PnP в сети ищет). В крайнем случае на компе можно просто пинг запустить хоть и не в существующий девайс.

[Aprox]

Безусловно. Допустим, у нас безмозглая железка генерирует RAW-пакеты с правильными MAC-адресами (заранее задаными). В результате, первый же пакет от железки установит соответствие MAC<->PORT для железки, хотя, если не нужно принимать пакеты, это не особо и надо. А куда же отроутится пакет? Полетит он скорее всего в нужный порт, к которому подключен комп, т.к. стек сетевых протоколов на компе тоже проявляет некоторую активность (особенно виндозный, всякие девайсы PnP в сети ищет). В крайнем случае на компе можно просто пинг запустить хоть и не в существующий девайс.

Каверза возникла. Если безмозглая железка не генерирует RAW пакеты, а наоборот - только принимает пакеты молча, то свитч никогда ее обнаружить на порту не сможет и будет рассылать широковещательно. Получается, read only режим неэффективен в случае применения свитча и RAW пакетов.

[zltigo]

Если безмозглая железка ...
...
то свитч никогда ее обнаружить на порту не сможет и будет рассылать широковещательно.

Ну так если все "безмозглые", то кому-то придется добавить мозгов, либо железке, либо switch-у, либо компьютеру. Выбирайте.

[Rst7]

Ну так если все "безмозглые", то кому-то придется добавить мозгов, либо железке, либо switch-у, либо компьютеру. Выбирайте.

да ну пусть раз в полсекунды каждая железка плюнет пакетом со своим маком. И все будет ок.

[Aprox]

да ну пусть раз в полсекунды каждая железка плюнет пакетом со своим маком. И все будет ок.

Пусть то оно пусть, но уже лишние сложности наметились. Вообще, постепенно прихожу к мысли, что IP навороты в протоколах недаром были созданы и стандартизованы. Попытки их избежать с помощью очень "сырых" пакетов Ethernet чреваты вляпаться в непредусмотренные проблемы.

[Rst7]

Пусть то оно пусть, но уже лишние сложности наметились. Вообще, постепенно прихожу к мысли, что IP навороты в протоколах недаром были созданы и стандартизованы. Попытки их избежать с помощью очень "сырых" пакетов Ethernet чреваты вляпаться в непредусмотренные проблемы.

В принципе, особо никакой сложности не вижу. И зря боитесь, будет все работать.

[iosifk]

В принципе, особо никакой сложности не вижу. И зря боитесь, будет все работать.

Насколько я помню, когда я отлаживал МАС в ПЛИС, то как раз и гонял пакеты, в которых были только МАС адреса и CRC. Так вот сниффер их тоже принимал и благополучно обрабатывал, как пакеты с ошибками и складывал в счетчик "непринятых данных", поэтому и до приема данных дело не доходило. Так что на уровне РС, где стандартно все настроено на прием данных, которые имеют структуру IP, могут быть проблемы. Мало того, пакеты могут и не прийти вовсе. И кто будет делать перезапрос?

[Aprox]

Насколько я помню, когда я отлаживал МАС в ПЛИС, то как раз и гонял пакеты, в которых были только МАС адреса и CRC. Так вот сниффер их тоже принимал и благополучно обрабатывал, как пакеты с ошибками и складывал в счетчик "непринятых данных", поэтому и до приема данных дело не доходило. Так что на уровне РС, где стандартно все настроено на прием данных, которые имеют структуру IP, могут быть проблемы.

Эти проблемы, как я понял, в виндах решается применением WinPCap. Под линуксом , говорят, проблем с RAW пакетами нет в вообще. Другие OS в расчет можно не брать.

Мало того, пакеты могут и не прийти вовсе. И кто будет делать перезапрос?

А вот это серьезно. Я поэтому и интересуюсь работой свитчей, ищу возможные причины, по которым могут пропадать RAW пакеты в корпоративной сети.

Шаманства и попыток "избегать" не надо. Надо просто со знанием дела выбрать, например, фрейм IEEE 802.3 (не массово используемый DIX/Ethernet II ) и индивидуальный 16bit FRAMEID из официально не занятых. И можете спать спокойно.

Подскажите пожалуйста список официально занятых FrameID. Хочу выбрать незанятый.

[zltigo]

Я поэтому и интересуюсь работой свитчей, ищу возможные причины, по которым могут пропадать RAW пакеты в корпоративной сети.

По причине кривости железа. Цена железа падает, качество обработки ошибок никого не волнует, нехай все потом будут разруливать протоколы верхнего уровня... Типичная проблема - пакет влетел в hub/switch, на _выходе_ из hub/switch коллизия. Старое доброе железо, как и положено отражало эту проблему на вход, я на сетевой карте фиксировал проблему и перепередавал. Все работало как часики. Ну а потом призводители начали все упрощать Самый первый раз столкнулся лет десять на Realtek - оборудование абсолютно с таким-же названиеми и номером для заказа. Две разницы - пластмассовый корпус и другой чип . В общем, в нагруженной сети с произвольным сетевым оборудованием пакеты изредка теряться будут.

Подскажите пожалуйста список официально занятых FrameID. Хочу выбрать незанятый.

Поищите в интернете, или возьмите 0x69 0x7B - это следующий после моего