[Methane 0]

А что вы вообще делаете. Роутеры? Где посмотреть?

Я много чего делаю.

 

ssh в дистрибутиве WinCE не нашел, где вы его там видели.

Погугли-те, что-ли.

 

И что значит ssh наружу, нужно чтоб броузер в дивайс в сети за NAT-ом по HTTP залезал. Залезет?

Думаю без шансов.

Только если руки из задницы, и человек никогда NAT не настраивал, и вообще не знает что это такое и как работает.

[AlexandrY 3]

Вы бы курнули чтоли архитектуру SSH http://tools.ietf.org/html/rfc4251. Использование носков - это всего лишь способ динамического указания порта на другой стороне. Возможно и простой туннель, входящий порт на одной машине - исходящий порт на другой машине.

 

Если чесно, то не актуально, тут ради одного порта разгребать спецификацию SSH.

 

Под Win2003 есть пару тысч портов по PPTP, L2TP и PPoE c IPSec-ом в придачу.

 

Былоб интересно услышать как запихнуть это ssh в собственный дивайс на Cortex-е.

 

Я много чего делаю.

Удивительная скромность

 

Только если руки из задницы, и человек никогда NAT не настраивал, и вообще не знает что это такое и как работает.

NAT тут не причем. Мы говорим о ситуации когда дивайс стоит за чужим NAT-ом, к примеру NAT-ом провайдера интернета.

[Methane 0]

Если чесно, то не актуально, тут ради одного порта разгребать спецификацию SSH.

 

Под Win2003 есть пару тысч портов по PPTP, L2TP и PPoE c IPSec-ом в придачу.

 

Былоб интересно услышать как запихнуть это ssh в собственный дивайс на Cortex-е.

На сайте атмела есть пример для avr32, под freertos.

 

NAT тут не причем. Мы говорим о ситуации когда дивайс стоит за чужим NAT-ом, к примеру NAT-ом провайдера интернета.

Огласите пожалуйста весь список. у меня видимо с телепатией, не очень.

[AlexandrY 3]

На сайте атмела есть пример для avr32, под freertos.

Огласите пожалуйста весь список. у меня видимо с телепатией, не очень.

 

Ну наконец вы вернулись к FreeRTOS.

 

Я в начале приводил такую схему когда есть сеть дивайсов из них один роутер с NAT-ом поскольку все делят один внешний IP.

И есть еще NAT провайдера через который надо делать тоннель к NAT-у дивайса-роутера.

У FreeRTOS насколько помню есть только моноинтерфейсные IP стеки поэтому MQX и имеет преимущество.

[Methane 0]

Ну наконец вы вернулись к FreeRTOS.

 

Я в начале приводил такую схему когда есть сеть дивайсов из них один роутер с NAT-ом поскольку все делят один внешний IP.

И есть еще NAT провайдера через который надо делать тоннель к NAT-у дивайса-роутера.

У FreeRTOS насколько помню есть только моноинтерфейсные IP стеки поэтому MQX и имеет преимущество.

Слово моноинтерфейсное, очень сложное. А FreeRTOS уж вообще ничего про tcp/ip не знает (вы уж извините за то что я вас немного просвятил). Так что я тут Ваши мысли не сумел прочитать.

[AlexandrY 3]

Да ничего, я ж понимаю.

Вы просто хотите что-то узнать.

 

Во FreeRTOS применяют одну из двух адаптированных под эту ось вариаций стека Дункеля.

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

 

 

Слово моноинтерфейсное, очень сложное. А FreeRTOS уж вообще ничего про tcp/ip не знает (вы уж извините за то что я вас немного просвятил). Так что я тут Ваши мысли не сумел прочитать.

[Methane 0]

Да ничего, я ж понимаю.

Вы просто хотите что-то узнать.

 

Во FreeRTOS применяют одну из двух адаптированных под эту ось вариаций стека Дункеля.

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

Эти оси вообще, для слабоватых процессоров применяют. Если вы и это тоже не заметили.

Если что-то более серьезное, (вплоть до топовых суперкомпьютеров) есть Linux.

[AlexandrY 3]

Эти оси вообще, для слабоватых процессоров применяют. Если вы и это тоже не заметили.

Если что-то более серьезное, (вплоть до топовых суперкомпьютеров) есть Linux.

 

Прям обидели фанатов VxWorks-а (космос), QNX-а (атомная энергетика) ... Щас прибегут, затопчут же...

На самом деле есть вполне четкие градации цены-функциональности в осях.

Разбираться просто детально нужно.

[1891ВМ12Я 0]

Так вот прикиньте, кто-то мается, ставит UNIX по вашему совету.

Покупает для этого какие-то навороченные сомнительные платы с RAM-ом не меньше 16 Мб утешая себя мыслью что это все скоро подешевеет.

Сам то такую плату не сделает какую хочет - умрет BSP переписывать.

Потом долго объясняет клиенту как это настраивается.

Потом еще делает пинговалки для этого монстра. Он же будет виснуть, если не по аппаратной причине, то по программной.

