Danis 0 19 ноября, 2014 Опубликовано 19 ноября, 2014 · Жалоба Привет, коллеги! Недавно поднял на STM32Fxx FTP сервер и удаленно через Internet пишу файлы во внешнюю flash память. Все неплохо работает, есть вопрос с подходом к верификации данных в принятых файлах. Я использую ftp passive mode, и по сути, аппаратно верифицируются только пакеты пришедшие с Ethernet, можно конечно и проверить пакет после записи на SD. Но этого не достаточно для полного убеждения о целостности файла. Я тут вижу два пути, сначала записать удаленно файл, и скачать обратно, сравнить их Hash (долго, если файл большой). Второй, научить STM-ку считать Hаsh уже записанных файлов по команде (возможно не стандартной) FTP и создавать *.txt файл с Hаsh суммами файлов в текущей директории. После чего можно скачать этот файл и проверить. Но наверняка, есть более красивый и правильный подход, которого я не знаю, так что буду рад подсказке, спасибо! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 19 ноября, 2014 Опубликовано 19 ноября, 2014 · Жалоба CRC32 вполне достаточно в этом случае. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 19 ноября, 2014 Опубликовано 19 ноября, 2014 · Жалоба Ну да, если файл передаётся через интернет, то контрольная сумма TCP слабовата. Если файл требует защиты, то пусть закачивают пару файлов: данные и контрольную сумму. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Danis 0 19 ноября, 2014 Опубликовано 19 ноября, 2014 · Жалоба Ну да, если файл передаётся через интернет, то контрольная сумма TCP слабовата. Если файл требует защиты, то пусть закачивают пару файлов: данные и контрольную сумму. У меня со стороны FTP клиента сидит человек (пока), возможно будет «сидеть» и машина, а со стороны FTP сервера «железка» STM32, она и использует файлы, без человека. Вот смысла закачки файла с контрольной суммой пока недопонимаю, если честно... наверное, это будет уместно, если человек со стороны сервера вытащит флешку и сверит. А так, идею понял, спасибо. CRC32 вполне достаточно в этом случае. Ну уж очень лаконично. Да, в моем случае в контроллер входит аппаратный модуль CRC32, им часто пользуюсь, очень шустрый. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 19 ноября, 2014 Опубликовано 19 ноября, 2014 · Жалоба Но этого не достаточно для полного убеждения о целостности файла. Подключите SSL. Этого будет достаточно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 19 ноября, 2014 Опубликовано 19 ноября, 2014 · Жалоба Вот смысла закачки файла с контрольной суммой пока недопонимаю, если честно... ну я так понимаю реализация может быть такая вы шлете файл, и второй файл со значением хитро посчитанной контрольной суммы. На стороне проца, для каждого файла проц считает по тому же алгоритму хитрую контрольную сумму и сверяет со значением во втором файле. Если все ок, считает файл достоверным. То есть это ваш вариант с хэш кодом, только не надо команды на пересыл контрольной суммы обратно, доставьте ее процу. Но меня интересует вот что, ТСР уже снабжено неплохой контрольной суммой, причем не на весь файл а на каждый пакет. Неужели ее катастрофически не хватает? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aleksandr Baranov 1 19 ноября, 2014 Опубликовано 19 ноября, 2014 · Жалоба вы шлете файл, и второй файл со значением хитро посчитанной контрольной суммы. А почему нельзя хитрую контрольную сумму поместить в первый файл? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 20 ноября, 2014 Опубликовано 20 ноября, 2014 · Жалоба Но меня интересует вот что, ТСР уже снабжено неплохой контрольной суммой, причем не на весь файл а на каждый пакет. Неужели ее катастрофически не хватает? Вы считаете x0+x1+...+xN (ну плюс ещё переносы из старших разрядов) неплохим контролем? Хм.... и зачем тогда люди CRC считают, мучаются?... непонятно.... А почему нельзя хитрую контрольную сумму поместить в первый файл? Непонятно, что автор контролировать хочет. Если - достоверность полученного файла на сервере, то очевидное решение - просто пристыковать CRC32 к концу файла (+4 байта к длине), а на приёмном конце проверить. Если - контроль со стороны отправителя, что получатель получил корректный файл - инфу и принятом файле (имя+длина+CRC32) отправить обратно к клиенту. Любым удобным способом (хоть рядом файл создать, хоть через другой сокет и т.п.). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 20 ноября, 2014 Опубликовано 20 ноября, 2014 · Жалоба А почему нельзя хитрую контрольную сумму поместить в первый файл? потому что не понятно как будет использоваться файл, может формат жестко задан. Но в целом верно то что сказал jcxz не понятно контроль чего нужен... Вы считаете x0+x1+...+xN (ну плюс ещё переносы из старших разрядов) неплохим контролем? да, потому что XOR по 8 битам считаю плохим, а этот считаю не плохим... не супер, но не плохим... кстати еще хорош стандартный метод, зажать выходной файл зипом, передать, а на приемной стороне разархивировать. Тем самым выполняются оба контроля. Архивированный файл содержит внутри контрольную сумму, если он разархивировался значит и был передан правильно, и приемная сторона узнает что сумма сошлась. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 20 ноября, 2014 Опубликовано 20 ноября, 2014 · Жалоба кстати еще хорош стандартный метод, зажать выходной файл зипом, передать, а на приемной стороне разархивировать. Тем самым выполняются оба контроля. Архивированный файл содержит внутри контрольную сумму, если он разархивировался значит и был передан правильно, и приемная сторона узнает что сумма сошлась. Ну да, реализовать на удалённой системе поддержку распаковки ZIP-формата. А потом ещё и дорабатывать это каждый раз, как в ZIP-формат вводятся какие-то нововведения (новые методы сжатия и т.п.). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 20 ноября, 2014 Опубликовано 20 ноября, 2014 · Жалоба я может ошибаюсь, но вроде бы для распаковки предоставлялась библиотека. Давным давно так было сделано обновление прошивки в каком-то продукте. Он заливался по RS232 и zip здорово помогал в ускорении процесса, а так же проверял целостность. Так вот как паковать - это супер мего тайна фирмы производящей архиватор, это их конкурентное преимущество, а как распаковывать было открыто и то ли исходники кода давали, то ли библиотеку, я не очень помню, но помню что проблем с распаковкой вообще не было. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 20 ноября, 2014 Опубликовано 20 ноября, 2014 · Жалоба Так вот как паковать - это супер мего тайна фирмы производящей архиватор, это их конкурентное преимущество, а как распаковывать было открыто и то ли исходники кода давали, то ли библиотеку, я не очень помню, но помню что проблем с распаковкой вообще не было. Время течёт, всё меняется. И вот уже в формат ZIP добавили например AES. И если запаковать с ним, то никакая старая либа такое не распакует. Конечно это опционально и при паковке это можно не включать. Но всё-же всё-же.... Зачем себе усложнять жизнь? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Danis 0 20 ноября, 2014 Опубликовано 20 ноября, 2014 · Жалоба Коллеги, большое спасибо за идеи и рассуждения. Думаю это полезно не только для меня. Не стал сильно сразу расписывать задачу, чтоб не засорять. Со стороны клиента файлы пока передает человек, это не картинки и не музыка, а созданный пакет файлов, например бинарники и другие форматы подготовленные для обработки удаленной «железкой», поэтому есть свобода, и действительно идея прописать внутрь файла 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 20 ноября, 2014 Опубликовано 20 ноября, 2014 · Жалоба Простой проверке CRC32 пакетов, что приходят по TCP я не верю, у меня был случай, когда я скачивал дистрибутив Mplab с сайта Микрочип Где-ж Вы в TCP нашли CRC32??? Почитайте его описание. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
WitFed 1 20 ноября, 2014 Опубликовано 20 ноября, 2014 · Жалоба Про TCP я читал очень давно, как там дополнительно контролируется содержимое внутри уже проверенного внешним CRC32 пакета, но CRC32 вполне себе очень доверятельная вещь ! По инету всё им проверяется на вшивость, мужики очень умные придумывали. И просто, и надёжно. Там на каждый единичный бит в исходном файле к 4-байтному результату XOR-ится уникальное 32-битное число, и если бит/байт или их группа рядом где-то испортится, как обычно бывает в импульсных глюках, то проксорится уже другая цепочка, и вероятность получить тот же код невероятно мала. Для получения той же CRC32 для других данных нужен очень мощный перебор. Происходит вычурная однозначная трансляция из всего множества файлов разных длин в множество 32-битных чисел, которая, естественно, может несколько файлов отобразить в одно и то же число, но на практике это не бывает, особенно если несколько байт изменено, а остальные прежние. Вообще, я считаю, что нужно сначала ошибку увидеть, а потом её начинать бояться, солому стелить как-то... Флэшь тоже может сбоить -- вот там нужны CRC32 в каталоге для каждого файла или даже у каждого сектора, как раньше было у HDD. А у провайдера кэш глючил на прокси (ОЗУ/винт SSD), скорей всего -- они файл получили, куда-то сохранили, потом считали побитый, на пакеты порезали, новой CRC32 закрыли -- и передали, типа "усё хоккей". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться