Arduino.ru

Вернемся к сюрпрайзам ESP.

Есть веб сервак, самая интересная по теме его часть, вызываемая достаточно часто

void ProcessWeb(WiFiClient client)
{
      if (client.available()) 
      {             
        char c = client.read();            
        header += c;
        if (c == '\n') 
        {  
          if (currentLine.length() == 0) 
          {

            client.println("HTTP/1.1 200 OK");
            client.println("Content-type:text/html");
            client.println("Connection: close");
            client.println();

            SendHTML(client);

            client.flush(200);
            client.stop();


         } 
          else 
          {
            currentLine = "";
          }
        } 
        else if (c != '\r') 
        {  
          currentLine += c;  
        }
      }
}


void  ProcessConnected(void)
{
  static WiFiClient client;
  static bool NewClient=true;
  if (client) 
  { 
    if(client.connected())
    {
      if(NewClient)
      {
        NewClient=false;
      }
      ProcessWeb(client);
    }

    if(!client.connected())
    {
     header = "";
     client.stop();
     delay(200);
     while (client.available()) client.read();
     NewClient=true;
    }
  }
  else
  {
   client = server.available(); 
   if (client) 
   { 
     currentLine = ""; 
   }
  }
}

Вторая ф-я конектит клиента, первая принимает и возвращает данные. Я их заметно почистил, чтоб осталось по существу (в частности в запросе иногда команды могут ехать, но не суть, вырезал).

Сам HTML генерится и отсылается в  SendHTML(client);, его много до 200КБ, он динамический т.е. вызвав два раза подряд  SendHTML(client); получим два несколько разных HTML. Все это не позволяет получить и отправить в хедере http значение content-length. Работаем без него. Имеем следующее.

1. При обращении из локальной сети по "http://192.168.0.121" - работаем устойчиво, недели, месяцы. Завалить не выходит. Все браузеры отображают.

2. Для обращения из инета на настроенном сервере LAMP в моей локалке, в видимой папке лежит незамысловатый код

<?php

$ServerGidropon="h t t p://192.168.0.121";

$vpogr = file_get_contents($ServerGidropon);

echo $vpogr


?>

Не, я в курсе, что можно и по другому организовать доступ к ESP. Но мне так нравится, хотяб по соображению безопасности. Все параметры из URL никогда не потревожат ESP. И это тоже стабильно долго работает.

3. Но при попытке чередовать оба способа обращения наблюдается отсутствие ответа. Например, ходили из инета, ок, обратились из локалки, ок, но следующий раз с инета уже не ок. Страница недоступна, на какое то время (или на какое-то число попыток, не распробовал). Потом попустит. Эту фигню видел давно, но списывал на проделки роутера. Однако на другом роутере - тоже самое.

4. С этим вполне можно жить, но... вчера в ситуации из п.3 ESP начала отваливатся от вайфая и виснуть. А это уже совсем плохо.

5. Оперативная разборка показала что п.4 возникает через раз в условия п.3 плюс еще и мало памяти, свободно ОЗУ где то около 20КБ. Оставив больше памяти системе п.4 решился. А п.3 остался.

Кто что думает?

Советчиков в стиле "смини платформу", перейди на MQTT, и пр. - просьба не беспокоить, этот вопрос просто не на ваш уровень компетенции.

По горячим следам попробовал сделать допилинг PHP, как советуют на умных ресурсах.

<?php
function curl_load_($url){
    curl_setopt($ch=curl_init(), CURLOPT_URL, $url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    $response = curl_exec($ch);
    curl_close($ch);
    return $response;
}

function curl_load($url){

$ch = curl_init();

curl_setopt($ch, CURLOPT_AUTOREFERER, TRUE);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, TRUE);  
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 3);     
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
$data = curl_exec($ch);
curl_close($ch);

return $data;
}

$ServerGidropon="h t t p://192.168.0.121";

echo curl_load($ServerGidropon);


?>

Не помогло.

