Привет, коллеги!
Недавно поднял на STM32Fxx FTP сервер и удаленно через Internet пишу файлы во внешнюю flash память. Все неплохо работает, есть вопрос с подходом к верификации данных в принятых файлах. Я использую ftp passive mode, и по сути, аппаратно верифицируются только пакеты пришедшие с Ethernet, можно конечно и проверить пакет после записи на SD. Но этого не достаточно для полного убеждения о целостности файла. Я тут вижу два пути, сначала записать удаленно файл, и скачать обратно, сравнить их Hash (долго, если файл большой). Второй, научить STM-ку считать Hаsh уже записанных файлов по команде (возможно не стандартной) FTP и создавать *.txt файл с Hаsh суммами файлов в текущей директории. После чего можно скачать этот файл и проверить. Но наверняка, есть более красивый и правильный подход, которого я не знаю, так что буду рад подсказке, спасибо!
Полная версия этой страницы: FTP сервер на STM-ке
CRC32 вполне достаточно в этом случае.
Ну да, если файл передаётся через интернет, то контрольная сумма TCP слабовата. Если файл требует защиты, то пусть закачивают пару файлов: данные и контрольную сумму.
Цитата(scifi @ Nov 19 2014, 19:23) 
Ну да, если файл передаётся через интернет, то контрольная сумма TCP слабовата. Если файл требует защиты, то пусть закачивают пару файлов: данные и контрольную сумму.
У меня со стороны FTP клиента сидит человек (пока), возможно будет «сидеть» и машина, а со стороны FTP сервера «железка» STM32, она и использует файлы, без человека. Вот смысла закачки файла с контрольной суммой пока недопонимаю, если честно... наверное, это будет уместно, если человек со стороны сервера вытащит флешку и сверит. А так, идею понял, спасибо.
Цитата(jcxz @ Nov 19 2014, 19:15)
CRC32 вполне достаточно в этом случае.
Ну уж очень лаконично. Да, в моем случае в контроллер входит аппаратный модуль CRC32, им часто пользуюсь, очень шустрый.
Цитата(Danis @ Nov 19 2014, 17:50)
Но этого не достаточно для полного убеждения о целостности файла.
Подключите SSL. Этого будет достаточно.
Цитата
Вот смысла закачки файла с контрольной суммой пока недопонимаю, если честно...
ну я так понимаю реализация может быть такая
вы шлете файл, и второй файл со значением хитро посчитанной контрольной суммы. На стороне проца, для каждого файла проц считает по тому же алгоритму хитрую контрольную сумму и сверяет со значением во втором файле. Если все ок, считает файл достоверным. То есть это ваш вариант с хэш кодом, только не надо команды на пересыл контрольной суммы обратно, доставьте ее процу.
Но меня интересует вот что, ТСР уже снабжено неплохой контрольной суммой, причем не на весь файл а на каждый пакет. Неужели ее катастрофически не хватает?
Цитата(Golikov A. @ Nov 19 2014, 16:46)
вы шлете файл, и второй файл со значением хитро посчитанной контрольной суммы.
А почему нельзя хитрую контрольную сумму поместить в первый файл?
Цитата(Golikov A. @ Nov 20 2014, 02:46)
Но меня интересует вот что, ТСР уже снабжено неплохой контрольной суммой, причем не на весь файл а на каждый пакет. Неужели ее катастрофически не хватает?
Вы считаете x0+x1+...+xN (ну плюс ещё переносы из старших разрядов) неплохим контролем?
Хм.... и зачем тогда люди CRC считают, мучаются?... непонятно....
Цитата(Aleksandr Baranov @ Nov 20 2014, 03:10)
А почему нельзя хитрую контрольную сумму поместить в первый файл?
Непонятно, что автор контролировать хочет.
Если - достоверность полученного файла на сервере, то очевидное решение - просто пристыковать CRC32 к концу файла (+4 байта к длине), а на приёмном конце проверить.
Если - контроль со стороны отправителя, что получатель получил корректный файл - инфу и принятом файле (имя+длина+CRC32) отправить обратно к клиенту. Любым удобным способом (хоть рядом файл создать, хоть через другой сокет и т.п.).
Цитата
А почему нельзя хитрую контрольную сумму поместить в первый файл?
потому что не понятно как будет использоваться файл, может формат жестко задан. Но в целом верно то что сказал jcxz не понятно контроль чего нужен...
Цитата
Вы считаете x0+x1+...+xN (ну плюс ещё переносы из старших разрядов) неплохим контролем?
да, потому что XOR по 8 битам считаю плохим, а этот считаю не плохим... не супер, но не плохим...
кстати еще хорош стандартный метод, зажать выходной файл зипом, передать, а на приемной стороне разархивировать. Тем самым выполняются оба контроля. Архивированный файл содержит внутри контрольную сумму, если он разархивировался значит и был передан правильно, и приемная сторона узнает что сумма сошлась.
Цитата(Golikov A. @ Nov 20 2014, 11:54)
кстати еще хорош стандартный метод, зажать выходной файл зипом, передать, а на приемной стороне разархивировать. Тем самым выполняются оба контроля. Архивированный файл содержит внутри контрольную сумму, если он разархивировался значит и был передан правильно, и приемная сторона узнает что сумма сошлась.
Ну да, реализовать на удалённой системе поддержку распаковки ZIP-формата. А потом ещё и дорабатывать это каждый раз, как в ZIP-формат вводятся какие-то нововведения (новые методы сжатия и т.п.).
я может ошибаюсь, но вроде бы для распаковки предоставлялась библиотека. Давным давно так было сделано обновление прошивки в каком-то продукте. Он заливался по RS232 и zip здорово помогал в ускорении процесса, а так же проверял целостность. Так вот как паковать - это супер мего тайна фирмы производящей архиватор, это их конкурентное преимущество, а как распаковывать было открыто и то ли исходники кода давали, то ли библиотеку, я не очень помню, но помню что проблем с распаковкой вообще не было.
Цитата(Golikov A. @ Nov 20 2014, 13:42)
Так вот как паковать - это супер мего тайна фирмы производящей архиватор, это их конкурентное преимущество, а как распаковывать было открыто и то ли исходники кода давали, то ли библиотеку, я не очень помню, но помню что проблем с распаковкой вообще не было.
Время течёт, всё меняется. И вот уже в формат ZIP добавили например AES. И если запаковать с ним, то никакая старая либа такое не распакует.
Конечно это опционально и при паковке это можно не включать. Но всё-же всё-же.... Зачем себе усложнять жизнь?
Коллеги, большое спасибо за идеи и рассуждения. Думаю это полезно не только для меня. Не стал сильно сразу расписывать задачу, чтоб не засорять. Со стороны клиента файлы пока передает человек, это не картинки и не музыка, а созданный пакет файлов, например бинарники и другие форматы подготовленные для обработки удаленной «железкой», поэтому есть свобода, и действительно идея прописать внутрь файла hash мне нравится. После загрузки файла можно сразу ее пересчитать или даже на ходу по блокам после записи и чтения с SD. Тогда можно будет светси к минимуму напряжения оператора, что будет их «заливать» удаленно. И по приему 226 transfer complete можно будет судить, что файл записан и верифицирован.
В примере *.dvc3 это формат шифрованной прошивки для обновления firmware в нашей компании.
Простой проверке CRC32 пакетов, что приходят по TCP я не верю, у меня был случай, когда я скачивал дистрибутив Mplab с сайта Микрочип, после скачки установка «падала», когда я скачал этот же дистрибутив с другого места, все стало ОК. Я сравнил эти два одинаковых файла по 105 MB утилитой «file compare» и нашел 9 байт в разных местах, которые отличались, распечатал и «сунул в нос» провайдеру, через неделю извинились и что то поменяли, стало нормально.
В примере *.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 секунды
Статус: Соединение установлено, ожидание приглашения...
Ответ: 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 байт в разных местах, которые отличались, распечатал и «сунул в нос» провайдеру, через неделю извинились и что то поменяли, стало нормально.
Цитата(Danis @ Nov 20 2014, 15:04)
Простой проверке CRC32 пакетов, что приходят по TCP я не верю, у меня был случай, когда я скачивал дистрибутив Mplab с сайта Микрочип
Где-ж Вы в TCP нашли CRC32???
Почитайте его описание.
Про TCP я читал очень давно, как там дополнительно контролируется содержимое внутри уже проверенного внешним CRC32 пакета, но CRC32 вполне себе очень доверятельная вещь !
По инету всё им проверяется на вшивость, мужики очень умные придумывали. И просто, и надёжно.
Там на каждый единичный бит в исходном файле к 4-байтному результату XOR-ится уникальное 32-битное число, и если бит/байт или их группа рядом где-то испортится, как обычно бывает в импульсных глюках, то проксорится уже другая цепочка, и вероятность получить тот же код невероятно мала. Для получения той же CRC32 для других данных нужен очень мощный перебор.
Происходит вычурная однозначная трансляция из всего множества файлов разных длин в множество 32-битных чисел, которая, естественно, может несколько файлов отобразить в одно и то же число, но на практике это не бывает, особенно если несколько байт изменено, а остальные прежние.
Вообще, я считаю, что нужно сначала ошибку увидеть, а потом её начинать бояться, солому стелить как-то... Флэшь тоже может сбоить -- вот там нужны CRC32 в каталоге для каждого файла или даже у каждого сектора, как раньше было у HDD.
А у провайдера кэш глючил на прокси (ОЗУ/винт SSD), скорей всего -- они файл получили, куда-то сохранили, потом считали побитый, на пакеты порезали, новой CRC32 закрыли -- и передали, типа "усё хоккей".
По инету всё им проверяется на вшивость, мужики очень умные придумывали. И просто, и надёжно.
Там на каждый единичный бит в исходном файле к 4-байтному результату XOR-ится уникальное 32-битное число, и если бит/байт или их группа рядом где-то испортится, как обычно бывает в импульсных глюках, то проксорится уже другая цепочка, и вероятность получить тот же код невероятно мала. Для получения той же CRC32 для других данных нужен очень мощный перебор.
Происходит вычурная однозначная трансляция из всего множества файлов разных длин в множество 32-битных чисел, которая, естественно, может несколько файлов отобразить в одно и то же число, но на практике это не бывает, особенно если несколько байт изменено, а остальные прежние.
Вообще, я считаю, что нужно сначала ошибку увидеть, а потом её начинать бояться, солому стелить как-то... Флэшь тоже может сбоить -- вот там нужны CRC32 в каталоге для каждого файла или даже у каждого сектора, как раньше было у HDD.
А у провайдера кэш глючил на прокси (ОЗУ/винт SSD), скорей всего -- они файл получили, куда-то сохранили, потом считали побитый, на пакеты порезали, новой CRC32 закрыли -- и передали, типа "усё хоккей".
Цитата(WitFed @ Nov 20 2014, 16:11)
Про TCP я читал очень давно, как там дополнительно контролируется содержимое внутри уже проверенного внешним CRC32 пакета, но CRC32 вполне себе очень доверятельная вещь !
Ещё раз внимательно читаем по слогам: в TCP-кадрах нет CRC32-контроля.
Вот расчёт контрольной суммы для TCP-кадра из рабочего TCP-стека:
CODE
static s32 CalcCsum(void const *start, int cnt, s32 sum)
{
u16 const *p = (u16 const *)start;
while ((cnt -= 2) >= 0) sum += *p++; //sum words
if (!(cnt + 1)) sum += *(u8 *)p; //add left-over byte, if any
while ((u32)(sum = (sum & 0xFFFF) + ((u32)sum >> 16)) >> 16); //fold 32-bit sum to 16 bits
return ~sum;
}
{
u16 const *p = (u16 const *)start;
while ((cnt -= 2) >= 0) sum += *p++; //sum words
if (!(cnt + 1)) sum += *(u8 *)p; //add left-over byte, if any
while ((u32)(sum = (sum & 0xFFFF) + ((u32)sum >> 16)) >> 16); //fold 32-bit sum to 16 bits
return ~sum;
}
Покажите мне - где здесь CRC32????
Цитата(jcxz @ Nov 20 2014, 13:21)
...где здесь CRC32????
Вам шашечки или ехать?
От противного =>
Вы утверждаете, что контрольая сумма даёт сбои при конкретной реализации и посему TCP не надёжен в плане сетевой передачи?
Если нет - тогда не понятен изначальный посыл. Если да, то собственно это немного противоречит мировой практики, несколько тонн кода и
фиг знает сколько часов работы...
На самом деле я что-то тоже в какой-то момент начал думать что в ТСР CRC32, но для себя эту проблему решил прочитав еще раз формат пакета, там обычная 16 битная сумма.
Такая контрольная сумма весьма не дурна, но не гениальна. Она не замечает перестановку слов, и двойную ошибку одного бита. Учитывая сетевой протокол, избыточное кодирование и прочее она годиться для ТСР (вот теперь сижу вспоминаю а есть ли там избыточное кодирование
), и дает единицы ошибок в год, но CRC32 в разы надежнее...
Принимать из интернета битые файлы - это нормальная практика, не скажу чтобы так каждый день, но при передачи файлов по сети такое несколько раз случалось, так что проблема не мифическая.
Единственное я бы не стал встраивать контрольную сумму в FTP, все таки это вне протокола, то есть я бы принял файл, а потом проверил и выставил бы какой-то признак файлу, так было бы идеологически правильнее, чем передавать сигнал прием завершен или нет в зависимости от целостности, но это на усмотрение автора...
Такая контрольная сумма весьма не дурна, но не гениальна. Она не замечает перестановку слов, и двойную ошибку одного бита. Учитывая сетевой протокол, избыточное кодирование и прочее она годиться для ТСР (вот теперь сижу вспоминаю а есть ли там избыточное кодирование
), и дает единицы ошибок в год, но CRC32 в разы надежнее...Принимать из интернета битые файлы - это нормальная практика, не скажу чтобы так каждый день, но при передачи файлов по сети такое несколько раз случалось, так что проблема не мифическая.
Единственное я бы не стал встраивать контрольную сумму в FTP, все таки это вне протокола, то есть я бы принял файл, а потом проверил и выставил бы какой-то признак файлу, так было бы идеологически правильнее, чем передавать сигнал прием завершен или нет в зависимости от целостности, но это на усмотрение автора...
Хорошо, в TCP простая сумма. Но этот TCP идет поверх Ethernet, в котором как раз таки CRC-32.
Википедия:
Википедия:
Код
Самый популярный и рекомендуемый IEEE полином для CRC-32 используется в Ethernet,
Вот оно откуда воспоминание о CRC32, ведь помнил что был какой-то гемор в железной его реализации%)))
Неужели тогда не хватает CRC32, ведь реально по сети есть шансы скачать битый файл...
Неужели тогда не хватает CRC32, ведь реально по сети есть шансы скачать битый файл...
Цитата(kolobok0 @ Nov 20 2014, 18:12)
Вы утверждаете, что контрольая сумма даёт сбои при конкретной реализации и посему TCP не надёжен в плане сетевой передачи?
Пропускают ошибки любые методы контроля. Вопрос в вероятности. А по этому критерию CRC32 несравнимо лучше обычной суммы.
И если поддаться паранойе, то можно не ограничиваться 32 разрядами. Есть полиномы и на большие разрядности.
Цитата(Сергей Борщ @ Nov 20 2014, 19:12)
Хорошо, в TCP простая сумма. Но этот TCP идет поверх Ethernet, в котором как раз таки CRC-32.
А где ТС пишет, что клиент и сервер находятся в одной Ethernet-сети?
Он вроде про Интернет пишет. А значит - на пути следования пакета могут быть различные физические+канальные среды передачи.
Плюс - переход пакета из одного сегмента сети в другой, через кучу маршрутизаторов.
Не здесь-ли и возникают сбои, приводящие к ошибкам в принятых по FTP файлах?
А ещё - как я понимаю для Ethernet обязательно только формирование кадров с CRC, но не обязателен контроль этой CRC на приёмной стороне.
Цитата(Golikov A. @ Nov 20 2014, 18:26)
Такая контрольная сумма весьма не дурна, но не гениальна. Она не замечает перестановку слов, и двойную ошибку одного бита. Учитывая сетевой протокол, избыточное кодирование и прочее она годиться для ТСР (вот теперь сижу вспоминаю а есть ли там избыточное кодирование), и дает единицы ошибок в год, но CRC32 в разы надежнее...
), и дает единицы ошибок в год, но CRC32 в разы надежнее...Я бы сказал - не в разы, а на порядки. Учитывая кол-во разрядов в контрольной сумме TCP и в CRC32. Уж не говоря о том что даже CRC16 будет надёжнее обычной суммы.
Кодирование - это функция вроде канального или физического уровня протокола (в частности - Ethernet-уровня или какой там канальный/физический уровень в данном сегменте). А TCP - это более высокий уровень OSI.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.