• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Нужна помощь UDP как сырой пакет

nikolz

Well-known member
Добрый день,
Что- то не выходи у меня каменная чаша.
-------------------------
Задумка такая.
Исследования показали,
что пакет UDP на ESP8266 можно передать минимум за 285 мс.
пакет ESP-NOW можно передать за 117 мс
сырой пакет можно передать за 117 мс
---------------------
задача в том, что бы передать в качестве сырого пакет UDP пакет.
--------------------
Для теста взял пакет UDP из WireShark и передал его как сырой.
Пакет излучается (контролирую по току потребления) , но в WireShark не появляется.
=====================
Приветствуются любые конструктивные идеи
 

pvvx

Активный участник сообщества
При уже готовом соединении с AP любой пакет передается не через мс, а через мкс.
Из вашего описания не ясно: куда и от куда и при каких условиях и что за мс?
Что такое "можно передать" и куда?
 

pvvx

Активный участник сообщества
Для дальнейшего уточнения:
  1. “Сырой пакет в WiFi” – это фрейм WiFi? Если да -> выбирайте тип фрейма хоть тут: Wi-Fi, Фреймы При этом максимальная длина кадра данных 802.11 равна 2346 байт…
  2. Если брать на уровень выше – IP протокол, то тут длина блока другая и = MTU.
  3. И как вы передаете “скопированный UDP” пакет? Multicast, ... ?
 

nikolz

Well-known member
Для дальнейшего уточнения:
  1. “Сырой пакет в WiFi” – это фрейм WiFi? Если да -> выбирайте тип фрейма хоть тут: Wi-Fi, Фреймы При этом максимальная длина кадра данных 802.11 равна 2346 байт…
  2. Если брать на уровень выше – IP протокол, то тут длина блока другая и = MTU.
  3. И как вы передаете “скопированный UDP” пакет? Multicast, ... ?
уточняю задачу
речь идет о передаче пакета при выходе из режима сна.
время складывается из четырех составляющих
1) время на старт из пзу составляет 84 мс
2) время на загрузку прошивки составляет 15 мс
3) время включение и настройки WiFi составляет 10 мс
В итоге 110 мс - это затраты времени до момента передачи
далее если это ESP-NOW или сырой пакет (короткий) то время 7 мс из которых работа передатчика 2 мс
итого 117 мс
----------------------
В режиме UDP идет куда пакетов (примерно 6 по 2 мс)
до включения передатчика работает приемник 100 мс
потом несколько пакетов на интервале 50 мс
итого примерно 280 мс
===================
Так как в режиме передачи пакетов UDP не надо устанавливать соединение
то интересно было бы послать пакет UDP как сырой
------------------------
Но пока не получается его увидеть сканером пакетов
тип фрейма я выбрал
вот такой пакет :
----------------------------------------------
uint8_t sbuf[30+256] = {
0x08,0x00, //тип IP data (0x08),
0x45, //версия 4 Header длина 20 байт
0x00, //Differentiated Services 00
0x00,0x4e, //total length 78
0x00,0x03, //идентификатор 2
0x00,0x00, //флаги
0x80, //time to live 128
0x11, // 17 - протокол UDP
0xb7,0xe6, //контрольная сумма
0xc0,0xa8,0x00,0x66, //источник 192.168.0.102
0xc0,0xa8,0x00,0xff, //приемник 192.168.0.255
0x0f,0x9f, //порт источника 3999
0x0f, 0x9f, //порт приемника 3999
0x00, 0x3a, //длина 58
0x88, 0xed, //контрольная сумма
0x74,0x65,0x73,0x74,0x3b,0x32, //данные 50 байт
0x30,0x38,0x31,0x38,0x30,0x3b,0x38,0x3b,0x31,0x3b,0x38,0x32,0x33,0x32,0x31,0x38,
0x3b,0x32,0x3b,0x31,0x3b,0x33,0x39,0x35,0x32,0x32,0x33,0x38,0x3b,0x30,0x3b,0x31,
0x3b,0x34,0x36,0x33,0x37,0x30,0x34,0x36,0x33,0x3b,0x35
};
 

