Jump to content

    
Sign in to follow this  
Danis

FTP сервер на STM-ке

Recommended Posts

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

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

Share this post


Link to post
Share on other sites

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

Share this post


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

 

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

 

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

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

Share this post


Link to post
Share on other sites
Вот смысла закачки файла с контрольной суммой пока недопонимаю, если честно...

 

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

 

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

 

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

Share this post


Link to post
Share on other sites
вы шлете файл, и второй файл со значением хитро посчитанной контрольной суммы.

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

 

Share this post


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

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

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

 

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

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

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

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

Share this post


Link to post
Share on other sites
А почему нельзя хитрую контрольную сумму поместить в первый файл?

 

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

 

 

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

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

 

 

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

Share this post


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

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

Share this post


Link to post
Share on other sites

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

Share this post


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

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

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

Share this post


Link to post
Share on other sites

Коллеги, большое спасибо за идеи и рассуждения. Думаю это полезно не только для меня. Не стал сильно сразу расписывать задачу, чтоб не засорять. Со стороны клиента файлы пока передает человек, это не картинки и не музыка, а созданный пакет файлов, например бинарники и другие форматы подготовленные для обработки удаленной «железкой», поэтому есть свобода, и действительно идея прописать внутрь файла 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 байт в разных местах, которые отличались, распечатал и «сунул в нос» провайдеру, через неделю извинились и что то поменяли, стало нормально.

Share this post


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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this