• Уважаемые посетители сайта esp8266.ru!
    Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
    Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru
  • Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Разработка ‘библиотеки’ малого webсервера на esp8266.

aloika

Active member
Pvvx, подскажите пожалуйста.

Ситуация такая:
Ваша сборка-свалка, SDK 1.5.2. Но проявляется также и на 2.0.0.

При работе AP подключаюсь к ESP8266 телефоном и компьютером, потом отключаюсь и тем и тем, потом снова подключаюсь телефоном. Иногда (не всегда) вместо WEB: init port 80 в логе появляется tcpsrv: not new tcp! . Естественно, web не работает.
(Как будто бы что-то не успевает закрыться, а я открываю новое)

Через некоторое время нормальная работа восстанавливается (иногда нужно переподключиться).

Я вижу в коде фразу эту tcpsrv: not new tcp! . Судя по коду, она тогда появляется, когда не получается выделить память под новый tcp_pcb.

Почему такое происходит? И как с этим бороться?
Если отключить модбас (он мне не нужен) - лучше будет?

И не может это быть оттого, что я поставил esp8266web\app\sdklib\lwip\core\init.c MEMP_NUM_TCP_PCB = 40; ?
 
Последнее редактирование:

pvvx

Активный участник сообщества
При работе AP подключаюсь к ESP8266 телефоном и компьютером, потом отключаюсь и тем и тем, потом снова подключаюсь телефоном. Иногда (не всегда) вместо WEB: init port 80 в логе появляется tcpsrv: not new tcp! .
Это вроде исправлено было тут:
esp8266web/tcp_srv_conn.c at master · pvvx/esp8266web · GitHub
 

aloika

Active member
Да, я вижу, что по сравнению с SDK 1.5.2. там многое изменилось и попытки исправить были, но, к сожалению - проблема присутствует.

Проще всего проблему можно повторить так:

- Подключаем к АР телефон (андроид)
- Подключаем к АР планшет (андроид)
- отключаем телефон
- отключаем планшет
- подключаем телефон - получаем "not new tcp!"
 

pvvx

Активный участник сообщества
Да, я вижу, что по сравнению с SDK 1.5.2. там многое изменилось и попытки исправить были, но, к сожалению - проблема присутствует.

Проще всего проблему можно повторить так:

- Подключаем к АР телефон (андроид)
- Подключаем к АР планшет (андроид)
- отключаем телефон
- отключаем планшет
- подключаем телефон - получаем "not new tcp!"
Я знаю, что там есть проблема. Она просто не решается. Reopen порта тоже не работает - убивать все соединения насмерть при отключении тоже не вариант - возникают другие проблемы - при разрыве и новом подключении комп и другое оборудование сходит с ума, т.к. ESP открывает соединение на тех-же портах, что незаконно без паузы в 120 сек (TIME_WAIT) если произошел разрыв... идут одни реконнекты по TCP, а ESP не врубается, что творит и соединения становятся по байту в час... Управление netif-ами у Espressif в соответствии с состояниями WiFi нет. Рандома тоже нет - это так-же приводит к бешенству всех на линии, если включить ESP и пресбросить - она лезет в тот-же порт по старту к примеру на комп, как ни в чем не бывало :) - итог описан - по байту в час, пока устройства не успокоятся, закрыв разорванное ранее соединение.
Возможно, что ESP не всегда посылает разрыв соединения WiFi - тогда по линии бы проходила команда на переинициализацию всех сопутствующих открытых соединений и связей к данном устройству (таблицы роуты и прочее)...
Кароче, лечить весь этот бардак в ESP нет никакого желания. Пусть Espressif лечит. Просите у них :)

