Добрый день.
Нужно разработать устройство, управление которым должно осуществляться через ethernet и wi-fi.
Какая минимальная/типичная/комфортная программно-аппаратная конфигурация должна быть у встраивамого устройства, чтобы запустить на нем более-менее полноценный web-сервер и web-службу?

Простейшие WEB-серверы даже на PIC делают.
http://www.megachip.ru/news.php?id=84
А для управления по сети может и UDP хватить ...

Мне нужен не простейший, а достаточно полноценный.

w7200 [Wiznet]?
Тут те и арм, тут те и аппаратный tcp/ip

А что в Вашем понимании полноценный? Иногда "полноценный" Web-сервер может быть весьма суровым и выдвигать неслабые требования к хостингу.

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


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

Может роутер + микроконтроллер: http://www.xakep.ru/magazine/xa/128/110/1.asp

Ну кто теперь публичный сервер делает на встраиваемом дивайсе?
Если нужны красивые интерактивные графики на основе данных то Google Fusion Tables.
Если нужно on-line управление удаленным устройством, то берут хостинг с Node.JS как посредника, но ни в коем случае не открывают прямой доступ из интернета к портам устройства.

Самому устройству при этом сервер не нужен, нужен только TCP стек с HTTP и SSL.

Вы хотите прямо этот сайт запустить на своей втроенной железке и выставить голой ж... в Интернет? Набега хакеров не боитесь? Или что ваш девайс начнет показывать поронографические мультики вместо графиков?
Послушайтесь AlexandrY - он дело говорит

При использовании ОС это делается элементарно не выходя из buildroot на imx233 например у меня работала небольшая CMS на php+sqlite (например эта http://www.wolfcms.org/), в качестве сервиса http использовал встроенный в busybox http-сервер.
http://box.matto.nl/busyboxphp.html

ethernet и wi-fi аналогично с пол-пинка прикручиваются. На все это нужно потратить минут 15.

Я не хочу запустить этот сайт на железке. Это вообще не мой сайт. Я его привел в качестве хоть какого-нибудь примера.


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


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


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

ИМХО набега хакеров надо боятся если сервер основан на открытых/широкоизвестных вещах, в которых можно поковыряться и поискать уязвимости. А если все самописное и железо физически недоступно (только через сетевые сервисы), то хакеры не так уж нестрашны. Ну за ДДОС-ят, в худшем случае - это не совсем вопрос к серверу/железке. Интересно было бы сделать, например, дефейсинг на сервере, у которого ресурсы все в программной памяти микроконтроллера (ну типа LPC17). Теоретически понятно - нужно как-то удаленно грузануть свой код в RAM и получить управление. Но практически - без наличной прошивки и много-много времени на ее вдумчивое изучение на предмет "дырок" - малореально.

чтоб поднять Ethernet - много телодвижений не надо. С ВайФаем сложнее. Если Вам принципиально и то и то, то тогда надо искать готовые девайсы(типа роутеров под льюникс) или готовые платки которые берут на себя данный функционал (типа визнета и иже).
Чисто изернет - определяетесь какая поддерживаемая скорость нужна, цена вопроса, сколько ресурсов на самой железке. Исходя из этого есть варианты
1) чисто всё самому реализовывать. в инете есть вплоть до физического уровня всё на МК. правда скорость - сами понимаете не серъёзно.
2) взять готовые микросхемки(типа CS8900A - это правда десятка, чисто как пример) сети(как правило управление ими - параллельное), внимание уделить при разводке дорожек, согласующему трансику на выходе. с точки зрения софта - микросхемка предоставляет только физический уровень и фильтрацию(поддержку) на мак уровне(типа бродкасты и явную адресацию). стэк подымать самому. Минималка для вэба - ARP, IP, ICMP, TCP, WEB начинку(HTTP + некий свой встроенный язык - аля пыхпых). для расширения UDP на любителя - занимает копейки телодвижений, а заюзать можно не плохо для своих нужд. Обращаю внимание, что если встраиваемый сервак должен принимать страницы более 1500 байт(такое может быть - в зависимости от функционала вэба), то обязательно нужно поддерживать сборку на IP уровне!(не путать с TCP). Если её поддерживать - то как правило требования к ОЗУ возрастает(время жизни фрагмента, интенсивность и размер ОЗУ - связаные вещи).
3) взять готовые платки (микросхемка, сетевой трансик, кварц). как и во втором варианте возможно придётся(зависит от милкосхемки) реализовывать стэк самому(см. пункт 2). Но есть и готовые решения - например WizNet. Управление как правило идёт через SPI или COM или типа того. Стэк как правило в этом случае поддерживается милкосхемкой. Вэб решение бывает внутри, а бывает и нет.
4) взять готовые девайс типа роутера. софтверная начинка - льюникс и иже. выхода можно намудрить. Но это не пром. вариант кмк.





