[Danis 0]

Привет, коллеги!

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

[jcxz 184]

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

[scifi 1]

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

[Danis 0]

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

 

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

 

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

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

[AlexandrY 3]

Но этого не достаточно для полного убеждения о целостности файла.

 

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

[Golikov 0]

Вот смысла закачки файла с контрольной суммой пока недопонимаю, если честно...

 

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

 

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

 

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

[Aleksandr Baranov 1]

вы шлете файл, и второй файл со значением хитро посчитанной контрольной суммы.

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

 

[jcxz 184]

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

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

Хм.... и зачем тогда люди CRC считают, мучаются?... непонятно....

 

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

Непонятно, что автор контролировать хочет.

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

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

[Golikov 0]

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

 

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

 

 

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

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

 

 

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

[jcxz 184]

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

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

[Golikov 0]

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

[jcxz 184]

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

Время течёт, всё меняется. И вот уже в формат ZIP добавили например AES. И если запаковать с ним, то никакая старая либа такое не распакует.

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

[Danis 0]

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

В примере *.dvc3 это формат шифрованной прошивки для обновления firmware в нашей компании.

 

Статус:    Соединяюсь с 176.226.243.83:201...
Статус:    Соединение установлено, ожидание приглашения...
Ответ:    220 Welcome to DaNiS FTP Server
Команда:    USER Murena
Ответ:    331 User name okay, need password
Команда:    PASS ******
Ответ:    230 Login successful.
Команда:    SYST
Ответ:    215 UNIX Type: L8 Internet Component Suite
Команда:    FEAT
Ответ:    500 Syntax error, command unrecognized
Статус:    Соединение установлено
Статус:    Получение списка каталогов...
Команда:    CWD /
Ответ:    250 CWD command successful
Команда:    PWD
Ответ:    257 "/" is current directory.
Команда:    TYPE I
Ответ:    200 Switching to Binary mode.
Команда:    PASV
Ответ:    227 Entering Passive Mode (176,226,243,83,0,200)
Команда:    LIST
Ответ:    150 Opening BINARY mode data connection for /bin/ls
Ответ:    226 transfer complete, data port is closed
Статус:    Список каталогов извлечен
Статус:    Начинаю закачивать E:\KTM4_v64_35_test_U3_ftp.dvc3
Команда:    CWD /DanFolder002
Ответ:    250 CWD command successful
Команда:    PWD
Ответ:    257 "/" is current directory.
Команда:    PASV
Ответ:    227 Entering Passive Mode (176,226,243,83,0,200)
Команда:    STOR KTM4_v64_35_test_U3_ftp.dvc3
Ответ:    150 File status okay; about to open data connection.
Ответ:    226 transfer complete, data port is closed
Статус:    Файл передан успешно, передан 263 462 байт в 3 секунды

 

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

[jcxz 184]

Простой проверке CRC32 пакетов, что приходят по TCP я не верю, у меня был случай, когда я скачивал дистрибутив Mplab с сайта Микрочип

Где-ж Вы в TCP нашли CRC32???

Почитайте его описание.

[WitFed 1]

Про TCP я читал очень давно, как там дополнительно контролируется содержимое внутри уже проверенного внешним CRC32 пакета, но CRC32 вполне себе очень доверятельная вещь !

По инету всё им проверяется на вшивость, мужики очень умные придумывали. И просто, и надёжно.

Там на каждый единичный бит в исходном файле к 4-байтному результату XOR-ится уникальное 32-битное число, и если бит/байт или их группа рядом где-то испортится, как обычно бывает в импульсных глюках, то проксорится уже другая цепочка, и вероятность получить тот же код невероятно мала. Для получения той же CRC32 для других данных нужен очень мощный перебор.

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

Вообще, я считаю, что нужно сначала ошибку увидеть, а потом её начинать бояться, солому стелить как-то... Флэшь тоже может сбоить -- вот там нужны CRC32 в каталоге для каждого файла или даже у каждого сектора, как раньше было у HDD.

А у провайдера кэш глючил на прокси (ОЗУ/винт SSD), скорей всего -- они файл получили, куда-то сохранили, потом считали побитый, на пакеты порезали, новой CRC32 закрыли -- и передали, типа "усё хоккей".