Вообще закрытие портов сделано для экономии питания, чтобы в LwIP не отрабатывали таймеры и прочее, а прошивка вечно сидела на команде в ets_run() пониженного потребления, ожидая только аппаратные прерывания, когда активных соединений у WiFi нет. :) Уберите закрытие по любым событиям WiFi порта Web (80), и он будет пожизненно работать :p Единственное, что нужно перезапускать - это клиентов, лезущих во вне - SNTP или если TCP2UART лезет к внешнему серверу - при новом соединении их надо перезапустить, т.к. может смениться путь и прочее... так-же если IP не фиксирован у staion на внешней AP...
 
Последнее редактирование:

aloika

Active member
Уберите закрытие по любым событиям WiFi порта Web (80), и он будет пожизненно работать :p
Это мне подходит, спасибо за совет.
Вот я так вот поступил:

Код:
void ICACHE_FLASH_ATTR close_all_service(void)
{
#if DEBUGSOO > 1
    os_printf("Close all except WEB (MK):\n");
#endif
    if(flg_open_all_service) {
#ifdef USE_NETBIOS
        netbios_off();
#endif
#ifdef USE_TCP2UART
        tcp2uart_close();
#endif
#ifdef USE_MODBUS
        mdb_tcp_close(); // mdb_tcp_init(0);
#endif
#ifdef USE_WEB
    //    if(syscfg.web_port) webserver_close(syscfg.web_port); // webserver_init(0);
#endif
    //    tcpsrv_close_all();
        flg_open_all_service = false;
    }
}
т.е. закомментировал webserver_close и tcpsrv_close_all.

Ну и вроде работает, как задумывалось.
Но зачем вообще tcpsrv_close_all ? В ней три действия... не до конца мне понятных. Может быть, из них что-то нужно оставить?
 

pvvx

Активный участник сообщества
Не подскажите, что это у вас за приложение для отображения отладки по udp используется и где его взять?
Купить с модулем, но не ESP :) - > [USR-TCP-Test] Testing Software V1.3 | USR IOT
(да, и поаккуратнее там, на данном сайте - в части софта с него неоднократно вылавливал вирусы...)
 
  • Like
Реакции: vad7

vad7

Active member
Я тут один момент обнаружил в вебсервере:
Если пытаешься загрузить на место диска обычный файл размером больше 32кb, то браузер пишет: ERR_CONNECTION_RESET.
memi0x00000000[1400] rec 1400 of 1400 :
srv[80] 192.168.0.220:62989 [1] read: 1400 tst_rx: 200, 1, 32929 rx:32929[1400] recved_bytes=1400
bufi[1400]0, cont:32929 find_bndr len=143,ret=1 name:'file' filename:'1.bin' trim#147
bufi[1253]0, cont:32782 tst,fn='1.bin'(file) ERR1 ret u_b: 200,f108 resp=61706 prh#f10a,200,16 #f10a (83) 302 dis
tcpsrv_server_close (0x3fff0018)
tcpsrv: check 0 tm pcb
srv[80] 192.168.0.220:62989 [1] disconnect
cf254

А если меньше 32к, то как и должно быть disk_er1.htm - Image Corrupt or Wrong Version.

Причем в логах одно и то же в обоих случаях, только добавляется после:
srv[80] 192.168.0.220:63057 [1] listen
memi0x00000000[581] rec 581 of 581 :
srv[80] 192.168.0.220:63057 [1] read: 581 http_ver=11 of1[disk_er1.htm]
 

vad7

