[Arlleex 331]

2 часа назад, dxp сказал:

Тогда после енумерции пусть ARP таблицу обновляет, и всё.

Короче: Вы предлагаете заполнить статически ARP-таблицу после энумерации, так?

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

[tonyk_av 77]

1 hour ago, mantech said:

Сделайте свой сегмент эзернета ТОЛЬКО для промавтоматики и все станет норм, проверено неоднократно.

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

Я прекрасно понимаю что и как делать, но проблема в том, что вышестоящее руководство не понимает, почему 200 камер нормально передают картинку, а десяток ПЛК на линиях плохо работают. Все эти разделения требуют денег на кабель, на его прокладку, требуют покупки сетевого оборудования, а это не 100 рублей стОит.

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

1 hour ago, Arlleex said:

А Ваш пример с CAN-ом абсолютно неудачный, т.к. подключите вирусный девайс и шлите CAN ID == 0

Так ведь CAN в ПЛК, в которые ничего не воткнёшь, и стоят они в шкафах, а компы- вот они, на столах у персонала, суй в них кто-чё хочет, например, флэшку с заразой.

[dxp 198]

5 минут назад, Arlleex сказал:

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

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

[Arlleex 331]

4 минуты назад, tonyk_av сказал:

Так ведь CAN в ПЛК, в которые ничего не воткнёшь, и стоят они в шкафах, а компы- вот они, на столах у персонала, суй в них кто-чё хочет, например, флэшку с заразой.

То то же. У меня тоже сеть закрытая, отдельная, никуда во вне не подключенная, изолированная.

 

1 минуту назад, dxp сказал:

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

Понял. Ну, попробую коллегам своим намекнуть, потестируем. Спасибо.

[tonyk_av 77]

1 hour ago, Arlleex said:

эзернет вполне себе достаточен для вполне надежной сети

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

[jcxz 359]

15 минут назад, Arlleex сказал:

Практика показала, что LwIP не успевает. А писать свое в данном случае будет весьма накладно.

Конечно своё. Прям в ISR. Не обязяательно ISR от Ethernet-RX. Можно в менее приоритетном, чтобы сразу для группы ARP-кадров. Для минимизации затрат тактов CPU.

[mantech 132]

13 минут назад, tonyk_av сказал:

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

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

[Arlleex 331]

2 часа назад, tonyk_av сказал:

Надёжен для чего? Данные передаёт надёжно, но задержку не гарантирует.

Задержка - по нашим тестам эта задержка передачи коммутатора, она ничтожно мала для наших требований.

2 часа назад, jcxz сказал:

Конечно своё. Прям в ISR. Не обязяательно ISR от Ethernet-RX. Можно в менее приоритетном, чтобы сразу для группы ARP-кадров. Для минимизации затрат тактов CPU.

Да было бы просто здорово, если в той же STM-ке был фильтр по заголовку ARP, который не пропускал кадр на уровень выше, если IP-шник в целевом поле не совпадал.

2 часа назад, tonyk_av сказал:

Для вас вон, даже задержка на обработку служебных пакетов оказывается критичной, а вы всю концепцию проекта на нём построили, что странно.

Не задержка на обработку для нас критична, а потенциальные "бродкаст-штормы" из следующих друг за другом ARP-ов. Это разные вещи.

[mantech 132]

28 минут назад, Arlleex сказал:

Практика показала, что LwIP не успевает.

Значит выкинуть эту требовательную к дин. памяти и пр. вещам каку, пока сам не сделал так года 4 назад, все мучался с этим делом...

6 минут назад, Arlleex сказал:

а потенциальные "бродкаст-штормы" из следующих друг за другом ARP-ов.

А на приеме кадра программно фильтровать бродкаст не вариант, еще до всех стеков?

[Arlleex 331]

1 минуту назад, mantech сказал:

Значит выкинуть эту требовательную к дин. памяти и пр. вещам каку, пока сам не сделал так года 4 назад, все мучался с этим делом...

Не, я дожму ее, а если потом надо будет еще что-то добавить сложнее UDP, тогда подумаю. А сейчас необходимость "не настоялась".

[mantech 132]

35 минут назад, Arlleex сказал:

Вагоны могут прицепляться/отцепляться, разворачиваться, перестыковываться и т.д.

У вагона есть ведь серийный номер, он уникальный? Самое простое - заложить его в мак-адрес, и мак выдумывать не надо и он идеально идентифицирует вагон...

[jcxz 359]

9 минут назад, mantech сказал:

А на приеме кадра программно фильтровать бродкаст не вариант, еще до всех стеков?

Я именно это и предложил выше. Направить фильтром MAC широковещательные кадры в отдельную очередь. Которую обрабатывать при накоплении там не менее N кадров (или по таймауту) прям внутри ISR. Все необработанные широковещательные (не ARP-кадры) - пускать на вышележащие уровни.

Не знаю - можно ли в STM сделать две очереди принимаемых кадров (для двух масок фильтров)? Если можно - должно работать.

В крайнем случае - одна большая приёмная очередь кадров. Которую также периодически пробегать в низкоприоритетном ISR. И только после - не обработанные этим ISR входящие кадры - отправлять уровню выше (LwIP).

[mantech 132]

4 минуты назад, jcxz сказал:

В крайнем случае - одна большая приёмная очередь кадров.

ТС писал, что у него памяти мало... Хотя при этом же использовать lwip - такое себе... Я б при этом uip выбрал, и памяти почти не жрет и тормозов почти нет...

Edited March 9, 2025 by mantech

[Arlleex 331]

25 минут назад, mantech сказал:

У вагона есть ведь серийный номер, он уникальный? Самое простое - заложить его в мак-адрес, и мак выдумывать не надо и он идеально идентифицирует вагон...

Все сильно сложнее, чем может показаться, поэтому не вижу смысла тут особо эту тему мусолить, просто если было бы "слишком просто", мы бы так и сделали))

Блоки ничего о серийных номерах вагонов не знают, более того, при всяких обслуживаниях/ремонтах и т.д. могут кочевать вплоть до другого поезда.

34 минуты назад, mantech сказал:

А на приеме кадра программно фильтровать бродкаст не вариант, еще до всех стеков?

Да можно, наверное. Но пока что не хотелось сильно точить напильник.

23 минуты назад, mantech сказал:

Я б при этом uip выбрал, и памяти почти не жрет и тормозов почти нет...

Так он же древний как мамонт)) А мы только ноу-хау одобряем😅

28 минут назад, jcxz сказал:

Я именно это и предложил выше. Направить фильтром MAC широковещательные кадры в отдельную очередь.

...

В крайнем случае - одна большая приёмная очередь кадров. Которую также периодически пробегать в низкоприоритетном ISR.

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

[mantech 132]

14 часов назад, Arlleex сказал:

Так он же древний как мамонт))

Так TCP-IP еще древнее)))))))

14 часов назад, Arlleex сказал:

А мы только ноу-хау одобряем

Ноу-хау хороши тогда, когда приносят пользу, ускоряют процесс и пр, а иначе это хау-ноу))))))))