глупость несёте...
поясните как хакеры будут ломать флэш МК через Ethernet?

Понимаю, что сайт для примера. Но ход мыслей понятен, графики и все такое.
Графики можно строить в самом браузере используя например движок jQuery и передавать только массивы данных.
Но если браузеры могут быть с выключенным JavaScript, то графики придется строить силами самого дивайса.
Это уже круто, но по прежнему осуществимо на каком нибудь STM32F103 силами GUI.

Google Fusion Tables неплохой вариант даже для интрасетей, поскольку там данные действительно хранятся надежно, централизовано и бесплатно.
В дивайсах вы не можете положиться 100% на надежность встроенных носителей. (Особенно на дешевых KIT-ах ).

Если делать WEB сервер на самом дивайсе, то наличие скриптовых движков типа PHP совсем необязательно.
Сервера для микроконтроллеров поддерживают технологию серверных включений SSI и CGI которые пишутся на знакомом C-и, и значительно гибче и быстрее PHP, при этом могут напрямую обращаться к любой периферии на плате (а не только к UART-у )

Поднимал сервак на LPC2129+CS8900A+uIP. В принципе доволен, но макс. кол-во подключений TCP слишком мало. Всего 20 сокетов.
Сейчас делаю новую хрень, но там мне нужен чисто UDP: LPC1768+PHY+не_знаю_пока_какой_стек. А для WiFi использую ConnectOne'овский модуль. В принципе он вроде позволяет поднять вполне себе полноценный web, но что тогда делать с web'ом по ethernet - вот вопрос.

Не хакеры ломать будут, а боты и вообще все соседи.
Будут во первых непрерывно сканировать порты.
Будет идти непрерывный широковещательный трафик от роутеров и прочей инфраструктуры.
Потом будут непрерывно долбить по HTTP, Telnet, FTP и т.д.
Серверу все время надо будет парсить идиотские запросы по HTTP.
В конце концов сервер упадет либо из-за нехватки памяти либо из-за ошибки в парсере.
Либо сам встроенный сервер занесут в черный список за неадекватные ответы.
Обрезание трафика по email уже обычное дело.
С провайдерами приходится ругаться чтобы дивайсы могли отправлять емайлы беспрепятственно.
Ну а Flash (вернее файловые носители на Flash) рухнет от износа.

что то новенькое.. а откуда такое ограничение то???
(дописал)я не обратил внимание на uIP изначально - именно реализация протокола накладывает ограничение. само железное решение не причём...
на 51+CS8900A подымал вэб сервак - ограничений не наблюдал. доводил до 100 далее не интересно...




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

по поводу что и каких ресурсов не хватит - если делаете стэк с учётом именно такой нагрузки - проблем НЕ будет. Вам никто не мешает сделать анализ на ликвидность приходящих пакетов, в том числе и по временному признаку. В чём проблема то???