Active member
@pvvx, попробовал отладку по UDP.
В момент загрузки вебдиска при включенной отладке, происходит такое, после успешной загрузки около 16к:
memi0x3fff7380[3062] rec 1400 of 3062 :
srv[80] 192.168.0.220:49953 [1] read: 3062 tst_rx: 200, 1, 90862 rx:90862[3062] recved_bytes=1400
bufi[3062]0, cont:90862 fdata ret=0
Write to 0x47000, len=2048, block_size=2048, c_len=90862, sbry= 38, r=0, d=-19144, l=3062trim#2048
bufi[1014]0, cont:88814 fdata ret u_b: 0,7108 no boundary ...
WiFi event(7): Probe Request (MAC:f0:5b:7b:b5:09:dc, RSSI:-93)
WiFi event(7): Probe Request (MAC:00:1e:64:9f:04:9e, RSSI:-59)
srv[80] 192.168.0.220:49953 [1] poll: 0 #4, 5,5
srv[80] 192.168.0.220:49953 [1] poll: 1 #4, 5,5
...
srv[80] 192.168.0.220:49953 [1] poll: 2 #4, 5,5
...
srv[80] 192.168.0.220:49953 [1] poll: 3 #4, 5,5
...
srv[80] 192.168.0.220:49953 [1] poll: 4 #4, 5,5
...
srv[80] 192.168.0.220:49953 [1] poll: 5 #4, 5,5
tcpsrv_server_close (0x3fff02a8)
srv[80] 192.168.0.220:49953 [1] disconnect
Далее:
no buf for action frame

И, наконец:
Fatal exception (29):
epc1=0x4000e1b2, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000

Поймать глюк с помощью udplog не получится. :(
 

vad7

Active member
Иногда, правда, не сразу падает - нет несколько минут коннекта, только потом ексепшн:
state: 5 -> 2 (10c0)
rm 0
WiFi event(1): Disconnect from ssid HOME, reason(16): Ie_in_4way_differs, count 1 (rt=30)
Close all:
WEB: close
state: 2 -> 0 (0)
WiFi event(1): Disconnect from ssid HOME, reason(202): Auth_fail, count 2 (rt=30)
Close all:
WiFi event(7): Probe Request (MAC:00:1e:64:9f:04:9e, RSSI:-60)
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (2)
reconnect
WiFi event(1): Disconnect from ssid HOME, reason(2): Auth_expire, count 3 (rt=30)
scandone
Set reconnect after 30 sec
Close all:
....
New connect ST...
...
Fatal exception (29):
epc1=0x4000e1b2, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000

Иногда еще такая фигня вылазит: srv[80] new listen - low heap size!
 
Последнее редактирование:

vad7

Active member
@pvvx, еще наблюдения за вебсервером:
Скачиваю с модуля всю флеш (4Mbyte):
Если быстро выбрать место на диске - то все ок.

Если долго выбирать (скачка все равно начинается сама), то через несколько секунд соединение рвется:
srv[80] 192.168.0.220:52017 [1] send: rcb 0012ee39..0012f911 #22d8,2776 ....
srv[80] 192.168.0.220:52017 [1] send: rcb 0012f911..001303e9 #22d8,2776 ....
srv[80] 192.168.0.220:52017 [1] send: rcb 001303e9..00130ec1 #22d8,2776 ....
WiFi event(7): Probe Request (MAC:a4:4e:31:50:13:c0, RSSI:-94)
srv[80] 192.168.0.220:52017 [1] send: rcb 00130ec1..00131999 #22d8,2776 ....
srv[80] 192.168.0.220:52017 [1] send: rcb 00131999..00131f0a fr3:0x3fff0768<-0x00131f0a[1]
#22d8,1393 ....
WiFi event(7): Probe Request (MAC:00:1e:64:9f:04:9e, RSSI:-56)
srv[80] 192.168.0.220:52017 [1] poll: 0 #4, 5,5
WiFi event(7): Probe Request (MAC:00:1e:64:9f:04:9e, RSSI:-59)
WiFi event(7): Probe Request (MAC:54:27:1e:c1:35:8b, RSSI:-80)
srv[80] 192.168.0.220:52017 [1] poll: 1 #4, 5,5
WiFi event(7): Probe Request (MAC:54:27:1e:c1:35:8b, RSSI:-81)
srv[80] 192.168.0.220:52017 [1] poll: 2 #4, 5,5
WiFi event(7): Probe Request (MAC:00:1e:64:9f:04:9e, RSSI:-59)
srv[80] 192.168.0.220:52017 [1] poll: 3 #4, 5,5
srv[80] 192.168.0.220:52017 [1] poll: 4 #4, 5,5
srv[80] 192.168.0.220:52017 [1] poll: 5 #4, 5,5
tcpsrv_server_close (0x3fff0020)
srv[80] 192.168.0.220:52017 [1] disconnect
Если включить оверлей udplog - и быстро выбрать место - рвется соединение.
rv[80] 192.168.0.220:52028 [1] send: rcb 001e5dff..001e68d7 #22d8,2776 ....
WiFi event(7): Probe Request (MAC:1c:e6:2b:11:f1:df, RSSI:-87)
srv[80] 192.168.0.220:52028 [1] send: rcb 001e68d7..001e6e48 fr3:0x3fff12b8<-0x001e6e48[1]
#22d8,1393 ....
srv[80] 192.168.0.220:52028 [1] poll: 0 #4, 5,5
WiFi event(7): Probe Request (MAC:00:1e:64:9f:04:9e, RSSI:-56)
WiFi event(7): Probe Request (MAC:00:1e:64:9f:04:9e, RSSI:-60)
srv[80] 192.168.0.220:52028 [1] poll: 1 #4, 5,5
При включенном udplog, если выбирать дольше - Fatal exception (0) здесь:
struct pbuf * pbuf_alloc(pbuf_layer layer, u16_t length, pbuf_type type)
4021160c: d0c112 addi a1, a1, -48
 

pvvx

Активный участник сообщества
@pvvx, еще наблюдения за вебсервером:
Скачиваю с модуля всю флеш (4Mbyte):
Если быстро выбрать место на диске - то все ок.

Если долго выбирать (скачка все равно начинается сама), то через несколько секунд соединение рвется:
А чего ему бы ему не рваться? По умолчанию стоит дисконект по 5 сек тишины от клиента.
---
После этого:
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (2)
из потрохов WiFi драйвера может быть что угодно -> пишите письма в Espressif - они вам ответят: "Спасибо за интерес к продукции Espressif!" и на этом всё :)

