нужна ли отдельная библиотека для работы с udp/ip пакетами на микроконтроллерах?

А в ней char может быть не только 8 бит, но и, например, 16?

ARP, DHCP?

ARP есть, DHCP пока нет

А в ней char может быть не только 8 бит, но и, например, 16?

Я использую uint*_t . или ты про что?

Я о том, что если буферы объявлены как char массив, то, обычно, к ним обращаются, как будто каждый элемент размером в 8 бит, но на TI C55x DSP - там 16, и всё ломается.

А через интернет будет работать?

у меня буферы uint8_t

пока что таблицу маршрутизации тоже не делал

Но вообще надобность в выходе в интернет на подобных устройствах сильно сомнительна

Ясно, значит, не скомпилируется: там нет int8_t/uint8_t.

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

TCP у меня нет и не планируется)

Может быть сделаю RUDP / RFC908 / RFC1151

а какие там несовместимости были?

По идее, сеть должна пропускать IP пакеты, а поддержка IP это просто

а ICMP куда девать, его поддержка как бе обязательна

на пинг отвечает

Логика работы сети вот тут: https://github.com/nort-cnc-control/cnccontrol_rt/blob/master/libs/libip/net.c

ssh бы на микроконтроллере… Чтобы с компьютера простейшими скриптами железом управлять (и без риска, что какое-нибудь любознательное чудо взломает).

на stm32f103 / stm32f302? С 20 кб и 32 кб ОЗУ?

Да оно банально не влезет туда.

Сети с такими устройствами надо защищать по периметру

печаль.

Учитывая цены на стм-ки, луче немного докинуть и купить с нормальным объемом памяти чем считать байты. Ну а код выкладывай конечно.

Что не влезет? Я, честно говоря, никогда не вникал в алгоритмы SSH. Но сдается мне, что для конкретного случая с фиксированными ключами все должно в пару десятков килобайт флеша уместиться и жрать от силы пару килобайт оперативки!

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

Но без SSL сеть на МК вообще никакой ценности не имеет, т.к. ломается на раз-два!

Я надеюсь, что «кризис» долго не продлится и через пару лет можно будет опять STM32F072CBT6 или F103CBT6 купить за 90 центов.

А сейчас — да, дешевле взять orange pi zero, а для рилтайма и АЦП приладить к ней какое-нибудь копеечное китайское восьмибитное барахло.

Но без SSL сеть на МК вообще никакой ценности не имеет, т.к. ломается на раз-два!

Сеть на МК защищается по периметру.

Предлагаешь на компе делать шлюз для сетевых устройств на МК? Тогда зачем вообще париться с сетью на МК, если их можно по USB/CAN/RS-485 к тому же компу подключить?

все подобные устройства не должны смотреть в интернет, а быть доступны только из локалки

Блин, так в локалке их какая-нибудь любознательная зараза и поломает!

Знаешь, сколько у нас студентов бывает? А не так давно школьничек один во время АФШ все пытался какой-нибудь сервак взломать. Взломать не смог, но DOS-атаку устроил. Перехватить же логин-пароль, шляющиеся по сети в незакодированном виде, ему бы вообще труда не составило! И стали бы железки «с ума сходить»!..

Поэтому мы вообще сейчас не рассматриваем http, если нужно передавать какие-то команды. И никакой «базовой авторизации», понятное дело.

Огосики, что-то я давно цены на стм-ки не смотрел. Реально цена в 3 раза выросла, вот дела.

Ладно хоть есть небольшой запас с прошлого года ))

а выросли цены на все

Если локалка большая и в ней есть недоверенные люди - то подобные девайся должны быть в отдельном VLAN

А городить ssh + TLS + https + 100500 защит для общения компьютера с микроконтроллером управления железякой - смысла нет

Вот поэтому и ethernet нет смысла на МК городить, коль уж все равно он будет кабелем подключен к компьютеру!

Делаем на «апельсинке» шлюз в CAN, да подключаем свои микроконтроллеры.

char 16 бит? Дай догадаюсь, DSP?

Ага: нужна ли отдельная библиотека для работы с udp/ip пакетами на микроконтроллерах? (комментарий)