ссылочка на дэкумент у вас конечно же имеется??? ограничения по чтению - что то новенькое... и сразу в догонку, я правильно понимаю вашу мысль, что при выполнении программы флэш не читается, или читается так-же(и со временем МК умирают)? ))

На нормальных осях есть нетфильтры - вся эта левая шелуха отметается, настройка их ~ +5 минут к времени работы над проектом итог - минут 20 работы.

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

Думаете обладаете телепатическими способностями?
Нет, майлы не проходили потому что между ними был слишком короткий интервал.
Эвристика провайдера однако..




А здесь другая эвристика.
На примитивных МК ничего не записывающих во время или на старте сессий, и не дампирующих крахи нормальный WEB сервер не сделать.



Да, лучше год потерять, но зато потом за 20 мин долететь

Вот мы думали, думали и решили остановиться на варианте использования встраиваемого одноплатного компа + наше устройство. С учетом отсутствия опыта работы с ethernet и протоколами, это будет наиболее быстро поднимаемый вариант.

Сервер то получается, но уж больно сложно поддается программированию. Там проблема хранения/обработки последовательных данных HTTP протокола. Если в PC памяти достаточно для формирования ответа сервера целиком, то на базе PIC контроллеров это дается очень не легко, приходится формировать ответ сервера только фрагментарно из-за ограничений в памяти и буферов малой длины.
В общем я несколько лет делал сервера для PC поддерживающие динамический контент. Называлось это - удаленный пользовательский интерфейс. Сейчас в основном используют PHP. Но когда попытался сделать мини подобие для PIC, был в шоке от ограниченности ресурсов. Возможно еще продолжу подобные исследования.

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

PS. Есть такой встроенный WEB сервер - GoAhead, видел его во многих роутерах и прочем сетевом хламе

И Flash тоже перепишут.
Посылается TCP пакет (или фрагмент более высокого протокола),
который вызывает переполнение стека, в следствии чего запускется
фрагмент кода из уже убитого стека.
Разработка такого мероприятия "с нуля" - достаточно муторное мероприятие.
Но в этой степи работают уже много лет и есть серьезные наработки.
По "стилистике" ответов определяют тип используемого стека.
Конкретные опции - экспериментально.

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

P.S. От дальнейших подробностей - воздержусь : )

один тупой вопрос:
У Вас лично есть хоть одна взломанная система, под заказчика?

Raspberry Pi. An ARM GNU/Linux box for $25. Take a byte! С эзернетом он стоит $35. Продается в Фарнелле.

Замечательная ссылка однако.
Сервер имеет CGI, SSL, аутентификацию и даже серверный JavaScript с поддержкой ASP файлов.
А главное портируется под любую RTOS. Надо изменить только пару вызовов сервисов RTOS. Хоть на FreeRTOS портируй.
256К RAM хватит за глаза такому серверу если не увлекаться CGI.

Не совсем в тему.. Может кто-нибудь подскажет более-менее приличный FTP сервер, чтобы на FreeRTOS положить без заморочек?

Мы делали сервер на LPC1768 c кайловской библиотекой. Для динамического отображения использовали json. Но у нас задачи наверное попроще - отобразить как работает прибор, поменять пару параметров, обновить софт. Число коннектов ограничили двумя. Вообще если хочется много коннектров нужна внешняя память. Для нашего сервера использовали совсем немного памяти примерно 100k flash + 10kram, потому что в основном память для приложении использована.

Если бы там была встроенная Flash, хотя бы несколько MB, то это было бы то, что надо. А так, там вся работа только с карты памяти ведется. Не думаю, что это надежное решение для промышленного устройства.


Не могу понять, а каких усилий будет стоить написание динамичного сайта для этого сервера. И кто должен прилагать эти усилия: я или можно привлечь обычного web-программиста. Т.е. можно ли применить стандартные на текущий момент решения для web разработки.