Про Transfer-Encoding: chunked слышал, шото он мне не нравится, чтоб вот так взять и кучу текста поменять чтоб попробовать. В конце концов п.1 и п.2 по отдельности работают.

А что видно на стороне ESP-шки - коннекты фиксируются?

Я некоторое время назад с сопряжением БТ устройства и ESP32 страдал. Так там в секьюрном режиме, если первый коннект неудачен (ESP32 отвергла сопряжение по моему указанию), второй коннект даже не фиксируется в логах IDF. Тайм-аут нужен некоторый для второй попытки.

Это я к тому, что проблема может быть очень глубоко внутри и быть неисправимой.

Chunked выпиливается в PHP легко и незамысловато, если речь о нем.

С коннектами интересно. Иногда, как попустит, то данные выдает, причем судя по времени не свежие данные, а на момент коннекта. Но чаще нет.

//Тайм-аут нужен некоторый для второй попытки.

Какая длительность таймаута?

Я бы на debug-level-е глянул - сокет новый открывается или же нет.

Не. уменя не про 5 сек, там может и пару минут быть.

Клиент в ESP всегда один обрабатывается у меня. Если в это время приходит следующий - он ждет завершения предыдущего, потом тоже обслужится. С этим нормально. Но только один. Там по коду видно стр.63 client = server.available();только если клиент нул стр 41.

//на debug-level-е глянул 

это куда? где?

Ну, там в менюшке IDE в опциях компиляции есть уровни отладки - info, error, verbose и пр.? Для 32-й точно есть такое, для 8266 уже давно ничего не компилировал - подзабыл.

а... есть такой..

Думаю не получится, контроллер в устройстве, на его уарте другой висит.

Пока таймаут померил похоже не менее минуты. Да за 50 сек не восстанавливается.

Дак другой помучать на макете, не? Поведение схожее должно быть. Без выяснения глубины залегания проблемы нет возможности искать workaround.

Я бы ещё без адского куска html-я погонял. Может, все же, дело в памяти - внутре там с буфера в буфер гоняется это все, мож где-то и встаёт раком, пока демон RTOS-а не поубивает процессы ))

хотя не.. бредово как то. Если отправить запрос из инета более чем через минуту после запроса с локалки - работает, отвечает сразу. Если через 50 секунд - не отвечает 20 секунд, потом дает ответ. Похоже коннект не завершен и по завершению ответит, если броузер дождется. Но если произойдет в это время, еще запрос - не ответит никогда, ну минуты две точно. Если оставить в покое, минуты на 3 все ок становится.

Пойду я бахну чего... Если кто чего знает пишите. Пообщаемся. 

Проблема воспроизводима на 100%. Без адского HTML тоже. На втором ESP видел пол года назад. Но списывал на "фичу" роутера. Я бы и тут копать не стал, если бы не зависания в мертвую. Ну с ними ясно. Та ситуация из п.3 создает нагрузку на память, иногда, если повезет и не зависнет, то видно что свободной памяти сильно убыло. Потому запас памяти от зависания спасает. А с остальным - непонятка пока.

Вот, положим, в визнетовской библиотеке по стопу коннект не дропается сразу же, а ремоте посылается FIN. И только если она не ответила, то сокет закрывается принудительно через некоторое время. Может и тут типа этого - ремота подвешивает сокет. Есть ещё вариант посмотреть вайршарком на локальной машине в момент подвисания - ESP вообще чухается или нет, отвечает хотя бы на TCP хендшейк?

ну на ESP winshark не поставиш, ХЗ шо там в TCP.

Это получается на моем серверке надо смотрет. Зависает если через него проходит. 

Тогда стоит начать испытания с порт-маппинга вместо php-proxy.

попробовал несколько разных клиентов в локальной сети - идеально работает в любых комбинациях. Если одновременно приходят - по очереди обслуживаются все. Без таймаутов и сбоев. Ниче не понимаю...

Убери временно лишнее звено - php. Прям с роутера порт прокинь. Потом на серверке порт прокинь. Если все ОК - проблема в связке с php. Может кэширует там что.

