Баг в прошивке 0.21.0.0 (?)

[Tamerlan]

Здравствуйте!

Перерыл все темы, баг-трекера не нашел, поэтому решил создать тему, за одно и подтвердить/ опровергнуть мои наблюдения касательно данного модуля (esp-01).

Ситуация следующая:

Прошил последнюю прошивку с данного сайта:
AT+GMR

AT version:0.21.0.0
SDK version:0.9.5

Подключаюсь к точке доступа, команды следующие:
ATE0
AT+CWMODE=1
AT+RST
ATE0
AT+CWJAP="xxx","xxx"
AT+CIPMUX=1
AT+CIPSERVER=1,80

Далее открываю TCP клиент, подключаюсь по присвоенному IP адресу, и начинаю отправлять без остановки произвольный текст, к примеру ("GET / HTTP/1.1"). Терминал принимает текст, как и должен. Но, если ускорить посылку текста быстрым "кликанием" отправки пакета, то соединение разрывается и модуль перезагружается!

После этого, решил проверил тот же сценарий на прошивке 20.09, там этих проблем не наблюдалось.

Скриншоты вложил в пост.

Подскажите это баг, или я что-то делаю не так!

 

[pvvx]

Далее открываю TCP клиент, подключаюсь по присвоенному IP адресу, и начинаю отправлять без остановки произвольный текст, к примеру ("GET / HTTP/1.1"). Терминал принимает текст, как и должен. Но, если ускорить посылку текста быстрым "кликанием" отправки пакета, то соединение разрывается и модуль перезагружается!

Зависит от TCP клиента. Баг есть во всех AT, но с разновидностями При посылке большого куска у espconn, на которой базируется прием-передача TCP у AT, происходит переполнение. Она не умеет говорить по TCP передающему, что приемный буфер заполнен и ещё медленно выводится в UART. По тому следующий пакет идет фиг знает куда и что это вызовет - тоже не известно (в каждой прошивке своё - но итог у них всех один = перезагруз или зависон).
Не рекомендуется что-то на AT прошивке (да и на Iot и NodeMCU тоже), открывающее TCP сокет для для приема, подключать в глобальную сеть инет. Ставьте шлюз или роутер, который будет ограничивать передачу данных в сторону ESP8266

 

[Tamerlan]

Зависит от TCP клиента. Баг есть во всех AT, но с разновидностями При посылке большого куска у espconn, на которой базируется прием-передача TCP у AT, происходит переполнение. Она не умеет говорить по TCP передающему, что приемный буфер заполнен и ещё медленно выводится в UART. По тому следующий пакет идет фиг знает куда и что это вызовет - тоже не известно (в каждой прошивке своё - но итог у них всех один = перезагруз или зависон).
Не рекомендуется что-то на AT прошивке (да и на Iot и NodeMCU тоже), открывающее TCP сокет для для приема, подключать в глобальную сеть инет. Ставьте шлюз или роутер, который будет ограничивать передачу данных в сторону ESP8266

Это очень странно, что с каждой новой прошивкой, не уменьшается количество багов, а увеличивается. Делаю выводы, что при использовании данного модуля в своих проектах, мне придется писать процедуры для мониторинга статуса модуля и авто-настройки в случае перезапуска/ зависания.

 

[JustACat]

Это очень странно

Это не странно - это грустно, но увы - оно именно так

Делаю выводы

Выводы делаете правильные. Без этого никак. Положиться на сам ESP, да еще если серьезное что-то - никак нельзя.

 

[pvvx]

Выводы делаете правильные. Без этого никак. Положиться на сам ESP, да еще если серьезное что-то - никак нельзя.

А выводы простые - все кто пользуется AT или Lua = в пролете. Причина банальная - кто может сам писать на СИ в SDK используя LwIP напрямую, без espconn от Espressif, тот не использует AT или Lua и у них ошибок связанных с приемо-передачей по TCP и прочему нет. Такова жизнь.
И положиться на ESP уже "почти" можно. Осталось малое - найти модули с выведенными ногами питания RTC и поправить управление WDT в "СИ". После этого (выкидывания кучи хлама Espressif, включая espconn в проекте на "СИ") стабильность работы ESP8266 не будет отличаться от аналогичных модулей. Т.е. на "военную приемку" всё равно не потянет, но для бытовухи и части пром.изделий пойдет. А AT-ешники и Lua-шнки так и будут вынуждены мериться с кучей багов...

 

[AlexeyGR]

используя LwIP напрямую

Если напрямую использовать lwip, то можно ли читать все пакеты (monitor mode) или буфер приёма также будет ограничен 128 байтами?
То есть возможно ли написание на lwip сниффера пакетов?

 

[pvvx]

Если напрямую использовать lwip, то можно ли читать все пакеты (monitor mode) или буфер приёма также будет ограничен 128 байтами?
То есть возможно ли написание на lwip сниффера пакетов?

Сниффер WiFi не связан с TCP или UDP. Прием и обработка пакетов от WiFi обрабатывается через буфера LwIP - pbuf. Снифер WiFi - это уровнем ниже.

 

[AlexeyGR]

Прием и обработка пакетов от WiFi обрабатывается через буфера LwIP - pbuf.

Спасибо, если я правильно понял, то размер принятого пакета (лимит) находится в заголовочных файлах lwip?
Или это всё же находится в библиотеках espressif (вопрос в каких(ой))?, тогда какие (по Вашему мнению) функции отвечают за длину буфера?

 

[pvvx]

Спасибо, если я правильно понял, то размер принятого пакета (лимит) находится в заголовочных файлах lwip?
Или это всё же находится в библиотеках espressif (вопрос в каких(ой))?, тогда какие (по Вашему мнению) функции отвечают за длину буфера?

