Так и я о том же, почему то всегда интересная тема образуется как офтоп.
К счастью таких заказчиков найти не проблема, но найти надежное проверенное решение гораздо труднее.
Тут наверно ветку порежут... END.

Добрые люди модераторы перенесите ветку. И я наконец объясню теоретикам почему устройство с простеньким стеком и контроллером не выживет в реальной не управляемой сети И про глючной камень ещё добавлю

Сообщение отредактировал Mihail Gluhowchenko - Jan 14 2009, 02:43

Moderator:
Выделено из темы http://electronix.ru/forum/index.php?showtopic=57576&hl=

заранее сорри за оффтоп,
но я лично на предложения установить флеш-плейер, адд-оны, плаг-ины и прочую требуху типа актив-Х матерно жму кнопку "ни в коем случае!"
Так что для Вас я и подобные мне товарищи - потерянные потенциальные клиенты.
Всегда надо предлагать людям альтернативу, пусть это даже будет простейшая табличная вёрстка без картинок
А привычка такая пошла с тех времён, когда тратить несколько метров траффика на загрузку одной страницы было непозволительной роскошью
Всё, закончил, ещё раз извините.

Давайте. Только, похоже, теоретик тут Вы. Я то могу своих клиентов сюда пригласить для разрешения споров.



Это про какой?

Друзья! Побольше бы такого "оффтопа", о котором Вы говорили, жить было бы интереснее))))

Это мы запросто

Вообще-то мне кажется, что нет у нас на форуме подходящего раздела для таких тем, ведь обсуждение, как видите, уже вышло за рамки "сделать устройство", оно перешло в область обсуждения построения системы, включающей в себя и железяки, и ПО, и прочее. Я сейчас пробежался по списку разделов, есть раздел "Вопросы системного уровня проектирования", но как-то там тоже не та тематика, не наблюдается системного подхода.

С другой стороны, у нас на форуме редко поднимаются такие вопросы. Непонятно, кстати, почему.

Камень BF532.

Простой котроллер != полноценный IP стек, работать просто небудет долго и стабильно, как он переживет стандартные IP MAC шторм например? Или другие каки которые пользователи могут организовать намеренно?
Не полноценные LwIP, или свой маленький наложили структурку разобрали пакетик, гарантированно жить небудут.

Ооо. А как же все стеки-то работают? Просветите нас, убогих? Неужели придумали другие способы разбора пакетов, кроме как по указателям на структуры? Ах да, мастера, они по байтику из пакета берут и потом клеят нужные поля в рукопашную



Обоснуйте. Утверждение голословно. На все 100.



И что такое "стандартный IP MAC шторм"? Это какой RFC?

B это все!?



Жалко, я ожидал полного разгрома.
Профи по Blackfin-ам не должен отделываться такими слабыми аргументами.
Проблема видимо в uCLinux. Эта штука может лишить здравого смысла любой процессор.

На самом деле придираться к ненадежности работы на физическом уровне low-end микроконтроллеров не стоит.
Если уж совсем не сделано безобразно, как например, китайцы любят трансформатор в Ethernet заменять резисторами.

Плотно работая с локальным клиентом, вполне можно сделать достаточно надежное решение на уровне передач по TCP/IP.
И дешевое будет экстремально.
Вот апнот от Microchip-а, где они дают раскладку ресурсов на их PIC-и при реализации TCP/IP.
http://ww1.microchip.com/downloads/en/AppNotes/00833c.pdf
Имея в виду что чип стоит 3-и бакса, плата однослойная может быть сделана полукустарно за 0.5$ и трансформатор заменен резисторами получаем себестоимость изделия в пределах 5$ вместе с упаковкой.

Не намного дороже будет если делать на Luminary Micro и на их бесплатном стеке, зато будет MDIX и 100Base-T.

В медиаканале действительно есть риск, что на дивайс ломанется адресуемый ему поток по Ethernet вызванный взбесившимся роутером.
Если поток достаточно плотный, то дивайсы неизбежно будут терять те редкие пинги которые будут к ним идти для пробинга.
Но это очень редкий случай, а сами дивайсы имеют аппаратную фильтрацию по MAC-у назначения.
Клиент правда для таких дивайсов не сможет применть широковещательные запросы пробинга, что усложнит ему администрирование, но было сказано что клиент не против. (А может еще не понял? )

С другой стороны мы не знаем на чем у уважаемого Rst7 сделан дивайс.
Он может в принципе быть сделан и на STR912 или ColdFire, тоже в принципе весьма недорогих микроконтроллерах.
Вот они могут фильтровать трафик по тэгу VLAN в Ethernet пакете и могут стоять прямо в линии где гуляет 100 мегабитный поток и при этом не захлебываться трафиком.
ColdFir-ы еще и могут обнаружить и сообщить о преднамеренном флуде и атаках на MAC уровне не теряя связи с целевым хостом.