Вычистить то от багов такую махину просто нереально.

В конце концов придется посоветовать клиенту не ставить такой дивайс в ответственные места.

Ну и под конец плюнуть, зайти в эту конфу и начать прославлять Линукс.

Уважаемый, Вы не ошиблись сайтом? баш орг ру немного не тут... Память стоит копейки, а тем более SDRAM, ее стоимость просто тает на глазах, становится просто незначительной. BSP надо не переписывать, а корректировать под свое железо, ибо существуют образцовые платы, например AT91SAM9260-EK или EDB-9302 и т.д., остальные платы - клоны со своими доработками. Настраивается просто и элементарно - потому что все стандартно и привычно, а то, насколько удобно будет работать клиенту - зависит от разработчика. С UNIX железо взлетает просто мгновенно, а то что интегрировано в проц так и подавно, масса устройств работает сразу без танцев с бубном, все USB, все PCI, SD/MMC - запросто, SSH - запросто, то се пятое десятое - элементарно. Без глюков. А если появляются - есть возможность разобраться во всем этом. Вывод: типичный "неосилятор"... =(

[Methane 0]

Прям обидели фанатов VxWorks-а (космос),

Сравнительно простые (с точки зрения оси) задачи.

 

QNX-а (атомная энергетика) ...

Это так Канадцам хочется. На самом деле это ось канадских лесопилок. Причем я не знаю как оно сейчас, но уже когда оно называлось "нейтрино", оно было больше вполне нормальным UNIXом. С иксами, GCC итд.

 

Щас прибегут, затопчут же...

На самом деле есть вполне четкие градации цены-функциональности в осях.

Разбираться просто детально нужно.

Размазаны они все. Области Linux и QNX во много сильно перекрываются.

[VslavX 0]

У FreeRTOS насколько помню есть только моноинтерфейсные IP стеки поэтому MQX и имеет преимущество.

LwIP с самого начала поддерживал несколько интерфейсов и имеет зачатки маршрутизации.

Насчет "убийцы" - вопрос спорный - мне кажется что ниши у MQX и перечисленных в топике ОС несколько разные. Упомянутые ОСи - они хороши для "моноконтроллерных" :) устройств, добавляете внешний чип S(D)RAM - уже "не то" - и ноги "отъедены", и место на плате занято, иногда и микропотребление/спящий режим не обеспечивается.

Посмотрел MQX-овский стек - после обнаружения копирования некоторых отсылаемых пакетов в MAC-драйвере интерес несколько поугас. Так что - мое мнение - MQX всего лишь "один из", а отнюдь не "убийца" :). В качестве примера, исходники безусловно полезны.

[AlexandrY 3]

LwIP с самого начала поддерживал несколько интерфейсов и имеет зачатки маршрутизации.

Насчет "убийцы" - вопрос спорный - мне кажется что ниши у MQX и перечисленных в топике ОС несколько разные. Упомянутые ОСи - они хороши для "моноконтроллерных" :) устройств, добавляете внешний чип S(D)RAM - уже "не то" - и ноги "отъедены", и место на плате занято, иногда и микропотребление/спящий режим не обеспечивается.

Посмотрел MQX-овский стек - после обнаружения копирования некоторых отсылаемых пакетов в MAC-драйвере интерес несколько поугас. Так что - мое мнение - MQX всего лишь "один из", а отнюдь не "убийца" :). В качестве примера, исходники безусловно полезны.

 

Вы наверно увидели функцию типа memcpy процедуре ENET_send_MAC

Там написано что это нужно в частности в случае невыровненности данных в буфере.

Почему это может случится?

Тут как раз особенность сложных IP стеков.

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

Например в пакете Echo при использовании ping-а стек не выделяет новый буфер для ответа,

а просто переставляет адреса ну и там кое-что еще и отсылает обратно.

Все нормально когда маршрут то-же самый.

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

а этот интерфейс может оказаться PPP или вообще тоннелем c 3-х этажной структурой заголовков.

Тогда отраженный пакет и окажется невыровненным из-за кардинальной смены заголовков.

И тогда его надо перемещать по границе буфера где-то на уровне драйвера.

К тому же данные в связи с особненностью MAC контроллера Freescale могут быть размещены только по границе 4, а лучше 128 (еще быстрее пересылка будет).

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

Ответ пинга через другой интерфейс эт вообщем скорее ошибка роутинга.

Или закольцовывание маршрутов.

Тут нужен уже RIP протокол. И опять же, он есть в открытом MQX!

 

Вообще не думаю что вы найдете в стеке MQX какие-нить явные ляпы. Такие оси не с потолка стоят по 100 тыс.$ в полном комплекте.

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

 

Я всегда привожу интересный факт, что вот есть роутеры Linksys WRT54G с популярной книжкой как хакать ихний линукс.

Но когда понадобилось сделать еще более дешевые и надежные роутеры с шифрацией WPA/2-PSK linksys выбрал операционку VxWorks!

 

В той же книжке дается обзор той самой кучи линуксового софта которую можно поставить на WRT54G.

