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

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

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

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

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

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

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

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

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



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

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

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

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



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



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

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

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

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

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