Форум разработчиков электроники ELECTRONIX.ru > подключение устройства к ethernet

AlexY

Dec 10 2007, 09:14

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

В данный момент имеется устройство сбора информации, которое для ввода информации в PC использует плату PCI или ISA (не ругайте

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

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

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

Bird2

Dec 10 2007, 19:07

Использовать ARM7 или 9 с поддержкой Ethernet. Если необходимо куда-то вставлять (для совместимости) плату PCI или ISA, то видимо, понадобится еще и ПЛИС. Должно быть недорого.

zltigo

Dec 10 2007, 19:27

Цитата(AlexY @ Dec 10 2007, 11:14)

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

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

Aprox

Dec 11 2007, 11:55

Цитата(zltigo @ Dec 10 2007, 22:27)

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

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

zltigo

Dec 11 2007, 12:31

Цитата(Aprox @ Dec 11 2007, 13:55)

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

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

Цитата

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

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

Aprox

Dec 12 2007, 14:23

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

zltigo

Dec 12 2007, 15:27

Цитата(Aprox @ Dec 12 2007, 16:23)

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

Да.

Цитата

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

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

ishergin

Dec 12 2007, 19:00

Цитата(Aprox @ Dec 12 2007, 19:23)

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

Для Windows есть WinPcap . Через него работает сниффер Ethereal (сейчас уже подругому называется)

Aprox

Dec 13 2007, 08:31

Цитата

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

Да.

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

zltigo

Dec 13 2007, 10:09

Цитата(Aprox @ Dec 13 2007, 10:31)

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

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

.

Aprox

Dec 13 2007, 11:50

Цитата(zltigo @ Dec 13 2007, 13:09)

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

.

Да, это я ступил. Прошу прощения.

Цитата(ishergin @ Dec 12 2007, 22:00)

Для Windows есть WinPcap . Через него работает сниффер Ethereal (сейчас уже подругому называется)

О! WinPcap у меня оказывается уже стоит, его пользует сниффер WireShark. Спасибо, пошел вникать в документацию.

Aprox

Dec 17 2007, 11:40

Цитата(zltigo @ Dec 13 2007, 13:09)

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

.

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

Rst7

Dec 17 2007, 11:50

Цитата(Aprox @ Dec 17 2007, 13:40)

На каком этапе свитчи формируют у себя в памяти таблицу соответствия "порт - 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

Dec 17 2007, 12:28

Цитата(Rst7 @ Dec 17 2007, 14:50)

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

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

Rst7

Dec 17 2007, 12:55

Цитата(Aprox @ Dec 17 2007, 14:28)

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

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

Aprox

Dec 17 2007, 13:07

Цитата(Rst7 @ Dec 17 2007, 15:55)

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

Понятно. Я почему беспокоюсь? Hацелился организовать с помощью raw-пакетов приличный поток данных от девайсов и не хочется, чтобы эти пакеты распространялись по всей сети, а шли бы прямиком в компьютер. То же- из компьютера в девайсы.

Aprox

Dec 18 2007, 15:40

Цитата(Rst7 @ Dec 17 2007, 15:55)

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

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

zltigo

Dec 18 2007, 15:49

Цитата(Aprox @ Dec 18 2007, 17:40)

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

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

Rst7

Dec 18 2007, 16:04

Цитата(zltigo @ Dec 18 2007, 17:49)

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

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

Aprox

Dec 19 2007, 08:01

Цитата(Rst7 @ Dec 18 2007, 19:04)

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

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

Rst7

Dec 19 2007, 09:36

Цитата(Aprox @ Dec 19 2007, 10:01)

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

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

iosifk

Dec 19 2007, 09:48

Цитата(Rst7 @ Dec 19 2007, 12:36)

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

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

zltigo

Dec 19 2007, 10:55

Цитата(Aprox @ Dec 19 2007, 10:01)

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

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

Rst7

Dec 19 2007, 11:15

Цитата(zltigo @ Dec 19 2007, 12:55)

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

Кстати, о шаманстве. Я думаю, самое оно послать пакет с одинаковым маком источника и приемника.

Цитата

Насколько я помню, когда я отлаживал МАС в ПЛИС, то как раз и гонял пакеты, в которых были только МАС адреса и CRC.

Вот только паддить их желательно до 64 байт. И надо бы тогда или выбрать FrameID или собственный мак в destination записать.

zltigo

Dec 19 2007, 12:14

Цитата(Rst7 @ Dec 19 2007, 13:15)

Я думаю, самое оно послать пакет с одинаковым маком источника и приемника.

Долго придумывали

?

Rst7

Dec 19 2007, 12:32

Цитата(zltigo @ Dec 19 2007, 14:14)

Долго придумывали

?

А что так развеселило? Нам же надо просто свич обучить, а для этого такой пакет - самое то, не уйдет никуда, к себе только вернется и все (а может и нет, но то не суть).

Aprox

Dec 20 2007, 13:39

Цитата(iosifk @ Dec 19 2007, 12:48)

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

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

Цитата

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

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

Цитата(zltigo @ Dec 19 2007, 13:55)

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

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

zltigo

Dec 20 2007, 14:33

Цитата(Aprox @ Dec 20 2007, 15:39)

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

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

Самый первый раз столкнулся лет десять на Realtek - оборудование абсолютно с таким-же названиеми и номером для заказа. Две разницы - пластмассовый корпус и другой чип

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

Цитата

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

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

Aprox

Dec 20 2007, 17:27

Цитата(zltigo @ Dec 20 2007, 17:33)

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

Самый первый раз столкнулся лет десять на Realtek - оборудование абсолютно с таким-же названиеми и номером для заказа. Две разницы - пластмассовый корпус и другой чип

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

Черт! У меня как раз такая ситуация- свитч гигабитным портом к компьютеру, а остальными 100Мбит портами к периферийным устройствам, которые шлют в компьютер пакеты на пределе пропускной способности FastEthernet. Я думал, что в таком свитче имеется буферная память, в которой пришедшие от периферии пакеты будут выстроены в очередь перед отправкой в компьютер. И, вроде бы, описанных вами коллизий не должно быть. Может, надо аккуратно выбирать модель свитча?

Цитата

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

Спасибо за FrameID. Однако, я сейчас разбирался с одним готовым MAC, встроенным в микроконтроллер, и обнаружил, что он фильтрует фреймы с неизвестными FrameID. Ему подавай или ограниченный ряд значений типов, или там должна стоять длина фрейма не более 1500. Чем мне может грозить использовать в этом поле длину вместо неизвестного FrameID?