Вам придется по любому учить HTML как минимум, для красивой динамики надо будет еще узнать про технологию AJAX (AJAH скорее в вашем случае), научиться понимать JavaScript и понимать и использовать универсальные библиотеки на JavaScript типа jQuery.
Это на стороне браузера.
На стороне сервера вам придется изучить технологию CGI и научиться связывать CGI запросы с железом на языке C-и, ну и опять разобраться с функциями которые дает серверный JavaScript.

Причем все это надо делать независимо от того насколько крутую платформу вы выберете, промышленный PC или PIC контроллер.
GoAhead интересен тем, что его исходники очень компактные, открытые и легко интегрируемые.

Стандартных решения для WEB чтобы напрямую связывали WEB сервер с железом и прикладными приложениями я что-то не видел.
Поэтому сайтостроители с опытом PHP и СMS-ов не подойдут. Скорее нужны дизайнеры с опытом JavaScript для стороны браузера.
На стороне сервера увы embedded программисту придется все делать самому.

Разложили по полочкам мои прыгающие мысли.


Большой минус для меня. Мне кажется, развивать и поддерживать сайт должен web программист.

Когда говорят WEB программист, все обычно представляют себе сервер Apache c PHP и MySQL ну или MS IIS7 c ASP .NET
При этом программисты потирают руки и представляют себе как притянут за собой еще и подготовленную под себя CMS (Content Management System) .

Если дать такому программисту embedded WEB сервер он будет в ступоре.
Многие из них даже HTML толком не знают, так как в CMS весь дизайн уже готов.
Но от CMS во встроенном сервере никакого толка если он должен показывать динамические данные от железа и работать не с MySQL, а с файловыми структурами на Serial Flash.
В принципе можно напряч WEB дизайнера чтобы он сделал макет страниц, но конкретно состав аргументов CGI запросов, сценарии обработки ошибок, валидацию данных, выборку данных для отображений на графиках и т.д. может сделать только embedded программист.
И это относится к любому встроенному WEB серверу, какой бы не выбрали.

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

Похоже, Вы не совсем понимаете как это работает. Для такой атаки надо детально знать код.
Просто так stack overflow вызвать НЕВОЗМОЖНО.




То о чем Вы говорите не имеет никакого отношения к ембеддед вебсерверу.
Все тоже самое будет происходить и с обычным PC.
Файрволл не уменьшает количество обращений и не предотвращает ДОС атаки.
Единственно, что это немного разгружает процессор, но имплементация такого файрволла
на микроконтроллере займет пару строчек.

А в чем проблема-то? Надежность разъема с золочеными контактами не устраивает? В мобильниках и фотиках работает надежно, а уж как только их не бросают. В любом случае это намного надежнее, чем обычный винчестер. Но уж если непременно хотите встроенную флэшку, то прикрутите сами снаружи. Разъем расширения с SPI+I2C там есть.

Или вот еще вариант: http://netduino.com/ Правда, послабее и подороже. Но зато железо открыто, можете переделать по-своему.

Обычный PC обычен только для дилетанта, а разработчика со стороны даже близко не подпустят к технологии его сетевых чипов.
Подите найдите описание контроллера Etherneta на тот же Raspberry Pi.
Это черные ящики. Если он начнет падать, то есть полная гарантия что вы никогда не узнаете почему.

Файрволл полностью может закрыть трафик к внутреннему серверу защитив его от перегрузок.
Софтварная импмлементация простейшего файрвола довольно сложна (сложнее простейшего WEB сервера) и ресурсоемка.
Но мы наверно о разном

На PC файрволл и сетевой чип - это параллельные прямые.
Вся коммуникация идет через драйвер и кернел API.
Во вторых, закрытость чипа определяется политикой компании производителя, а не наличием/присутствием его в PC.
Broadcom знаменит своим "не пущать!", так что Ваш пример ничего не доказывает.
В сурсах Линукса море драйверов для разных нетворк чипов.
Зачем они правда нужны для имплементации файрволла на PC, я не понял.

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