при желании я думаю можно будет допилить для систем, где нет uint8_t.

А городить ssh + TLS + https + 100500 защит

А нет ли кстати какого-то более простого протокола с криптографией, подходящего для микроконтроллеров?
Типа как wireguard, где всё прибито гвоздями, но аналог TLS.

Хотя я смотрю, и для TLS какие-то библиотеки для embedded есть. В чём тогда проблема?

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

Цена выхода МК в ethernet это цена ENC28J60, на порядок дешевле апельсинки, не считая монтажа проводов для кана.

И нуль безопасности! Это как «крокодиловские» сигналки, которые не шифруют канал…

Ну напримре у меня 32 кб ОЗУ, причем надо еще сеть и целевой алгоритм держать. Ну и криптография - это не то, чтобы быстро

Безопасность это в основном меры по ограничению физического доступа к оборудованию. С безопасностью все тупо, открыл шкаф - за спиной мент с автоматом.

ssh бы на микроконтроллере… Чтобы с компьютера простейшими скриптами железом управлять

А в качестве shell’а что будет?

В направлении микроконтроллеров ведутся исследования для достаточно быстрой софтовой криптографии. Например, эффективная реализация современного алгоритма Cur­ve25519 https://www.emsec.ruhr-uni-bochum.de/research/publications/mu25519/ даже для 8-битных МК. tinyssh может его использовать. Но «tiny» он не совсем:

no dynamic memory allocation - TinySSH has all memory statically allocated (less than 1MB)

А вот если без SSH, только TLS, то уже ближе к «tiny»:

If tiny is not enough, you can get even smaller! The footprint of our library can get as small as under 30 Kb RAM and ROM footprint for a working SSL server or SSL client.

https://tls.mbed.org/tiny-ssl-library

less than 1MB

хахаха

The footprint of our library can get as small as under 30 Kb RAM

Да у меня всего 32 кб памяти

А много где и того меньше

Обычный самописный парсер команд. Как если бы я просто открыл коннект в терминале.

Жуть какая! Максимум 4кБ оперативки и 20кБ флеша!

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

Автомобильную сигналку я бы на таком принципе и делал: имеем некий долговременный ключ длиной в 1024 байта. После незашифрованного рукопожатия сигналка отсылает брелку N случайных чисел и их позиции, оригинальный ключ XOR'ится с этими данными и дальнейшие посылки шифруются этой абракадаброй. А периодически, когда ключ в зажигании, сигналка может по блютусу или другому радиоканалу со значительно меньшей мощностью отправить новый ключ брелку.

В общем, нужно думать, как на пустом месте сварганить более-менее устойчивый к перехвату третьими лицами протокол XOR'ения. Скажем, перед XOR'ом еще и путать байты местами…

для сигналки нужно не шифрование, а подпись или хэш.

Жуть какая! Максимум 4кБ оперативки

Но для эффективной работы с сетью нужен буфер в 1,5 КБ.

В общем, нужно думать,…

Что люди в теме сломают почти так же быстро, как он и придуман был.

Самопальный метод XOR'ивания с перемешиванием байтов? Сомневаюсь, что кто-то такое сможет сломать (точнее — захочет), т.к. полным-полно сигналок вообще без шифрования! Просто бери приемник на 433МГц, подключай к диктофону, записывай, а потом нужный кусок воспроизводи на вход передатчика! Барсеточники на заправках примерно таким алгоритмом и пользовались: закрыл чувак машину и пошел внутрь, машина пинается, чувак выглядывает — никого, жмет «открыть», а потом «закрыть». Барсеточник за углом это пишет, а как только водитель отвернулся, воспроизводит. Его товарищ, который машину пинал, лезет в салон и тырит барсетки-сумки-что еще...

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

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

А сейчас — да, дешевле взять orange pi zero, а для рилтайма и АЦП приладить к ней какое-нибудь копеечное китайское восьмибитное барахло.

для реалтайиа микроконтроллер вообще не нужен - одного orange pi zero достаточно

https://github.com/siemens/jailhouse

Для криптографических примитивов в принципе должно хватать, можно хоть RSA-4096 запилить. Скорость да, может быть небольшая, но если много данных не передаётся, то пофиг