pvvx

Активный участник сообщества
передаче пакета при выходе из режима сна.

время складывается из четырех составляющих
1) время на старт из пзу составляет 84 мс
2) время на загрузку прошивки составляет 15 мс
3) время включение и настройки WiFi составляет 10 мс
В итоге 110 мс - это затраты времени до момента передачи
В доках Espressif сказано, что время просыпания зависит от типа инициализации WiFi и в минимальном режиме (без калибровок) составляет 2 мс. Или опять врут? :)
далее если это ESP-NOW или сырой пакет (короткий) то время 7 мс из которых работа передатчика 2 мс
итого 117 мс
memcpy() пакета в буфер передачи и инициализация псевдо DMA к передатчику и его запуск занимает 5 мс? :eek: Тогда это полный отстой.
Должно быть в мкс от готового бинарного фрейма (а вы его и готовите) до передачи(!).
К примеру - при работе с TCP, а это ещё и над-уровень IP + стек TCP, кол-во переданных и принятых пакетов в сек у ESP8266 составляет более тысячи...
В режиме UDP идет куда пакетов (примерно 6 по 2 мс)
до включения передатчика работает приемник 100 мс
потом несколько пакетов на интервале 50 мс
итого примерно 280 мс
до 100.24 mc - это при пассивном режиме сканирования AP. И то, при установке что период beacon на AP настроен по умолчанию... При активном - пару с плюсом mc, если всё сложилось и не устроили коллизии...
В итого - что ESP-NOW, что multicast UDP.
Отличия:
Инициализация низкоуровневого драйвера разборки raw фреймов WiFi + сам стек LwIP - явно до 1 mc (в реале там в коде инициализации всего назначение таймера :) ).
Инициализация декодера пакетов для API ESP-NOW - вы указали 5 мс.
Время согласования с AP в 802.11 при выходе из (DTIM) = до пары пакетов и зависит от роутера.
Время согласования с другим модулем при неизвестных у участников MAC ESP-NOW = десятки mc(?).

Итог - советую разобраться в протоколах WiFi до выкидывания никчемных замеров с неизвестными вам вызовами процедур из SDK/Arduino/... :) :p
 

nikolz

Well-known member
В доках Espressif сказано, что время просыпания зависит от типа инициализации WiFi и в минимальном режиме (без калибровок) составляет 2 мс. Или опять врут? :)
memcpy() пакета в буфер передачи и инициализация псевдо DMA к передатчику и его запуск занимает 5 мс? :eek: Тогда это полный отстой.
Должно быть в мкс от готового бинарного фрейма (а вы его и готовите) до передачи(!).
К примеру - при работе с TCP, а это ещё и над-уровень IP + стек TCP, кол-во переданных и принятых пакетов в сек у ESP8266 составляет более тысячи...

до 100.24 mc - это при пассивном режиме сканирования AP. И то, при установке что период beacon на AP настроен по умолчанию... При активном - пару с плюсом mc, если всё сложилось и не устроили коллизии...
В итого - что ESP-NOW, что multicast UDP.
Отличия:
Инициализация низкоуровневого драйвера разборки raw фреймов WiFi + сам стек LwIP - явно до 1 mc (в реале там в коде инициализации всего назначение таймера :) ).
Инициализация декодера пакетов для API ESP-NOW - вы указали 5 мс.
Время согласования с AP в 802.11 при выходе из (DTIM) = до пары пакетов и зависит от роутера.
Время согласования с другим модулем при неизвестных у участников MAC ESP-NOW = десятки mc(?).

