Comments 13
Интересно, но несколько сумбурно
Совершенно не ясен смысл такого исходного текста декодера — он ничего толком не поясняет. Код процедур с комментариями был бы уместнее.
Аналогично про умножению на матрицу — «Умножение на матрицу Арикана осуществляется с помощью функции, приведенной ниже:» и дальше название функции. Что, где, куда, зачем ?! Можно было бы сразу и код функции привести.
Совершенно не ясен смысл такого исходного текста декодера — он ничего толком не поясняет. Код процедур с комментариями был бы уместнее.
Аналогично про умножению на матрицу — «Умножение на матрицу Арикана осуществляется с помощью функции, приведенной ниже:» и дальше название функции. Что, где, куда, зачем ?! Можно было бы сразу и код функции привести.
+1
Что конкретно вам не понятно?
+1
Непонятно как зачем вообще такие исходники показывать :) Плюс, интересна реализация декодра.
0
Если не забыть про первую вставку, по коду видно, какие параметы у вызова. А про умножение на матрицу раскрывать нечего, оно и есть умножение на матрицу.
Реализация декодера в Гитхабе, просто откройте и посмотрите. Если будут вопросы, милости присим, задавайте сюда.
Реализация декодера в Гитхабе, просто откройте и посмотрите. Если будут вопросы, милости присим, задавайте сюда.
0
Зачем-то прочитал стандарт openUNB.
Так себе стандарт, если честно. Если хуже не сказать. А описание вообще ужасное.
Есть, например, стойкое ощущение (или даже уверенность), что протокол очень уязвим к целому спектру атак. Шифруются только данные, используется постоянный ключ при длине шифроблока 64/128 бит, пакеты-подтверждения не шифруются. Т.е., как минимум, возможны запись и повторная передача зашифрованных сообщений, отправка поддельных подтверждений о приёме и подделка пакетов с нулевой длинной данных. Одно это уже ого-го дыра.
А постоянный ключ 64 бита с учётом известных уязвимостей алгоритма шфирования, вероятно, может быть подобран за время порядка месяца на вполне доступном оборудовании.
Для тех же бытовых счётчиков сразу приходит на ум примитивная атака с передачей одних и тех же показаний, либо нужно уже поверх протокола какие-то костыли городить.
Принципиально нет широковещательных пакетов, и при большом количестве абонентов становятся просто невозможными некоторые типовые операции — от массового переконфигурирования устройств, до синхронизации времени. Ведь каждому устройству должен быть передан адресный пакет. В результате базовая станция может обработать лишь очень небольшое число абонентов. В то же время, в условиях города их могут быть тысячи и десятки тысяч.
Нет возможности полноценного пакетного обмена с устройствами — один цикл обмена занимает не менее 48 секунд! В результате типовая операция «получить данные от устройства, выдать команду устройству, получить ответ» занимает 48x3 — не менее 144 секунд. Это по оптимистичному сценарию. Если прикинуть максимальное количество абонентов, которых можно обслуживать по такому протоколу для случая те же бытовых счётчиков, то получается весьма печальная картина.
Почему-то принципиально исключена возможность инициации связи по нисходящему каналу. «Потому что, устройства не имеют часов реального времени». ?!!! Это более чем спорное утверждение, т.к. сейчас нет проблемы в часах реального времени — они есть или могут быть «бесплатно» реализованы практически во всех устройствах IoT, а их потребление не является определяющим (единицы микроампер или даже сотни наноампер). А довод о низкой точности генераторов у абонентских устройств в данном контексте вообще ложный — малопотребляющие кварцевые резонаторы на 32,768 кГц сейчас стоят практически везде, и даже в самом дешёвом исполнении во всём температурном диапазоне обеспечивают точность порядка секунды-двух в сутки, чего более чем достаточно для грубой синхронизации временных интервалов. При этом развитие идёт в сторону усложнения даже самых простых устройств IoT.
Возможности подстройки часов и синхронизации времени абонентских устройств тоже нет. Только через костыли в виде отправки отдельного информационного пакета каждому устройству. Хотя, это крайне востребованная функция.
И из-за принципиальных ограничений низкоуровневого протокола решить все эти проблемы какими-то мерами на более высоких уровнях протокола обмена будет проблематично. Не говоря о том, что смысл нового протокола должен быть в том, чтобы покрыть текущие и перспективные потребности рынка, а не в том, чтобы сразу городить поверх него костыли.
Короче, те же газовые счётчики по требованиям Газпрома не подключить. Электро-счётчики — аналогично. И вообще только очень небольшой класс устройств можно таким протоколом подключить.
И это преподносится, как универсальный супер-протокол.
А всего-то нужно было отказаться от неверного предположения об обязательном отсутствии часов реального времени у абонентских устройств и изучить реальные потребности самых массовых сегментов КОММЕРЧЕСКОГО рынка IoT-устройств. Вместо этого взяли какую-то узкую конкретную задачу, узкий класс устройств, отказались учитывать вектор развития IoT-устройств и сгородили крайне ограниченный и уже устаревший протокол.
Так себе стандарт, если честно. Если хуже не сказать. А описание вообще ужасное.
Есть, например, стойкое ощущение (или даже уверенность), что протокол очень уязвим к целому спектру атак. Шифруются только данные, используется постоянный ключ при длине шифроблока 64/128 бит, пакеты-подтверждения не шифруются. Т.е., как минимум, возможны запись и повторная передача зашифрованных сообщений, отправка поддельных подтверждений о приёме и подделка пакетов с нулевой длинной данных. Одно это уже ого-го дыра.
А постоянный ключ 64 бита с учётом известных уязвимостей алгоритма шфирования, вероятно, может быть подобран за время порядка месяца на вполне доступном оборудовании.
Для тех же бытовых счётчиков сразу приходит на ум примитивная атака с передачей одних и тех же показаний, либо нужно уже поверх протокола какие-то костыли городить.
Принципиально нет широковещательных пакетов, и при большом количестве абонентов становятся просто невозможными некоторые типовые операции — от массового переконфигурирования устройств, до синхронизации времени. Ведь каждому устройству должен быть передан адресный пакет. В результате базовая станция может обработать лишь очень небольшое число абонентов. В то же время, в условиях города их могут быть тысячи и десятки тысяч.
Нет возможности полноценного пакетного обмена с устройствами — один цикл обмена занимает не менее 48 секунд! В результате типовая операция «получить данные от устройства, выдать команду устройству, получить ответ» занимает 48x3 — не менее 144 секунд. Это по оптимистичному сценарию. Если прикинуть максимальное количество абонентов, которых можно обслуживать по такому протоколу для случая те же бытовых счётчиков, то получается весьма печальная картина.
Почему-то принципиально исключена возможность инициации связи по нисходящему каналу. «Потому что, устройства не имеют часов реального времени». ?!!! Это более чем спорное утверждение, т.к. сейчас нет проблемы в часах реального времени — они есть или могут быть «бесплатно» реализованы практически во всех устройствах IoT, а их потребление не является определяющим (единицы микроампер или даже сотни наноампер). А довод о низкой точности генераторов у абонентских устройств в данном контексте вообще ложный — малопотребляющие кварцевые резонаторы на 32,768 кГц сейчас стоят практически везде, и даже в самом дешёвом исполнении во всём температурном диапазоне обеспечивают точность порядка секунды-двух в сутки, чего более чем достаточно для грубой синхронизации временных интервалов. При этом развитие идёт в сторону усложнения даже самых простых устройств IoT.
Возможности подстройки часов и синхронизации времени абонентских устройств тоже нет. Только через костыли в виде отправки отдельного информационного пакета каждому устройству. Хотя, это крайне востребованная функция.
И из-за принципиальных ограничений низкоуровневого протокола решить все эти проблемы какими-то мерами на более высоких уровнях протокола обмена будет проблематично. Не говоря о том, что смысл нового протокола должен быть в том, чтобы покрыть текущие и перспективные потребности рынка, а не в том, чтобы сразу городить поверх него костыли.
Короче, те же газовые счётчики по требованиям Газпрома не подключить. Электро-счётчики — аналогично. И вообще только очень небольшой класс устройств можно таким протоколом подключить.
И это преподносится, как универсальный супер-протокол.
А всего-то нужно было отказаться от неверного предположения об обязательном отсутствии часов реального времени у абонентских устройств и изучить реальные потребности самых массовых сегментов КОММЕРЧЕСКОГО рынка IoT-устройств. Вместо этого взяли какую-то узкую конкретную задачу, узкий класс устройств, отказались учитывать вектор развития IoT-устройств и сгородили крайне ограниченный и уже устаревший протокол.
+1
Я прошу прощения, но это уже совсем другой OpenUNB. Старый вариант переработан полностью. Прошу подождать немного до публикации нового варианта. Эти статьи выходят немного заранее, чтобы к моменту публикации были готовы средства разработки. Я прошу посмотреть мои предыдущие публикации по этой теме, все станет ясно.
0
Было бы еще интересно посмотреть на PER. Бывает, что на BER наблюдается выигрыш ощутимый, однако на PER выигрыш значительно меньше.
BER выходит на полку или у этого кода такой проблемы нет?
BER выходит на полку или у этого кода такой проблемы нет?
+1
И ещё проблема. Это неплохой алгоритм коррекции ошибок, но что-то мне подсказывает, что у вас в протоколе нет стойкой к искажениям синхронизации начала пакета. В реальной жизни будут довольно частые ошибки потери бита или, даже, вставки бита. особенно в преамбуле и самом начале пакета. Против них это кодирование не помогает же.
0
Можете конкретнее сказать, что вам подсказывает, что в протоколе нет стойкой синхронизации? В предыдущей статье есть описание поиска преамбулы, исходники поиска есть на Гитхибе. Вы имеете все исходные данные для доказательной критики. Прошу критиковать, это нам будет очень полезно.
Я не вижу причин для появления ошибок потери или вставки бита в системе OpenUNB. Поясните ваш тезис.
Я не вижу причин для появления ошибок потери или вставки бита в системе OpenUNB. Поясните ваш тезис.
0
Sign up to leave a comment.
Интернет вещей по-русски. Помехоустойчивое кодирование в OpenUNB