Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: подключение устройства к ethernet
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > Fast Ethernet/Gigabit Ethernet/FibreChannel
AlexY
Всем добрый день,

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

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

Заранее спасибо.
Bird2
Использовать ARM7 или 9 с поддержкой Ethernet. Если необходимо куда-то вставлять (для совместимости) плату PCI или ISA, то видимо, понадобится еще и ПЛИС. Должно быть недорого.
zltigo
Цитата(AlexY @ Dec 10 2007, 11:14) *
Возможно ли обойтись без реализации TCP IP?

Разумеется да - на RAW Socket можете творить что угодно, ну или почти все, что угодно, если этим интерфейсом будет еще кто-то пользоваться.
Aprox
Цитата(zltigo @ Dec 10 2007, 22:27) *
Разумеется да - на RAW Socket можете творить что угодно, ну или почти все, что угодно, если этим интерфейсом будет еще кто-то пользоваться.


Подскажите, где берут программную поддержку для RAW Socket-ов на стороне компьютера. В составе WinSock я ничего похожего не нашел.
zltigo
Цитата(Aprox @ Dec 11 2007, 13:55) *
Подскажите, где берут программную поддержку для RAW Socket-ов на стороне компьютера.

Для Linux - нигде не берут smile.gif
Цитата
В составе 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
Цитата(Aprox @ Dec 12 2007, 16:23) *
создать в Windows XP сокет, который работал бы с периферийными устройствами на канальном уровне, простейшими Ethernet фреймами по физическим МАС адресам

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

А вот про это лучше забудьте.
ishergin
Цитата(Aprox @ Dec 12 2007, 19:23) *
Спасибо за ссылки. Вникаю. Меня интересует возможность создать в Windows XP сокет, который работал бы с периферийными устройствами на канальном уровне, простейшими Ethernet фреймами по физическим МАС адресам и увеличенным размером пакета, без IP протокольных наворотов. Возможно такое в Windows? Если возможно, то куда посоветуете смотреть?


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

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

Да.


Интересно, как будут себя вести "умные" свичи в составе сети, если послать не IP пакет, а пакет только с физическими адресами в заголовке? Умные- это которые запоминают распределение IP адресов девайсов на своих портах. Ведь, в рассматриваемых "сырых" пакетах нет IP хидера. Мне кажется, совсем "сырые" пакеты разумно использовать только в соединениях точка-точка.
zltigo
Цитата(Aprox @ Dec 13 2007, 10:31) *
Интересно, как будут себя вести "умные" свичи в составе сети

Свитчи, естественно, работают по MAC адресам. IP им без надобности smile.gif.
Aprox
Цитата(zltigo @ Dec 13 2007, 13:09) *
Свитчи, естественно, работают по MAC адресам. IP им без надобности smile.gif.

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

Цитата(ishergin @ Dec 12 2007, 22:00) *
Для Windows есть WinPcap . Через него работает сниффер Ethereal (сейчас уже подругому называется)

О! WinPcap у меня оказывается уже стоит, его пользует сниффер WireShark. Спасибо, пошел вникать в документацию.
Aprox
Цитата(zltigo @ Dec 13 2007, 13:09) *
Свитчи, естественно, работают по MAC адресам. IP им без надобности smile.gif.


На каком этапе свитчи формируют у себя в памяти таблицу соответствия "порт - MAC адрес"? Сомневаюсь, ведь устройство, работающее на raw пакетах без IP, не будет отвечать на стандартные ARP запросы. Как же свитч поймет, что к данному порту подключено устройство с таким-то MAC адресом? 05.gif
Rst7
Цитата(Aprox @ Dec 17 2007, 13:40) *
На каком этапе свитчи формируют у себя в памяти таблицу соответствия "порт - MAC адрес"? Сомневаюсь, ведь устройство, работающее на raw пакетах без IP, не будет отвечать на стандартные ARP запросы. Как же свитч поймет, что к данному порту подключено устройство с таким-то MAC адресом? 05.gif


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

Цитата
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
Цитата(Rst7 @ Dec 17 2007, 14:50) *
Как видите, он смотрит на ВСЕ пакеты, а не только на ARP

Спасибо. Насколько я понял, на первом этапе, когда еще нет MAC таблица еще сформирована, или не соответсвует действительности, свитч рассылает поступившие пакеты во все порты. Далее, по мере прихода пакетов с других портов, по их source адресам заполняет таблицу "MAC-порт". Я правильно понял текст?
Rst7
Цитата(Aprox @ Dec 17 2007, 14:28) *
Спасибо. Насколько я понял, на первом этапе, когда еще нет MAC таблица еще сформирована, или не соответсвует действительности, свитч рассылает поступившие пакеты во все порты. Далее, по мере прихода пакетов с других портов, по их source адресам заполняет таблицу "MAC-порт". Я правильно понял текст?


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

a14.gif Понятно. Я почему беспокоюсь? Hацелился организовать с помощью raw-пакетов приличный поток данных от девайсов и не хочется, чтобы эти пакеты распространялись по всей сети, а шли бы прямиком в компьютер. То же- из компьютера в девайсы.
Aprox
Цитата(Rst7 @ Dec 17 2007, 15:55) *
Безусловно. Допустим, у нас безмозглая железка генерирует RAW-пакеты с правильными MAC-адресами (заранее задаными). В результате, первый же пакет от железки установит соответствие MAC<->PORT для железки, хотя, если не нужно принимать пакеты, это не особо и надо. А куда же отроутится пакет? Полетит он скорее всего в нужный порт, к которому подключен комп, т.к. стек сетевых протоколов на компе тоже проявляет некоторую активность (особенно виндозный, всякие девайсы PnP в сети ищет). В крайнем случае на компе можно просто пинг запустить хоть и не в существующий девайс.