Итог - советую разобраться в протоколах WiFi до выкидывания никчемных замеров с неизвестными вам вызовами процедур из SDK/Arduino/... :) :p
Я взял для сравнение Ваш пакет который использовал Ch ... для передачи напряжения (ну вы знаете)
Получил такие же интервалы как указано выше.
Возможно, что Вы правы (теоретически) но я измеряю практически что получилось то получилось
У меня лучше не получается
В инете лучше , чем у меня не нашел.
Поэтому решил спросить подсказку.
 

pvvx

Активный участник сообщества
Поэтому решил спросить подсказку.
Основная и неизменная "подсказка":

Если у вас всего одно соединение двух модулей с очень малым трафиком (передача пару байт с периодами более нескольких сек) и “пофиг на других участников эфира”, тогда возможно альтернативное использование приемо-передатчика WiFi со своими протоколами (типа ESP-NOW). Но и тут есть возможность использовать стандартные фреймы 802.11, которые принимаются любым роутером с возможностью их логгирования и анализа без специального ПО. ESP-NOW таковым не является. Уже были продемонстрированы примеры использования фрейма beacon для передачи короткой информации на роутер и они показали минимальное время активности (просыпание-засыпание) ESP8266. Это достаточно просто – модуль просыпается, инициализирует только передатчик WiFi и передает raw пакет beacon к примеру с именем “ID+код” и вырубается. В роутере (и многих ОС) такие принятые фреймы доступны в базовом API и их разбор с дальнейшей обработкой производится без проблем. Но в данном варианте нет подтверждений приема (как и при использовании UDP) и достаточно часто возможно нарваться на коллизии в эфире, тем самым ещё и мешая другим участникам эфира...

Если вы делаете связь датчиков на WiFi для дома, то они не должны мешать работать другим. В таком случае придется выбирать стандартный вариант 802.11 с DTIM(). Это дает гораздо больше преимуществ – доступ к любым сервисам и шифрование передачи. Потери энергии у каждого автономного датчика в таком режиме могут получиться меньше, даже по сравнению с ESP-NOW. Меньше – при использовании своих процедур, а не стандартных от Espressif(!). Основная потеря уходит на первое включение при соединении с AP и переходе в режим DTIM(n). Далее модуль засыпает (отключается) на строго нормируемое время. От точности установки времени сна зависит общее потребление. Модулю необходимо проснуться строго перед приемом beacon от AP, который идет достаточно четко. По практике и анализу роутеров со средней ценой – уход строба beacon составляет нескольких мкс за сек и определен температурным уходом кварца… Модуль, приняв beacon, согласует передачу, передает данные, снова уходит в DTIM(n) и засыпает. На это требуется не так уж много mc активности. Стандартная процедура выхода в sleep от Espressif у ESP8266 в десятки раз длительнее… А т.к. все альтернативные процедуры для такого метода выданы желающим уже несколько лет назад и показаны/измерены вдоль и поперек, показав лучшие результаты, чем использование ESP-NOW и прочих кривых вариантов, то дальнейшие разговоры не о чем.
 

pvvx

Активный участник сообщества
Вообще на сегодня заниматься какими-то кривыми ESP-NOW и прочими само-мазахисткими-выдумками протоколов нет никакого смысла.. Ну кроме как для детсадовских игрушек по типу Arduino ( = купил, потыркал, сделал блог, выкинул).

Если вы решили баловаться своими силами дома и вас интересует минимальная цена комплекта – WiFi датчики + спец. роутер для них, тогда:

Ныне в продаже на ali завал WiFi repeater в корпусе со встроенным БП за 500..600 руб для 2.4ГГц и (если покопать и взять пачку) от 600 до 900 руб обойдется такой-же двух-диапазонный (+5ГГц WiFi).

Варианты исполнения на любой вкус:
upload_2019-7-24_16-43-29.pngupload_2019-7-24_16-44-30.png

Для простоты программирования проще взять те, которые имеют известный SoC с наличием OpenWRT под него и слепить специальную версию с поддержкой пачки внешних ESP8266 работающих в режиме DTIM()... Специальная версия требуется чтобы “ложить” их спать (в DTIM(n)) по своим условиям, а не как попало - c частными запретами от пролетающих мух (пакетов в общей местной сети) и т.д.