Начните с того, какая длина у передаваемого в эфире пакета WiFi. Далее он принимается и обрабатывается где-то в функциях:

Спойлер: Посмотреть

ieee80211_opcap 3FFE8DE8
ieee80211_parse_action 40106770
ieee80211_ifattach 40257B00
ieee80211_mhz2ieee 40257B50
ieee80211_chan2ieee 40257BA8
ieee80211_ieee2mhz 40257BC8
ieee80211_find_channel 40257C00
ieee80211_find_channel_byieee 40257C28
ieee80211_crypto_attach 40257D7C
ieee80211_crypto_available 40257D80
ieee80211_crypto_setkey 40257D84
ieee80211_crypto_encap 40257D88
ieee80211_crypto_decap 40257DD8
ieee80211_getmgtframe 40257E3C
ieee80211_hostap_attach 402581D4
ieee80211_ht_attach 40258DAC
ieee80211_ht_node_init 40258DFC
ieee80211_ht_node_cleanup 40258E3C
ieee80211_parse_htcap 40258E74
ieee80211_ht_updateparams 40258F4C
ieee80211_setup_htrates 4025905C
ieee80211_setup_basic_htrates 40259130
ieee80211_add_htcap 40259498
ieee80211_add_htcap_vendor 402594B4
ieee80211_add_htinfo 402595D8
ieee80211_add_htinfo_vendor 402595F4
ieee80211_deliver_data 4025981C
ieee80211_decap 40259864
ieee80211_setup_rates 4025996C
ieee80211_alloc_challenge 402599D8
ieee80211_parse_beacon 40259A0C
ieee80211_parse_wpa 40259E78
ieee80211_parse_rsn 40259F90
ieee80211_setup_rateset 4025A08C
ieee80211_output_pbuf 4025A094
ieee80211_send_setup 4025A318
ieee80211_mgmt_output 4025A444
ieee80211_tx_mgt_cb 4025A538
ieee80211_send_nulldata 4025A53C
ieee80211_add_rates 4025A994
ieee80211_add_xrates 4025A9CC
ieee80211_send_probereq 4025AA68
ieee80211_getcapinfo 4025AC14
ieee80211_send_mgmt 4025AC70
ieee80211_alloc_proberesp 4025B1D0
ieee80211_send_proberesp 4025B3C8
ieee80211_beacon_alloc 4025B708
ieee80211_get_11g_ratetable 4025B858
ieee80211_get_ratetable 4025B864
ieee80211_phy_init 4025B87C
ieee80211_phy_type_get 4025B8B0
ieee80211_setup_ratetable 4025B8C0
ieee80211_compute_duration 4025B8F4
ieee80211_dot11Rate_rix 4025B974
ieee80211_psq_init 4025B99C
ieee80211_psq_cleanup 4025B9BC
ieee80211_set_tim 4025B9C4
ieee80211_pwrsave 4025BA04
ieee80211_node_pwrsave 4025BAD4
ieee80211_proto_attach 4025BB0C
ieee80211_set_shortslottime 4025BB34
ieee80211_iserp_rateset 4025BB50
_ieee80211_basicrates 4025BB88
ieee80211_setbasicrates 4025BBE4
ieee80211_addbasicrates 4025BBF8
ieee80211_wme_initparams 4025BC0C
ieee80211_wme_updateparams 4025BC10
ieee80211_mlme_connect_bss 4025BC14
ieee80211_scan_attach 4025BC74
ieee80211_sta_new_state 4025C9BC
ieee80211_parse_wmeparams 4025CF18
ieee80211_send_action_register 4025E984
ieee80211_send_action_unregister 4025E9B8
ieee80211_send_action 4025E9CC
ieee80211_recv_action_register 4025EA30
ieee80211_recv_action_unregister 4025EA64
ieee80211_recv_action 4025EA78

И вообще sniffer работает по другому.
wifi_promiscuous_enable() вызывает wdev_go_sniffer() wdev_exit_sniffer() wDevEnableRx() wDevDisableRx() и меняются фильтры, mak и т.д...
Зачем снифферу собирать пакеты в TCP и прочее, если пакет WiFi несет другую инфу?

 

[AlexeyGR]

Начните с того, какая длина у передаваемого в эфире пакета WiFi.

Длина разная...

где-то в функциях:

 

[AlexeyGR]

И вообще sniffer работает по другому.
wifi_promiscuous_enable() вызывает wdev_go_sniffer() wdev_exit_sniffer() wDevEnableRx() wDevDisableRx()

"Волшебной" константы 0x80 там не найти , почему они закрыли эту инфу?...

и меняются фильтры, mak и т.д...

типы пакетов?

 

[pvvx]

"Волшебной" константы 0x80 там не найти , почему они закрыли эту инфу?...

типы пакетов?

Ну не весь же поток CPU разгребать. Он и не успеет.
И никому тут, кроме вас sniffer из ESP8266 не нужен.
Вот восемь фильтров для маков и в конце каждого его enable:

3ff20c20: 00 00 00 00 00 00 00 00 ff ff ff ff ff ff 00 00 ........яяяяяя..
3ff20c30: 1a fe 34 9f c0 bf 00 00 ff ff ff ff ff ff 01 00 .ю4џАї..яяяяяя..
3ff20c40: ff ff ff ff ff ff 01 00 18 fe 34 9f c0 bf 00 00 яяяяяя...ю4џАї..
3ff20c50: 1a fe 34 9f c0 bf 00 00 ff ff ff ff ff ff 01 00 .ю4џАї..яяяяяя..
3ff20c60: ff ff ff ff ff ff 01 00 20 20 0e 09 04 04 00 00 яяяяяя.. ......

Аналогично и другое задается для приемника WiFi