Кстати, простейший файрволл тупо сравнивает IP источника и не пропускает пакеты с запрещеным IP, где Вы видели проще HTTP server?

Эт что, в надежде что линукс большой и такие голословные утверждения никто не проверит?
Нут так в директории линукса с linux.org относительно сетевых физических контроллеров только 19 файлов!
Причем такого размера, что на драйвера не тянут. Это вообще ноль!
Конкретно файлов касающихся сетевых чипов там можно на пальцах пересчитать и видно, что функциональность их обрезана.

Embedded web cервер не файрволами надо обкладывать, а вообще нельзя в публичный интернет выставлять.
Да и функцию файрвола вы в моем контексте исказили.

а как посчитали количество? у меня в /usr/src/linux/drivers/net побольше всего, подскажите, pls где туплю

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

Интересно!
Можно пару вопросов?
1. Какое у Вас подключение к провайдеру? (DSL, ETHERNET, WiMax,...)
2. IP-адрес выделенный?

Спасибо!

... да. Это вариант. Надо подумать.

Главное в такой системе - чисто механическая блокировка, не допускающая заполнения ванны выше определенного уровня. Она есть ?

а это не оверкилл? может достаточно верхнего слива в сифоне?

/usr/src/linux/drivers/net/phy

а то в /net там записаны IrDA, CAN, WiMax и т.д.



Хостинг выбирают с Node.js. Тогда можно делать управление в риалтайме.

Но в моих дивайсах делается по другому.
По VPN дивайсы через NAT сервер провайдера (так стандартно бывает при GPRS соединении) по VPN организуют постоянный канал к домашней сети (можно просто роутер с поддержкой VPN) и там объявляются на фиксированных частных IP адресах.
Когда надо поуправлять дивайсом из публичного интернета, заходим опять же по VPN в свою домашнюю (частную, корпоративную) сеть и получаем доступ к WEB серверу дивайса по известному частному адресу.
В данном случае дивайсы защищены NAT сервером провайдера. Домашняя сеть защищена домашним роутером. Обмен же происходит в риалтайме.

так вы ж про mac а не про phy разговор вели, чем там рулить-то в фае? драйверы на чипы контроллеров на уровень выше в каталогах и отдельных файлах
или я опять чего-то не понимаю?

упд
мне вообще не понятно, кому эти драйверы фаев нужны? как-то попросили, мол, настрой программно; мужику лень стало смотреть в даташит и подтяжки подбирать для аппаратной конфигурации - притянул всё в одно место

а какие там маки неполные? энтузиасты писали или производитель не заморачивается?

да и опять же есть мак+езернет фай в одном чипе и одном драйвере, или я опять не понял?

Я MAC нигде не упоминал, меня вообще интересовало найти по работе с L3 что-нибудь посовременней.
Среди кучи мусора в директории NET PHY будет самым осмысленным местом где это могло бы лежать.
Есть там, конечно, и отдельные директории для оригинальных чипов, но это слезы.
Никаких оснований говорить, что в линуксе чего-то "море" нет.

Обычный четырех-жильный провод витая пара заходит в квартиру и на роутер, после роутера витая пара расходится по всей квартире, плюс Вафай.
Раньше, на протяжении 8 лет по DSL, IP был постоянным, но я недавно отказался от стационарного телефона и от DSL соответсвенно, сейчас без модема Ethernet заходит в квартиру и IP каждое подключение новый.


Обычный классический перелив в ванной.

Спасибо!
Я имел ввиду не статический/динамический IP-адрес, а "выделенный" (бывают белыми и черными). Т.е. он пингуется из глобальной сети?

А вообще решение интересное! Мне понравилось!

Это потому что производители пишут хреновенькие драйверы и этот мусор просто не принимают в майнстримовое ядро, а так - generic phy интерфейса с головой хватает в подавляющем большинстве случаев.