Объясняю. ARP это не то, это когда известен IP и нужно определить MAC. А когда IP неизвестен?
Посылается бродкаст UDP пакет на определенный порт с информацией "я Вася Пупкин, ищу брата Федю, отзовись, мой IP a.b.c.d"
Программа узнает пакет и отвечает по IP.
"Откуда взял", не помню, я уж больше 15и лет со всем этим хозяйством. Да хоть RFC почитайте, я ссылку приводил.
Посмотрите как Apple свои устройства в сети определяет.



Виноват, не точен. Можно запретить прием бродкастов/мултикастов на уровне ethernet controllera.

Данные реального времени, идет поток с датчиков. О другой части, кто принимает эти сигналы, они ничего не знают.
Поэтому и UDP broadcast.

Только вот беда-то - как-же другим устройствам жить??? Которым не посчастливилось оказаться в одной сети с этим говорливым поделием...
Ведь оно завалит теперь всех в сети своими броадкастами...
Если в этой организации в сети имеются и другие изделия на маломощных CPU, их разработчикам тоже прикажете заменять CPU на более мощный чтоб в чужом кале не утонуть?


Не обязательно. ARP может использоваться и для других целей.
Например у себя в изделии я использую его для проверки занятости IP-адреса. Это ещё одна возможность ARP.
Достаточно поставить IP-источника = 0.
Не знаю, но наверное можно и адрес назначения поставить в 0, тогда никто случайный на Ваши ARP-кадры не ответит.
А когда IP неизвестен, для этого есть другой протокол: RARP. Почитайте про него.


За 15 лет Вы могли-бы найти время и прочитать про ARP/RARP всё

Я понимаю что на 90% целью форума является загнобить человека, для этого надо найти единомышленика, не понять задачу, и начать кидать шапками.

Если почитать внимательно, станет понятно следующее
1. Сеть UDP brodcastami грузит не устройство ТС, а внешние устройства, чужие, которые не переделаешь, с этим просто надо жить.
2. Устройство ТС не успевает жевать бродкасты потому что занято другими делами помимо Ethernet

Зачем столько жевать что сделано не верно, если это изменить нельзя? ЧУЖИЕ устройства так сделаны, и в такой сети надо просто выживать.

3. Когда оцениваете 15 летний опыт, хорошо бы затратить хотя бы 15 минут своего времени на разбор задачи.
ARP и RARP дают вторую часть пары IP - MAC, когда известна первая.
То есть зная MAC можно получить IP, зная IP можно получить MAC.

Теперь вопрос к клубу "знатаков" как узнать IP и MAC одновременно?

Негодую я от такого поведения господа... не разобрались что происходит, и давай шапками кидаться!

П.С. Сети бывают разные, у нас есть сеть приборов компьютер и несколько девайсов. Она отрезана от внешнего мира, а внутри происходит полная вакханалия, но это сделано осознано, потому что так она лучше масштабируется и управляется. Ее можно было сделать вообще на сыром Ethernet без IP, но это неудобно для компьютера, потому в ней ТСР/IP. Но сеть изначально предполагалась выделенной, чтобы в ней никого другого не было.

Это примерно как вилка на 12 вольтовом приборе, которую можно в 220 запихать. Наличие такой вилки не означает что ее надо пихать в 220, это означает что человек хотел использовать стандартные розетки, в своей 12 вольтовой цепи и все.

Вот это (нигде, правда, не встречал) может быть применимо. Тут нет потока данных с broadcast, которые глушат всё остальное. Послали/приняли пару broadcast сообщений и перешли в нормальный режим. Никого не повесили.

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

Тут ещё раз расскажите, что значит "на уровне ethernet controllera"? На уровне PHY? На уровне MAC?
На сколько известно мне - приём broadcast запретить нельзя!!!


тут наверно имелось ввиду - посчастливилось, они ведь должны быть безумно счастливы приёму кучи ненужного broadcasta

Да ну!

А как вам там с ШИМ-ом получается?
Удалось застабилизировать spread spectrum?

Лучше читайте документацию!

Не знаю - весь тред не читал, но из первого сообщения ТС это не следует.


Не знаю как так можно занять Cortex, чтобы он не успевал не свои кадры отсеивать.. %-)
Сейчас как раз занимаюсь Ethernet в устройстве на LPC1768 (100МГц). Оно включено тоже в корпоративную сеть с неск. сотнями устройств.
Если включить встроенный снифер, то получаю непрерывный большой поток широковещательных (и не только) ARP-, IP/UDP-кадров,
и некоторых других типов кадров.
Загрузка CPU при этом (в целом, там почти ничего нет только uCOS крутится, да снифер инфу о потоке в UART выводит) составляет 0.8 ... 1.0 %.
И где я не прав?
И то это у меня драйвер проверяет каждый пакет, а не только свои (валидность заголовков Ethernet/ARP/IP/TCP/..., контрольные суммы считает).
А если отбрасывать сразу не свои по какому-то признаку, то загрузки тут вообще практически никакой не должно быть.
Если, как пишет ТС, кадры идут с периодом 10мкс, и работает Ethernet-DMA, то на все действия в ISR Ehternet хватит с лихвой ~100тактов.


Это Вы так поняли. И это совсем не следует из вопроса ТС.
Вменяемые чужие устройства даже в большой сети, не генерят столько широковещательного траффика.
Я прямо сейчас смотрю в лог сниффера, который выводит моё устройство на LPC1768 находящееся в достаточно большой корпоративной сети.