Каверза возникла. Если безмозглая железка не генерирует RAW пакеты, а наоборот - только принимает пакеты молча, то свитч никогда ее обнаружить на порту не сможет и будет рассылать широковещательно. Получается, read only режим неэффективен в случае применения свитча и RAW пакетов.
zltigo
Цитата(Aprox @ Dec 18 2007, 17:40) *
Если безмозглая железка ...
...
то свитч никогда ее обнаружить на порту не сможет и будет рассылать широковещательно.

Ну так если все "безмозглые", то кому-то придется добавить мозгов, либо железке, либо switch-у, либо компьютеру. Выбирайте.
Rst7
Цитата(zltigo @ Dec 18 2007, 17:49) *
Ну так если все "безмозглые", то кому-то придется добавить мозгов, либо железке, либо switch-у, либо компьютеру. Выбирайте.


да ну пусть раз в полсекунды каждая железка плюнет пакетом со своим маком. И все будет ок.
Aprox
Цитата(Rst7 @ Dec 18 2007, 19:04) *
да ну пусть раз в полсекунды каждая железка плюнет пакетом со своим маком. И все будет ок.

Пусть то оно пусть, но уже лишние сложности наметились. Вообще, постепенно прихожу к мысли, что IP навороты в протоколах недаром были созданы и стандартизованы. Попытки их избежать с помощью очень "сырых" пакетов Ethernet чреваты вляпаться в непредусмотренные проблемы.
Rst7
Цитата(Aprox @ Dec 19 2007, 10:01) *
Пусть то оно пусть, но уже лишние сложности наметились. Вообще, постепенно прихожу к мысли, что IP навороты в протоколах недаром были созданы и стандартизованы. Попытки их избежать с помощью очень "сырых" пакетов Ethernet чреваты вляпаться в непредусмотренные проблемы.


В принципе, особо никакой сложности не вижу. И зря боитесь, будет все работать.
iosifk
Цитата(Rst7 @ Dec 19 2007, 12:36) *
В принципе, особо никакой сложности не вижу. И зря боитесь, будет все работать.

Насколько я помню, когда я отлаживал МАС в ПЛИС, то как раз и гонял пакеты, в которых были только МАС адреса и CRC. Так вот сниффер их тоже принимал и благополучно обрабатывал, как пакеты с ошибками и складывал в счетчик "непринятых данных", поэтому и до приема данных дело не доходило. Так что на уровне РС, где стандартно все настроено на прием данных, которые имеют структуру IP, могут быть проблемы. Мало того, пакеты могут и не прийти вовсе. И кто будет делать перезапрос?
zltigo
Цитата(Aprox @ Dec 19 2007, 10:01) *
Попытки их избежать с помощью очень "сырых" пакетов Ethernet чреваты вляпаться в непредусмотренные проблемы.

Шаманства и попыток "избегать" не надо. Надо просто со знанием дела выбрать, например, фрейм IEEE 802.3 (не массово используемый DIX/Ethernet II ) и индивидуальный 16bit FRAMEID из официально не занятых. И можете спать спокойно.
Rst7
Цитата(zltigo @ Dec 19 2007, 12:55) *
Шаманства и попыток "избегать" не надо. Надо просто со знанием дела выбрать, например, фрейм IEEE 802.3 (не массово используемый DIX/Ethernet II ) и индивидуальный 16bit FRAMEID из официально не занятых. И можете спать спокойно.


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

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


Вот только паддить их желательно до 64 байт. И надо бы тогда или выбрать FrameID или собственный мак в destination записать.
zltigo
Цитата(Rst7 @ Dec 19 2007, 13:15) *
Я думаю, самое оно послать пакет с одинаковым маком источника и приемника.

Долго придумывали smile.gif?
Rst7
Цитата(zltigo @ Dec 19 2007, 14:14) *
Долго придумывали smile.gif?


А что так развеселило? Нам же надо просто свич обучить, а для этого такой пакет - самое то, не уйдет никуда, к себе только вернется и все (а может и нет, но то не суть).
Aprox
Цитата(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
Цитата(Aprox @ Dec 20 2007, 15:39) *
Я поэтому и интересуюсь работой свитчей, ищу возможные причины, по которым могут пропадать RAW пакеты в корпоративной сети.

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

Поищите в интернете, или возьмите 0x69 0x7B - это следующий после моего smile.gif
Aprox
Цитата(zltigo @ Dec 20 2007, 17:33) *
По причине кривости железа. Цена железа падает, качество обработки ошибок никого не волнует, нехай все потом будут разруливать протоколы верхнего уровня... Типичная проблема - пакет влетел в hub/switch, на _выходе_ из hub/switch коллизия. Старое доброе железо, как и положено отражало эту проблему на вход, я на сетевой карте фиксировал проблему и перепередавал. Все работало как часики. Ну а потом призводители начали все упрощать sad.gif Самый первый раз столкнулся лет десять на Realtek - оборудование абсолютно с таким-же названиеми и номером для заказа. Две разницы - пластмассовый корпус и другой чип sad.gif. В общем, в нагруженной сети с произвольным сетевым оборудованием пакеты изредка теряться будут.

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

Спасибо за FrameID. Однако, я сейчас разбирался с одним готовым MAC, встроенным в микроконтроллер, и обнаружил, что он фильтрует фреймы с неизвестными FrameID. Ему подавай или ограниченный ряд значений типов, или там должна стоять длина фрейма не более 1500. Чем мне может грозить использовать в этом поле длину вместо неизвестного FrameID?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.