Это вообще чудо "no buf for action frame" от драйвера WiFi - вылезает когда он не справляется со своими прямыми обязанностями - передавать пакеты :)
Вместо простого предупреждения и скипания пакета, что льете "через силу" (поток более чем тянет его устаревший HT20 WiFi) он что-то делает некому ненужное... Никаких ограничений для заливки UDP вообще нет, Espressif драйвер WiFi просто накроется после этого соо... У всех других продолжит работать, выводя кол-во скипнутых пакетов :p
Ну умер уже ESP8266, а ESP-32 никуда не годиться. Пытаться писать что-то на них - мазохизм. Будете няньчиться с данными тамогочами всю жизнь... Нуль встроенной отладки в SDK (On/Off) и прочего отладочного ПО к ним, да полная убогость на сегодня. Espressif пишет, в своих доках, что SDK надо от 1 Мег Flash и пользователю выделено всего до 40 к RAM. Куда с такими характеристиками в 2017 году?
 
Последнее редактирование:

vad7

Active member
@pvvx, да это понятно, просто еще как я понял этот веб-сервер вы планируете использовать и дальше в других модулях.
В нем похоже есть какая-то нестабильность.

Вот сейчас откатил tcp_srv_conn.c на лето прошлого года и теперь по крайней мере соединение при скачивании рваться перестало - неважно, быстро ли ты выбираешь место или нет. Так же из-за этого не падает с udplog.
Но вот запись вебдиска во влеш также падает с udplog-ом.

Я уже и очистку блока флеши убрал (оставил только сектора), чтоб поменьше времени на ней зависало...
 

pvvx

Активный участник сообщества
@pvvx, да это понятно, просто еще как я понял этот веб-сервер вы планируете использовать и дальше в других модулях.
В нем похоже есть какая-то нестабильность.

Вот сейчас откатил tcp_srv_conn.c на лето прошлого года и теперь по крайней мере соединение при скачивании рваться перестало - неважно, быстро ли ты выбираешь место или нет. Так же из-за этого не падает с udplog.
Но вот запись вебдиска во влеш также падает с udplog-ом.

