Посоветуйте микроконтроллер, для IP (UDP) filtering Опции

[A. Fig Lee]

В общем, в одной ethernet сети по производственной необходимости оказалось наше устройство на STM32F107 и
много других, которые шлют UDP broadcast.
Так как это ethernet broadcast, приходится принимать все пакеты, потом сбрасывать, когда ясно что не нам.
В итоге периодически затыкается контроллер, так как есть и другие задачи.

Хочу разбить на 2: один микроконтроллер с ethernet будет фильтровать IP пакеты, другой делать другие задачи.
Как бы его и так хватает, это чисто раутер с 802.15.4 250 килобит на IP.
Если бы не затыкался. Какой взять не очень большой микроконтроллер с ethernet?
Хорошо бы еще канал пошире для обмена с другим микроконтролером, но это вряд ли.
Наверное, обычный SPI.

Думал поставить Wiz5100 для фильтра бродкаст пакетов, но он же, наверное, пропустит UDP бродкаст пакет?

[Golikov A.]

Ну все верно. Не хватает ресурсов на работу, потому что задолбили пакетами - ставь выделенный обработчик. А поставить 2 одинаковых проца - дорого? Зачем элементную базу то плодить?

Можно кстати красиво решить: Ставьте в сеть 2 ваших устройства, на первом, что делает дело, выключайте UDP вообще, на втором создавайте TCP соединение с первым, и пусть он пакеты фильтрует, и те что к устройству по ТСР отдает первому, тот обрабатывает и возвращает обратно. Тогда даже плату переразводить не надо, просто 2 штуки поставить.

[A. Fig Lee]

Ну все верно. Не хватает ресурсов на работу, потому что задолбили пакетами - ставь выделенный обработчик. А поставить 2 одинаковых проца - дорого? Зачем элементную базу то плодить?

Можно кстати красиво решить: Ставьте в сеть 2 ваших устройства, на первом, что делает дело, выключайте UDP вообще, на втором создавайте TCP соединение с первым, и пусть он пакеты фильтрует, и те что к устройству по ТСР отдает первому, тот обрабатывает и возвращает обратно. Тогда даже плату переразводить не надо, просто 2 штуки поставить.

Да както некузяво. И так 100 ножковый СТМ32 стоит. Еще один 100 ножковый ради ethernet только.
2. Красиво не получится. Как они будут соединятся, в том же сегменте?
Там фишка же в том, что UDP broadcast приходит в пакете ethernet broadcast. То есть 2й, где UDP выключено, все равно будет принимать весь поток так как вунужден принимать ethernet broadcast - вдруг там ARP? и анализировать.

А, просто, поставить более мощный процессор? Не с 72 МГЦ, а, например, с 720 МГЦ ? Или свет клином именно на этом сошелся?

Какой имеено процессор рекомендуете? Все они, как правило, уже более навороченные. Не ставить же А8 для простого раутера?

Для этого используется IP multicast (для передачи сообщения нескольким адресатам). MAC-адрес в этом случае формируется по определённым правилам, а тут описано по каким.

Broadcast MAC-адрес используется только в ARP-запросах, но они-то точно не должны вешать сеть.

Не верю!
Вот документ:
http://tools.ietf.org/html/rfc1122#page-66

When a host sends a datagram to a link-layer broadcast address,
the IP destination address MUST be a legal IP broadcast or IP
multicast address.

Все нормально: UDP бродкасты посылаются с MAC бродкастами

[doom13]

Не верю!

Чему именно не верите, что broadcast не используется для передачи данных, а используется в ограниченном числе протоколов? Тогда Google в помощь.

Все нормально: UDP бродкасты посылаются с MAC бродкастами

Broadcast используется в основном для служебной информации или для передачи другой исключительно узкополосной информации. Если Вы начнёте бомбить данные при помощи broadcast - заглушите все устройства в сети, что и произошло.

[A. Fig Lee]

Чему именно не верите, что broadcast не используется для передачи данных, а используется в ограниченном числе протоколов? Тогда Google в помощь.


Broadcast используется в основном для служебной информации или для передачи другой исключительно узкополосной информации. Если Вы начнёте бомбить данные при помощи broadcast - заглушите все устройства в сети, что и произошло.

При чем здесь "ограниченное число протоколов"? Бродакст используется там, где он оправдан, а не там, где "гугл разрешил".
Не верю тому, что "неправильно посылать UDP broadcast с MAC broadcast".
Все законно.
Бывает, что надо и данные передавать при помощи бродкаст, как видим.
То, что Вам такая ситуация не попадалась, ни о чем не говорит. С опытом прийдет.

[doom13]

При чем здесь "ограниченное число протоколов"? Бродакст используется там, где он оправдан, а не там, где "гугл разрешил".

При том, что broadcast используется только в ARP, DHCP (может быть где-то ещё), т.е. в протоколах которым не требуется широкая полоса, где нет большого потока информации.

Не верю тому, что "неправильно посылать UDP broadcast с MAC broadcast".
Все законно.

Вы можете не верить, но это так. Вашему устройству нет необходимости принимать тот "ненужный" поток информации. Оно должно было находясь в данной сети выполнять какие-то другие функции. Вот если бы при передаче данных по UDP использовался не broadcast а multicast, Вы бы смогли легко фильтрануть все ненужные Вам пакеты и не ломали бы голову, как же устранить данную проблему. С другой стороны узлы, которым необходима данная информация её бы и принимали, только настроить их надо было бы правильно - на приём мультикаста (выше написано как).

Бывает, что надо и данные передавать при помощи бродкаст, как видим.
То, что Вам такая ситуация не попадалась, ни о чем не говорит. С опытом прийдет.

Как видим, передача при помощи broadcast добавила Вам лишних проблем, которых могло бы и не быть если разобраться с multicast.
Скорее всего с опытом к Вам придёт понимание того, что в данной ситуации нужно было использовать групповой IP-адрес, а не строить "костыль" для выхода из ситуации.