Повторил несколько клинтов через внешний ip, через сервак т.е.,  один мобильный, второй конечно на том же провайдере, ну всеж не по локалке напрямую. И тоже все хорошо. Медленней, но без отказов и затыков. ))))  бля...

Ну пожалуй теперь да, проброс портов настраивать пора. Или может еще с кодом PHP поигратся...

Завтра. Утро вечера мудреней, может кто почитает и еще что предложит..

Появились мысли и сегодня  поворошил проблему. Она все та же, но есть важное уточнение. Все выше описаное как "через внешний ip" теперь понимать как обращение сервера в локальной сети. 

Сервер на оранже  Ubuntu 15.04 armv7l Kernel: 3.4.39-02-lobo.

Даже curl  не отрабатывает. Висит ждет с моря погоды.

Т.е. куча устройств в локальной сети, винда, андроид,.. телевизор смарт в конце концов...  все успешно получают с ESP вебстраницу. При обращении в любом порядке, хоть подряд спрашуй, да хоть и одновременно. Хоть вечно. И только один сервер под линуксом... как в том анигдоте, сидит в дальнем углу паба и не может понять чего его называют трахателем овец..

Почему если случается какая-то невероятная ху.та, то она всегда под линуксом? Это лучшая платформа для всей херни, даже самой невероятной. Вот почему.

Помнится мне такое... Есть такая утилитка nc. В одной сборке линупса она коннект после того, как запрос сделан, закрывает, а в другой нужно в CLI аргумент указать для этого. В противном случае ждёт, пока ремота закроет сессию.

нету nc. и телнета тоже. Это Orange Pi. 

;))))))))))) Понаблюдаю. У тебя зависает на 60 секунд. Мучать не буду, но и решение не скажу, ну просто  из вредности. Подсказка: у винды и Линуха РАЗНЫЕ параметры TCP сокетов по умолчанию. Сильно разные. Линух - все-таки больше серверная система.

При окончании работы кода сокет не закрывается сразу, там тайм аут типа, "а вдруг еще что придет?". Далее - уж сам, сорри, но так смешнее.

я даже не очень вредный. Параметр сокета SO_REUSEADDR, а вот как в ПХП установить параметр для file_get_contents() - этого я просто не знаю, искать надо, а мне лень. Найдешь - опубликуй. Можешь даже на стековерфлоу - там таких вопросов куча. ;)))

When setting up TCP connections to sites, curl will keep the old connection around for a while so that if the next transfer is to the same host it can reuse the same connection again and thus save a lot of time. 

----------
Вобщем, чтобы не гадать о том, что внутри этой file_get_contents, наверное проще будет прямо tcp-коннект с php открыть. Записать в сокет, прочитать оттуда... 

Не про то. Здесь линукс не сервер ТСР, он ниче не слушает. Он ТСР клиент. Сервер ESP. 

Пока я тут вздремнул часок, все отдохнуло, я с нуля зашел на ESP с винды - ОК, дальше curl - не ок. С первого же раза. А если с винды сразу не тыкатся, то  и curl ок был бы.

Так что спасиба за сопереживание, но я помню что линукс порт держит минуту. Увы не то.

Пойду еще вздремну, а вы пока думайте ;)

Какая то странность у меня твориться, собрал себе в подпол железку на Wemos D1 mini
http://arduino.ru/forum/programmirovanie/snova-mqtt-1?page=1#comment-570275
Точка доступа ZyXel примерно в 8 метрах от подпола, в котором железка висит, между ними пару стен толстых кирпичных.
Устройство работает несколько часов норм, потом перестает видеть WiFi и соответственно не отправляет данные. Достаю железку из подпола, становиться лучше, опять несколько часов работает норм и перестает. Только когда ESP8266 практически в прямой видимости к роутеру - тогда все стабильно. Поменял на другой МК того же продавца - все аналогично.
С мобильника все хорошо, зона во всем доме, в подполе и на улице даже ловит.

Что это может быть? Бывает ли деградация радиомодуля ESP8266?

Ребут помогает?