Я уже и очистку блока флеши убрал (оставил только сектора), чтоб поменьше времени на ней зависало...
На других модулях ядро работает, а глюков с WiFi нет, т.к. RTOS - процессы разные и приоритеты у них ставятся. Падало при записи в flash на любом SDK, ... при процессе записи надо менять CLK на 80 МГц и пробовать переставлять местами процедуры, размеры блоков, может какие-то сообщения в лог вписать как задержку вместо delay()... В общем маяться с бубном вокруг текущего WiFi драйвера. Падает только при большой скорости потока... И всё заброшено - надоело - обновлений SDK всё равно нет и никакого смысла делать что-то более "демки на вечер" на ESP8266 на сегодня нет. Старая версия на старом SDK работает и имеет одну ошибку - с PullUp вроде (её и пользуйте), а новою, на новых SDK, не сделать. Причина банальная - не работает данный чип с имеющимся WiFi драйвером при требуемых мне условиях - пример: тупой показометр потребления на INA219. Помирает station и дырявят выходной поток, на любом SDK и ПО (хоть Arduino). Нулевая стабильность работы.
Когда задача тупая, типа несколько байт в час или RS-232 до 115200 типа modbus и модуль сидит на твердом питании и один у AP, то вроде как работает. Если к нему что-то подключается (типа стоит в лаб.БП в качестве измерителя) и рядом другие модули с WiFi, особенно если меряет питание другого модуля с WiFi - то полные кранты - и часа стабильной работы в таких условиях не достигнете (при этом испытуемый модуль другого производителя и стоящий те-же 1xx руб, на плавающем питании которое не может показывать ESP8266 сидящий на собственном стабильном(!), работает без данных глюков). Это говорит о том, что ESP8266 не жилец, когда рядом пробегают большие уровни в его диапазоне WiFi (по тем-же проводам хоть GND, что включаются к другому модулю).
 
Последнее редактирование:

vad7

Active member
@pvvx, хорошо, а нам, то что делать, прикладным разработчикам?
Я уже и так кучу времени убил ковыряясь с этими глюками, вместо того, чтобы дальше библиотеку доступа к счетчику дописывать.

Альтернативы то пока нету?
rtl модули на пробу уже заказал, но с ним тоже еще не все гладко и библиотеки вебсервера нету.
 

pvvx

Активный участник сообщества
@pvvx, хорошо, а нам, то что делать, прикладным разработчикам?
Я уже и так кучу времени убил ковыряясь с этими глюками, вместо того, чтобы дальше библиотеку доступа к счетчику дописывать.

Альтернативы то пока нету?
rtl модули на пробу уже заказал, но с ним тоже еще не все гладко и библиотеки вебсервера нету.
Там уже есть HTTPD c websocket - он работает и проблем особых из-за наличия больших ресурсов у него нет. Практически напрямую к нему подключается microSD c web-сервером на 32 Гегобайта. :) 128 и более ещё не пробовал.
 

PostLast

Member
Добрый день! Хочу реализовать реализовать анонс на сервер по UDP с информацией IP и мак модуля при его регистрации в сети. Сейчас, насколько я понимаю IP модуля получается в ip_current_netif()->ip_addr.addr
но функция работает только при получении данных в соответствии с описанием. Как получить IP модуля сразу после регистрации в сети?
 

PostLast

Member
Я ценю ваш юмор Но я в трех соснах заблудился. как выдернуть upcb->offered_ip_addr
Хотя я его и на стороне сервера могу определить;)
 
Последнее редактирование:

pvvx

Активный участник сообщества
Я ценю ваш юмор Но я в трех соснах заблудился. как выдернуть upcb->offered_ip_addr
Хотя я его и на стороне сервера могу определить;)
Там есть стандарный драйвер событий, по нему всё и работает. Событие получения IP и запускает/открывает все сокеты web и т.д... Так что шутки там не было. :(
 
Сверху Снизу