Что мы там видим в первую очередь:

Жесткий список совместимых с софтом моделей. Цифрой меньше или цифрой больше -и можете стреляться, никакой портабельности нет. Софт не полетит и вы ничем ему не поможете.

 

Из загрузочных каналов только TFTP и HTTP.

 

Куча каких-то недоделаных пингеров, дамперов, тестеров, килеров, администраторов, WEb апликаций. Куски PPP и PPTP в виде демонов, ясное дело без всякого понятно описанного прикладного API. Тот самый SSH с которым непонятно че делать в интенете.

Как только встречаем какой-то пакет Talisman VPN c IPSec, то оба! он сразу платный, стоп халяве.

И все список кончается. Где тут че-нить для embedded?

 

Словом кто-бы че не кричал про богатства, универсальность и портабельность линукса в embedded области - это пустой треп.

[Methane 0]

Словом кто-бы че не кричал про богатства, универсальность и портабельность линукса в embedded области - это пустой треп.

Та линух вообще полное г-но. Я вашу мысль понял. И как ни нем куча серваков бегает. Ума не приложу. Загадка природы. :)

 

Как-то странно получается. Линух, на котором пол инета бегает, с линухом не совместим. :)

[VslavX 0]

Вы наверно увидели функцию типа memcpy процедуре ENET_send_MAC

...

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

...

При правильной идеологии интерфейс не должен бы получать для отправки некондиционированные пакеты. В моей реализации стека на такое стоит вообще assert (была серьезная борьба за сквозной zero-copy). В приведенном примере это уже проблема процедуры маршрутизации переложить пакет "правильно" для исходящего интерфейса. Ведь в общем случае интерфейсы могут отличаться не только аттрибутами но и вообще пулами памяти, поэтому, в самом общем случае, при маршрутизации между разнотипными интерфейсами без копирования не обойтись, имхо. И делать это надо "сверху", а не "снизу", на уровне драйвера. Раз драйвер занимается копированием - значит где-то выше уже дали слабину и упростили себе жизнь. Такое допустимо, но восхищения уже не вызывает :).

 

Я всегда привожу интересный факт, что вот есть роутеры Linksys WRT54G с популярной книжкой как хакать ихний линукс.

Но когда понадобилось сделать еще более дешевые и надежные роутеры с шифрацией WPA/2-PSK linksys выбрал операционку VxWorks!

Я даже когда-то купил такой - года 4 назад. Помнится, основной причиной перехода на VxWorks производитель назвал меньшие требования к памяти - стали шустро паять 2МБ SDRAM вместо 8MБ. Я как раз купил версию 2МБ и мне был нужен VPN-клиент. Так вот, в линуксовой версии VPN-клиент был, а вот в VxW - нет :(, поэтому купленный WRT54G был возвращен в зад.

 

Впрочем, помнится, речь в топике не про "убийцу" Линукса, а про uCOS/FreeRTOS/ScmRTOS? А эти ОСи - для "монокристалльных" изделий и MQX тут пролезает только "боком" :). Сравнили бы уже с eCOS/RTEMS, что ли. VxWorks - тот коммерческий, будет некорректно.

[AlexandrY 3]

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

Я бы сказал при правильном компромиссе.

Вероятнее что пакет будет отражен в тот же тип интерфейса. Поэтому весь верхний уровень и не занимается вообще копированием.

Копирование удобнее делать низшему уровню. Ему там виднее как это лучше сделать. Может по DMA иль на ассемблере иль мапировать прямо буферы в дескрипторы MAC контроллера. Собственно отражение только и является источником нежелательных смещений.

 

Я правда не говорю про MQX. Но они все там примерно одинаково делают. Т.е. пакеты представляют собой цепочки связанных буферов. Каждый из которых идеально выровнен.

Freescale везде использует один и тотже MAC контроллер, поэтому могу точно сказать что дальше буфера мапируются в дескрипторы FEC

 

А zero-copy далеко не так однозначно дает прирост производительности. Если из Ethernet-а идет запись сразу в файл на блочное устройство типа SD карту то zero-copy может работать гораздо медленее чем в варианте с промежуточным копированием в большой буфер.

 

Так вот, в линуксовой версии VPN-клиент был, а вот в VxW - нет :(, поэтому купленный WRT54G был возвращен в зад.

 

Впрочем, помнится, речь в топике не про "убийцу" Линукса, а про uCOS/FreeRTOS/ScmRTOS? А эти ОСи - для "монокристалльных" изделий и MQX тут пролезает только "боком" :). Сравнили бы уже с eCOS/RTEMS, что ли. VxWorks - тот коммерческий, будет некорректно.

 

Я тож имею линуксовый WRT54G. Так в нем нет SSH. ;)

 

Поверьте VPN клиент потребляет максимум 100 Кб памяти для кода и еще меньше для данных.

Про MQX яж начал с того что он быстрее и меньше по объему всех заявленных. Так как это "боком"?

Потому что не портирован? Так специалиста это должно радовать, меньше конкурентов будет.