Привет, коллеги!
Недавно поднял на STM32Fxx FTP сервер и удаленно через Internet пишу файлы во внешнюю flash память. Все неплохо работает, есть вопрос с подходом к верификации данных в принятых файлах. Я использую ftp passive mode, и по сути, аппаратно верифицируются только пакеты пришедшие с Ethernet, можно конечно и проверить пакет после записи на SD. Но этого не достаточно для полного убеждения о целостности файла. Я тут вижу два пути, сначала записать удаленно файл, и скачать обратно, сравнить их Hash (долго, если файл большой). Второй, научить STM-ку считать Hаsh уже записанных файлов по команде (возможно не стандартной) FTP и создавать *.txt файл с Hаsh суммами файлов в текущей директории. После чего можно скачать этот файл и проверить. Но наверняка, есть более красивый и правильный подход, которого я не знаю, так что буду рад подсказке, спасибо!

CRC32 вполне достаточно в этом случае.

Ну да, если файл передаётся через интернет, то контрольная сумма TCP слабовата. Если файл требует защиты, то пусть закачивают пару файлов: данные и контрольную сумму.

У меня со стороны FTP клиента сидит человек (пока), возможно будет «сидеть» и машина, а со стороны FTP сервера «железка» STM32, она и использует файлы, без человека. Вот смысла закачки файла с контрольной суммой пока недопонимаю, если честно... наверное, это будет уместно, если человек со стороны сервера вытащит флешку и сверит. А так, идею понял, спасибо.


Ну уж очень лаконично. Да, в моем случае в контроллер входит аппаратный модуль CRC32, им часто пользуюсь, очень шустрый.

Подключите SSL. Этого будет достаточно.

ну я так понимаю реализация может быть такая

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

Но меня интересует вот что, ТСР уже снабжено неплохой контрольной суммой, причем не на весь файл а на каждый пакет. Неужели ее катастрофически не хватает?

А почему нельзя хитрую контрольную сумму поместить в первый файл?

Вы считаете x0+x1+...+xN (ну плюс ещё переносы из старших разрядов) неплохим контролем?
Хм.... и зачем тогда люди CRC считают, мучаются?... непонятно....


Непонятно, что автор контролировать хочет.
Если - достоверность полученного файла на сервере, то очевидное решение - просто пристыковать CRC32 к концу файла (+4 байта к длине), а на приёмном конце проверить.
Если - контроль со стороны отправителя, что получатель получил корректный файл - инфу и принятом файле (имя+длина+CRC32) отправить обратно к клиенту. Любым удобным способом (хоть рядом файл создать, хоть через другой сокет и т.п.).

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



да, потому что XOR по 8 битам считаю плохим, а этот считаю не плохим... не супер, но не плохим...


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

Ну да, реализовать на удалённой системе поддержку распаковки ZIP-формата. А потом ещё и дорабатывать это каждый раз, как в ZIP-формат вводятся какие-то нововведения (новые методы сжатия и т.п.).

я может ошибаюсь, но вроде бы для распаковки предоставлялась библиотека. Давным давно так было сделано обновление прошивки в каком-то продукте. Он заливался по RS232 и zip здорово помогал в ускорении процесса, а так же проверял целостность. Так вот как паковать - это супер мего тайна фирмы производящей архиватор, это их конкурентное преимущество, а как распаковывать было открыто и то ли исходники кода давали, то ли библиотеку, я не очень помню, но помню что проблем с распаковкой вообще не было.

Время течёт, всё меняется. И вот уже в формат ZIP добавили например AES. И если запаковать с ним, то никакая старая либа такое не распакует.
Конечно это опционально и при паковке это можно не включать. Но всё-же всё-же.... Зачем себе усложнять жизнь?

Коллеги, большое спасибо за идеи и рассуждения. Думаю это полезно не только для меня. Не стал сильно сразу расписывать задачу, чтоб не засорять. Со стороны клиента файлы пока передает человек, это не картинки и не музыка, а созданный пакет файлов, например бинарники и другие форматы подготовленные для обработки удаленной «железкой», поэтому есть свобода, и действительно идея прописать внутрь файла hash мне нравится. После загрузки файла можно сразу ее пересчитать или даже на ходу по блокам после записи и чтения с SD. Тогда можно будет светси к минимуму напряжения оператора, что будет их «заливать» удаленно. И по приему 226 transfer complete можно будет судить, что файл записан и верифицирован.
В примере *.dvc3 это формат шифрованной прошивки для обновления firmware в нашей компании.



Простой проверке CRC32 пакетов, что приходят по TCP я не верю, у меня был случай, когда я скачивал дистрибутив Mplab с сайта Микрочип, после скачки установка «падала», когда я скачал этот же дистрибутив с другого места, все стало ОК. Я сравнил эти два одинаковых файла по 105 MB утилитой «file compare» и нашел 9 байт в разных местах, которые отличались, распечатал и «сунул в нос» провайдеру, через неделю извинились и что то поменяли, стало нормально.

Где-ж Вы в TCP нашли CRC32???
Почитайте его описание.

Про TCP я читал очень давно, как там дополнительно контролируется содержимое внутри уже проверенного внешним CRC32 пакета, но CRC32 вполне себе очень доверятельная вещь !
По инету всё им проверяется на вшивость, мужики очень умные придумывали. И просто, и надёжно.
Там на каждый единичный бит в исходном файле к 4-байтному результату XOR-ится уникальное 32-битное число, и если бит/байт или их группа рядом где-то испортится, как обычно бывает в импульсных глюках, то проксорится уже другая цепочка, и вероятность получить тот же код невероятно мала. Для получения той же CRC32 для других данных нужен очень мощный перебор.
Происходит вычурная однозначная трансляция из всего множества файлов разных длин в множество 32-битных чисел, которая, естественно, может несколько файлов отобразить в одно и то же число, но на практике это не бывает, особенно если несколько байт изменено, а остальные прежние.
Вообще, я считаю, что нужно сначала ошибку увидеть, а потом её начинать бояться, солому стелить как-то... Флэшь тоже может сбоить -- вот там нужны CRC32 в каталоге для каждого файла или даже у каждого сектора, как раньше было у HDD.
А у провайдера кэш глючил на прокси (ОЗУ/винт SSD), скорей всего -- они файл получили, куда-то сохранили, потом считали побитый, на пакеты порезали, новой CRC32 закрыли -- и передали, типа "усё хоккей".