Есть и мелкие WiFi роутеры со встроенной АКБ, но как правило у них БП внешний. Стоят аналогично – менее SonOff поделок :p
Этим достигните минимальное потребление и устойчивость всего комплекса.

PS: К примеру, есть с SoC MT7628KN - MIPS 580 MHz со встроенные 8 МБ ОЗУ… Soc RTL8196UE со встроенной RAM… И т.д.
 

pvvx

Активный участник сообщества
@nikolz - И ещё на счет “посоветовать”:
Надеюсь, вы поймете, почему и куда ушли многие с ESP32 и т.д. И кто остался в них :)

Если не понятно, то ещё раз: китайцы освоили упаковку в один корпус DRAM c CPU и прочим, что сильно провалило цену… На склада залежалась куча старой eMMC, что позволяет наращивать объем Flash/RAM по низкой цене… Всякие devboard ESP8266/32 в корпусе и с БП для телепузиков-Ардуинщиков ныне стоят больше полнофункциональных коробочек с ali c WiFi, LAN, внутренних IO и поддерживающих Linux… ESP остался исключительно для впаривания Arduino и обогащения на детях и не шарящим в электронике с программированием.

Для автономных датчиков с малым потреблением существуют специальные протоколы и приемо-передатчики, а не WiFi…
 

nikolz

Well-known member
@nikolz - И ещё на счет “посоветовать”:
Надеюсь, вы поймете, почему и куда ушли многие с ESP32 и т.д. И кто остался в них :)

Если не понятно, то ещё раз: китайцы освоили упаковку в один корпус DRAM c CPU и прочим, что сильно провалило цену… На склада залежалась куча старой eMMC, что позволяет наращивать объем Flash/RAM по низкой цене… Всякие devboard ESP8266/32 в корпусе и с БП для телепузиков-Ардуинщиков ныне стоят больше полнофункциональных коробочек с ali c WiFi, LAN, внутренних IO и поддерживающих Linux… ESP остался исключительно для впаривания Arduino и обогащения на детях и не шарящим в электронике с программированием.

Для автономных датчиков с малым потреблением существуют специальные протоколы и приемо-передатчики, а не WiFi…
Про использование raw пакет beacon к примеру я уже выше написал, что результаты по времени те же самые.
Я ставил этот пакет и измерял
-----------------------------
Все что вы написали по техническим вопросам имеет место быть.
Но вот вам три возражения
1) Протокол ESP-NOW это фактически BLT
2) Если роутера нет вообще то никому ничего не мешает
3) если роутер завис - свет выключили то вся ваша умная электроника в доме перестает общаться
--------------------------------
Было бы совсем замечательно, если бы Вы в своих рассуждениях ограничились лишь техническими вопросами
и не занимались оскорблениями собеседников, навешиванием ярлыков и попыткой унизить других.
В вашем возрасте пора научиться уважать собеседников хотя бы из уважения к себе любимому.
 

pvvx

Активный участник сообщества
Все что вы написали по техническим вопросам имеет место быть.
А другого и не писал, кроме тенденций от них. Зря вы выдумываете, что на кого-то "оскорблениями"...
Но вот вам три возражения
1) Протокол ESP-NOW это фактически BLT
2) Если роутера нет вообще то никому ничего не мешает
3) если роутер завис - свет выключили то вся ваша умная электроника в доме перестает общаться
Электроника в доме управляет электроникой.
Если нет UPS или внешней подачи эл.энергии нет -> электроника не работает.
"Роутеры" не виснут. Тем более c собственно переписанной прошивкой, а имеющиеся покупные - у меня работают от USP годами и перегружаются только по команде...
В продаже так-же есть роутеры с АКБ - и их цена не велика, городские переключения и прочие баги сети выдержат, т.к. за последний десяток лет электроснабжение отваливалось один раз в пределе до пары часов (орали во всех сми), а UPS вообще не вырубался (с 2001 года выключал 2 раза: первый раз при смене UPS, второй - на смену всех АКБ).
П.п. 3 можно исключать :)
По п.п.2 - Я не могу найти мест, где нет роутера и нужны датчики по WiFi. Ну кроме как при гео-разведке в местах где месяцами не встречается никто и за сотни лет оставляешь первый след...
По п.п.1 не знаю что такое 'BLT'. Значит мне не нужен :)
 