А мне кажется, что человеку просто сказали как должно быть правильно и по всем стандартам. Чтоб все жили мирно и счастливо.


Зачем тогда утверждать, что всё сделано правильно и по стандарту. И на стандарт ссылаться в котором ни слова нет о таком применении broadcast.
Может лучше (по возможности) один раз сделать правильно и по всем стандартам и далее пользоваться этим решением, чем каждый раз при увеличеннии потока broadcast-ов менять процессор.


Это не оправдывает использование broadcast для передачи широкополосного потока данных.
Для целей "как узнать IP и MAC одновременно" можете его и использовать, тут и не будет противоречия при построении сети ethernet.
На сколько помню, Вы всегда были за надёжность и качество устройств. Ваши слова из одной темы:

Очень подходит для оценки устройств, что заглушили модуль автора топика


Это утверждение, что можно?
Расскажите пожалуйста, каким образом (без использования софта) Вы фильтруете broadcast? Вы, видимо, изобрели какой-то свой MAC-контроллер который внедряете в какие-то свои процессоры?
Расскажите, может приобретём парочку для тестов


Про ШИМ я спрашивал в другой теме (она, кстати, не закрыта), и Вы там ничего дельного посоветовать не смогли и умыли руки. Если знаете возможные причины проблемы обсуждаемой в той теме - добро пожаловать, буду благодарен за полезные советы.

Ну вы сравнили.
uCOS это совсем другое дело!
Это самый быстрый и правильный стек из всех доступных для мелких контроллеров.

Да и снифер скорее всего не в сегменте устройства, а небось отделен свитчером. Так что картину показывает скорее всего искаженную.
Опыты со снифером Wireshark показывают, что доверять ему можно только частично, и надо еще смотреть настройки сетевого драйвера PC.

Нет, Вы не поняли
Только ОС - uCOS. Стек к сожалению свой, не uCOS-кий.


Сниффер у меня - это часть моего ПО на LPC, которая выводит в лог поток всех кадров, которые лезут с RMII.

Извините конечно, но я ту вашу тему зафоваритил как живой анекдот.
Поэтому не хочу ничего добавлять, а то будет не смешно.



Немного не системно. Снифер должен быть независим от TCP стека, а то как-то резко падает доверие.

У меня все входящие кадры проходят через сниффер и только после него попадают в штатный обработчик.
Если-б что-то терялось и не отображалось в сниффере, оно-бы и до штатного обработчика не доходило.
А я уже не раз проверял работу ПО передачей большого многомегабайтного потока (через TCP-сокет) - ничего не теряется.
И стек построен на callback-вызовах - если-бы были пропуски из-за переполнения приёмной очереди, то загрузка у CPU была-бы близка к 100%.
А она даже при тестовом TCP-потоке (по двум сокетам одновременно) максимум до 7% доходит.

Расскажите мне тогда Ваш анекдот про broadcast и то, как его фильтровать, тоже хочу посмеяться

Я считаю по другому.
Возмем реалистичный 70 Mbit поток по Ethernet. Это 8 Мбат в сек данных.
Писать вам такой поток некуда.
Внешней памяти нет. На SD такую скорость не разовьете, а если б развили то 100% загрузки CPU точно было бы.
Даже на внутренней шине пересылка такого поток заняла бы гораздо больше 7%.

Вообще все это подозрительно.

Загрузку может неправильно определяете?

вот что пишет ТС в 1 сообщении



я понял что другие "не наши". По ходу он это уточнил, да они действительно не их.





Да так и есть, сторонние устройства сделаны не корректно. Но что вас убережет от их появления? Это данность среды в которую попал ТС. И для обеспечения надежности своего устройства, оно должно справляться со средой, а не изменять ее.

Как то нам надо было в протокол чужого устройства добавить команду (команда была реализована через меню, а нам надо было через ком порт, который был штатный у них и половину команд выполнял), при условии что мы были весьма эксклюзивными потребителями их продукции, и чуть ли не обеспечивали им выход на рос рынок, были вежливо посланы.

Есть среда - надо в ней жить, а не менять. Пробовать менять можно, но это процесс долгий, и полон чертиков в коробочках....


И ваще во всем виновата операционка я уверен, это она все ресурсы скушала...





снова невнимательно читаете. Идея была заглушить UDP вообще. Для этого и надо 2 устройства. Одно полное живет в сети отвечает на все вопросы ARP и так далее, и жует входной поток. Из него выдирает те сообщения что нужно и по ТСР на четки IP передает их, так же получает ответы и шлет в сеть. Второе устройство с урезанным езернет функционалом, без UDP ваще, все пакеты UDP просто игнорирует, и принимает только ТСР от первого устройства. В экстрим режиме, даже не ТСР а вообще raw ethernet.

Таким образом все UDP пакеты что бродкаст размером 100 байт и идут через 10 мкс, отвергаются значительно быстрее по признаку UDP, чем по разбору содержимого, и высвобождают ресурсы. Вот такое было предложение. Это костыль и заплатка- это не решение. Оно просто позволяет на существующей плате только подправив софт получить готовое устройство и не более того.

Да, должно, но для этого надо потратить время и деньги. И можно говорить о кривости и несовместимости тех остальных девайсов. И если не указать на ошибки, то broadcast так и будет использоваться для передачи огромного потока данных, а другие будут этот поток фильтровать и не расскажут остальным - КАК?!