О применимости простых решений может свидетельствовать тот факт, что сверхдешевые Ethernet модули широко распространены в хакерском бизнесе по удаленному шарингу различных смарткарт.
Суть очень схематично такова: вы имеете знакомого с SIM картой в Австралии и хотитет позвонить используя эту карту из Москвы.
Знакомый берет и подключает эту карту к инету. Вы из инета подключаете карту к мобиле и звоните. Естественно такой расшаренной картой может пользоваться еще пол интернета.
Виденное мной подобное решение на PIC18 показало полную жизнеспособность при работе в открытом интернете. При этом плотность трафика там требовалась больше чем в обсуждаемом варианте с пингами.

Риски дешевых решений проявляются только когда клиент удаленный и для наблюдения нужна система , вот тут можно поприкалываться над PIC-ами.

Будет он работать пока не рассосутся все електроны в полупроводниках, по поводу всяких штормов проводил специальный тест, 2 платы STR912FA включены в общую сеть конторы. На одной плате крутится LwIP, 2 плата не используя никаких стеков, на МАКСИМАЛЬНОЙ СКОРОСТИ броадкастомом пуляет в сеть рандом данные, так вот компы начали умирать, плата с стеком LwIP начала терять пакеты пинг вырос сильно (MAC захлебнулся), после выключения 1 платы 2 плата сразу начала работать нормально, а вот компы некоторые пришлось перезагрузить.

Я вам скажу что мелкий конртроллер с мелким стеком будет работать надежней и стабильней любого WIN и LINUX и других операционок, а если есть какието проблемы у мелкго контроллера так надо копать в программе че там на програмлено.

Ну и фиг с ним. Девайс его ребутнет да и все, это если из-за заливания потоком не будет проходить ICMP-пакеты. Если роутер поднимется после ребута в нормальном режиме - то все отлично. Не поднимется - никакая пинговалка, хоть на PPC G4, его не поднимет, надо идти разбираться ручками.

Вообще желательно конфигурировать сеть так, чтобы устройства управления сидели в отдельном VLAN'е. Тогда мультикастовые потоки в общедоступной части сети будут мало волновать.



Не нужно фильтровать девайсом. Надо правильно сконфигурить свич, если уж разговор зашел о VLAN'ах.

И вообще, я не претендую на то, что мое устройство будет управляемо при любом количестве флуда в сети. Просто когда количество флуда приведет к тому, что перестанут проходить ICMP-пакеты, оно примется сбрасывать оборудование.

Был у нас один прецедент.
Деталей не помню, но смысл в том, что многочисленные неконтролируемые сбросы роутеров приводили к сносу у них настроек.
Сбросы или не сбросы были в этом виноваты, но виноватым назначили того кто сбрасывал.
В дешевых роутерах особо не заботятся о целостности файловой системы ибо полагаются, что юзер где-то рядом и всегда все перенастроит согласно инструкции.
Судя по клиенту здесь как раз случай с дешевыми роутерами.
А сброс предпологается делать снятием питания.
Логично ожидать что и блоки питания будут дешевыми с экономией на обмотке и железе, и из-за того огромными скачками напряжения при коммутации. Заземление у них там тож вероятно в дефиците будет.
Дивайсы фазу напряжения как понял не ищут для подходящего времени отключения.

Вообщем роутеры обычно любят вести лог. Это означает что файловая система у них все время активна.
Отключение питания приводит к появлению сначала мощного импульса перенапряжения на вводе питания в роутер и оно уходит через плату и оплетку подключенных кабелей STP в землю и спустя милисекунды только напряжение питания начинает падать.
За это время NAND Flash на роутере из-за наводки успевает несколько раз ошибиться в адресации и вписать данные не туда куда надо.
Поскольку блоки в файловых системах пишуться не меньше чем по 512 байт то целостность файловой системы будет однозначно нарушена либо сразу
либо позже когда будет запись в грязный кластер считающийся чистым.
С большой вероятностью роутер вообще перестает отвечать на пинги.
Дивайс в свою очередь до отупения будет продолжать его сбрасывать, пока у роутера от ESD вообще не пробъет PHY драйвер.
Пробитый драйвер начинает неимоверно греться и вслед за ним начинает перегреваться блок питания, у дешевого трансформатора от перегрева начинают замыкать витки в обмотке от чего он еще сильнее перегревается и загорается.
Хорошо если сработает защита от KЗ в электрошкафу. Но сомневаюсь, что она будет стоять там где применяют Ethernet пробник за 20$
Итого все сгорает.

Вот такие вот риски..

Можете считать шуткой.

Ооо, какая страшилка на ночь. Детям хоть своим не рассказывайте

Я тут как Станиславский - НЕ ВЕРЮ!

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

Присоединяюсь!

Тем более, что никак не пойму логики автора:
Насколько мне известно, в имульсных блоках питания при отключении внешнего источника питания, т.е. до диодного моста, импульсный преобразователь начинает "высасывать" энергию, запасенную в электролитическом конденсаторе входного фильтра. При этом ШИМ-контроллер, регулируя скважность импульсов, будет еще некоторое время стабилизировать напряжение на выходе БП (те самые милисекунды) после чего, напряжение действительно начнет падать.. Но откуда "БРОСОК" напряжения на выходе БП???