nikolz

Well-known member
А другого и не писал, кроме тенденций от них. Зря вы выдумываете, что на кого-то "оскорблениями"...
Электроника в доме управляет электроникой.
Если нет UPS или внешней подачи эл.энергии нет -> электроника не работает.
"Роутеры" не виснут. Тем более c собственно переписанной прошивкой, а имеющиеся покупные - у меня работают от USP годами и перегружаются только по команде...
В продаже так-же есть роутеры с АКБ - и их цена не велика, городские переключения и прочие баги сети выдержат, т.к. за последний десяток лет электроснабжение отваливалось один раз в пределе до пары часов (орали во всех сми), а UPS вообще не вырубался (с 2001 года выключал 2 раза: первый раз при смене UPS, второй - на смену всех АКБ).
П.п. 3 можно исключать :)
По п.п.2 - Я не могу найти мест, где нет роутера и нужны датчики по WiFi. Ну кроме как при гео-разведке в местах где месяцами не встречается никто и за сотни лет оставляешь первый след...
По п.п.1 не знаю что такое 'BLT'. Значит мне не нужен :)
ну и зачем вы в этой теме пишите?
в чем Ваша помощь ?
 

pvvx

Активный участник сообщества
ну и зачем вы в этой теме пишите?
в чем Ваша помощь ?
Намеки что делаете неверно и описания по поводу передачи "Сырой пакет в WiFi' были даны. На остальные тех. вопросы вы не ответили - это можно воспринимать как отказ от дальнейшего разбора из-за безграмотности. В итоге понижаем уровень и переходим к бытовым аллегориям.
О чем тут ещё писать?
 

pvvx

Активный участник сообщества
Гуру @nikolz наверно под помощью предполагает его бесплатное обучение? :)
Ну не буду скатываться, т.к. не вижу пользы от вложений в актив nikolz...

Но детям есть подсказка что Гуру nikolz делает не так:

RAW формат фрейма данных MAC уровня в WiFi 802.11:

дернуто из 802.11 Wireless Networks: The Definitive Guide, 2nd Edition
 

pvvx

Активный участник сообщества
Дальнейшие разъяснения для Гуру nikolz,
почему все писанные выше сообщения относится именно к тех.ответам на его глупые вопросы, но теперь придется его тыкать носом и раскрывать всем его полную некомпетенцию в области WiFi модулей, которой он занимается уже много лет.

Т.к. для нормальной работы wireshark с WiFi пакетами в win нужен специальный WLAN sniffer адаптер, то выше приведены варианты на чем его возможно построить быстро и за дешево. На ESP8266 и подобных(!) не выйдет, т.к. трафик одного канала 802.11n при HT20 54Мб/с. Но он лезет в 100 мегабитную LAN и на Linux/OpenWRT реализуется проще…

А теперь, дабы убедиться, что любые подсказки ему бесполезны, засекам время и ждем от Гуру nikolz решения его же вопроса… :)
 

nikolz

Well-known member
Дальнейшие разъяснения для Гуру nikolz,
почему все писанные выше сообщения относится именно к тех.ответам на его глупые вопросы, но теперь придется его тыкать носом и раскрывать всем его полную некомпетенцию в области WiFi модулей, которой он занимается уже много лет.

Т.к. для нормальной работы wireshark с WiFi пакетами в win нужен специальный WLAN sniffer адаптер, то выше приведены варианты на чем его возможно построить быстро и за дешево. На ESP8266 и подобных(!) не выйдет, т.к. трафик одного канала 802.11n при HT20 54Мб/с. Но он лезет в 100 мегабитную LAN и на Linux/OpenWRT реализуется проще…

А теперь, дабы убедиться, что любые подсказки ему бесполезны, засекам время и ждем от Гуру nikolz решения его же вопроса… :)
ну и что вы нового написали?
картинку формата я и без вашей подсказки знаю
учебники читал
а WireShark и без ваших подсказок видит пакеты UDP
поэтому из Вас учитель как из слона муравей.
даже время нет надобности засекать.
сказали бы прямо, что Вы не знаете как решить данную задачу.
Более того, за четыре года Вы даже не сообразили что можно не в маяк запихивать данные и потом уродовать софт роутера
а передавать нормальные пакеты UDP
---------------------
Знаете в чем отличие Ваших решений от моих?
Вы лепите всегда нестандартное свое , поэтому оно оригинальное как царь пушка - все восхищаются но мало кто использует
и все работает лишь со старым SDK.
а я использую SDK, ничего нового но можно повторить и все работает с новым SDK.
---------------
Просьба не надо тратить свое драгоценное время и брызгать слюной на экран, рассказывая кому-то обо мне в третьем лице.
Это не делает вас умнее.
 

pvvx

Активный участник сообщества
Третий заход.

Ответьте себе сами:

1. Где вы наблюдаете “сырые UDP” пакеты?
2. Куда вы вставляете “сырые UDP” пакеты?
3. Каким образом Wireshark у вас показывает WiFi "сырые UDP" пакеты без специального оборудования и специфических драйверов к нему со всякими ncap и типа?

Подсказки:

WiFi – это транспортный уровень со своим форматом 802.11 для фреймов и протокола (уровень MAC) и в нем нет “сырых UDP” или TCP и прочих пакетов IP уровня :p

Для отсылки IP пакета (который вы привели выше) требуется его упаковать в указанный мной ранее тип фрейма данных 802.11. До его передачи дополнительно потребуется согласование с AP роутера другими фреймами и по протоколу 802.11. Можно раскидать данные IP пакета (или другого протокола) кусками в разные фреймы данных 802.11 WiFi, т.к. на приемной стороне они соберутся в цельный, в прослойке дров любого стека IP/TCP между MAC и IP уровнем :p

Чтобы Wireshark показывал WiFi пакеты вам потребуется копать темы с WiFi снифферами. На ESP8266/32 ничего хорошего по данному поводу так и нет. Как было всё связанное с дровами WiFi у ESP ‘сикретно’ так и осталось. И у них не хватает производительности внешних интерфейсов для передачи трафика даже для самого простого одиночного канала WiFi на 54Mbit/s, а так-же производительности и буферов для обработки (создания заголовка с тайм-штампом и т.д.) принятых по каналу фреймов 802.11 при перекидывании в другой интерфейс с целью доставить до компа с Wireshark...

Примеры:
C картинками отображения в Wireshark WiFi пакетов: Espressif Wireshark User Guide — ESP-IDF Programming Guide v4.0-dev-1349-g84982ae2e documentation Найдите там “сырой UDP” пакет :)

С описанием, что всё плохо в ESP32 для этого: Создание сниффера на ESP32. Сниффер своими руками

В итоге: Сниффер на ESP не работает и передавать произвольные фреймы 802.11 возможности на ESP нет. И таких выводов и описаний в инете масса… Надеюсь, что вы решите эту тему с ESP, иначе бы тут писать вообще ничего не стал :p

На RTL8195 чипах работает, т.к. их дрова WiFi позволяют отправлять и принимать любые фреймы 802.11 + достаточно памяти для буферизации потока + хватает скорости внешнего интерфейса LAN (а других имеющихся интерфейсов не хватает – проверено и описано на форуме).
 
Сверху Снизу