Espeasy: [BUG] [Estabilidade WiFi] Exceção ESP 3/29 quando a camada 2 se desconecta

Parece que tenho o mesmo problema. Às vezes, meu esp perdeu a conexão wi-fi e fica “perdido” do wi-fi por horas. Eu pensei que eles deveriam reiniciar e se reconectar ao wi-fi graças ao watchdog, mas eles não o fazem. Uma inicialização a frio resolve o problema.

A última coisa descrita por @wolverinevn é algo que vi acontecer aqui também.

como discutimos em # 1957, tenho quase certeza de que muitos desses problemas estranhos de WiFi / rede vêm dessa instabilidade da camada 2 ... Já vi todos os tipos de comportamento estranho antes de mudar meu AP para aumentar os tempos ...

como discutimos em # 1957, tenho quase certeza de que muitos desses problemas estranhos de WiFi / rede vêm dessa instabilidade da camada 2 ... Já vi todos os tipos de comportamento estranho antes de mudar meu AP para aumentar os tempos ...

Espero que você encontre a solução. Um dos meus Nodemcu trava e desaparece do roteador por 5 horas até agora sem motivo. Espero que possa se recuperar do cão de guarda, mas nada acontece. Tenho que reiniciá-lo manualmente agora. Muito irritado!

@wolverinevn quando você tiver acesso ao nó novamente vá para ferramentas => avançado e defina o "Limite de falha de conexão" para algo diferente de 0 (sugiro algo entre 50 e 100, dependendo do número de tarefas que você tem). Na verdade, isso não muda o problema, mas aumenta as chances de que o nó seja reinicializado e reconectado significativamente!

a outra solução alternativa seria se você pudesse ajustar alguns parâmetros em seu ponto de acesso, dependendo realmente de qual tipo de AP você tem, se isso puder ser ajustado ...

@clumsy-stefan Devemos definir o padrão no ESPeasy para este nível também?

E talvez devêssemos também exibir esse valor na página sysinfo e torná-lo disponível para regras?

@ TD-er configurá-lo para algum nível por padrão provavelmente não é uma coisa ruim se não estiver muito baixo (pode sempre acontecer que uma conexão falhe).

Ao depurar o problema, pensei em como isso é feito, atualmente cada conexão malsucedida aumenta o contador e sempre que as conexões bem-sucedidas o diminuem. Pensei se seria mais lógico redefini-lo para 0 assim que uma conexão bem-sucedida ocorresse, mas acho que é uma questão um pouco ideológica o que faz mais sentido.

O problema com esse número é que, se você tiver 10 tarefas, cada uma delas com uma contagem de tentativas de 10 e um atraso de reenvio de 100 ms, as reinicializações acontecem muito rapidamente se houver um problema real de comunicação (100 tentativas em cerca de 10 segundos). .

agora, se você tem, por exemplo, sempre 5 comunicações falhando e 1 bem-sucedido, você estará aumentando continuamente as falhas de conexão. se isso acontecer o tempo todo, você reiniciará o nó mais cedo ou mais tarde, embora todos os dados possam ser entregues.

o principal problema que estou vendo é que, de alguma forma, o nó não está percebendo que a conexão na camada 2 realmente acabou e continua a enviar dados (eu acho). além do que percebi esta noite, o que acontece com o syslog (e outras comunicações como NTP etc.) se não houver conexão wi-fi? Isso também parou? isso pode explicar por que meus nós de repente saltam para 100% da CPU quando a camada 2 termina. provavelmente nenhum dado de tarefa é enviado, mas ele tenta se livrar dos pacotes de syslog UDP e não consegue ... apenas um palpite ...

desculpe, texto longo para duas perguntas simples ... em resumo:
nível padrão: sim, eu definiria para o máximo (100) ou então por padrão ... se tudo estiver ok, não faz mal, caso contrário, a unidade fica acessível novamente ...
Página e regras do sysinfo: Eu diria que não, por que isso deveria ser alterado dinamicamente? é uma emergência valores ...

@ desajeitado-stefan Eu já configurei para 50. Vamos esperar. ;)

@wolverinevn hmm ... 50 deve acontecer muito rapidamente, dependendo do número de intervalos de tarefas e novas tentativas que você tem (5-15min.) ... se isso não ajudar, acho que o nó não está realmente congelado, mas pode ' t reconecte-se à rede. Eu também tive isso mesmo após uma reinicialização do WD. você pode ver se o nó tenta ir para o modo AP? você vê o AP-WLAN do nó?

Página e regras do sysinfo: Eu diria que não, por que isso deveria ser alterado dinamicamente? é uma emergência valores ...

Pretendo ser inspecionado em regras usando uma variável de sistema como %conn_fail% e mostrá-la na página sysinfo, ao lado do número de reconexões wi-fi.
Afinal, é um valor de estatísticas de desempenho

Eu pretendia ser inspecionado em regras usando uma variável de sistema como% conn_fail% e mostrá-lo na página sysinfo, próximo ao número de reconexões wifi. Afinal, é um valor de estatísticas de desempenho

ah, sim, concordo, isso faria sentido! isso também está um pouco relacionado ao problema # 1993. Ter um plugin que envia um número de variáveis ​​de sistema / desempenho regularmente para o controlador (sem desperdiçar as tarefas limitadas disponíveis) seria realmente ótimo!

@wolverinevn hmm ... 50 deve acontecer muito rapidamente, dependendo do número de intervalos de tarefas e novas tentativas que você tem (5-15min.) ... se isso não ajudar, acho que o nó não está realmente congelado, mas pode ' t reconecte-se à rede. Eu também tive isso mesmo após uma reinicialização do WD. você pode ver se o nó tenta ir para o modo AP? você vê o AP-WLAN do nó?

Tenho 9 tarefas, 3 delas são Dummy e MQTT_import. Acho que as regras estão um pouco ocupadas com a computação e leitura de sensores. Tentei limitar mqtt_publish chamando as regras a cada poucos minutos. A carga está em torno de 29%.
Pelo que me lembro, da última vez que ele foi congelado esta manhã, não consigo encontrar o AP do Espeasy (se você quer dizer que AP_WLAN está operando em modo AP).
Minha configuração (rede, localização do ESP) estava funcionando bem com outro Nodemcu rodando 2.3 ou 2.4 que foi lançado em março.

_Uptime é 7hrs e 20mins, RSSI é -71dbm, tem alguns wi-fi ao meu redor.
Razão da última desconexão: | (200) Tempo limite de Beacon
Número reconecta: | 35_

@wolverinevn o problema com esse problema é que isso acontece de forma completamente aleatória. Tenho ~ 30 nós em execução, alguns deles enfrentaram o problema alguns deles não, alguns reiniciados, alguns wnt para modo AP ...

Realmente parece ser uma combinação de quão ocupado o nó está, quão ocupado está o ar (por exemplo, número de dispositivos wi-fi) e como seu AP lida com certas condições de forma aguda (falta de acks de camada 2 etc.) ...

então eu acho que até encontrarmos uma maneira dentro do aplicativo (ESPEasy) para detectar essa condição de forma confiável e agir sobre ela, não existe uma solução "real" ....

@wolverinevn PS: você não está usando AP's do mikrotik por acaso?

@wolverinevn Sobre o número de reconexões (em sua edição)
35 reconecta em cerca de 8 horas é muito.
Eu tenho nós aqui em execução há dias que só tenho um punhado de reconexões.
O mais estável está funcionando por 20 dias 11 horas 46 minutos agora e apenas 1 reconectar.

Conectado | 19d22h33m
- | -
Razão da última desconexão | (202) Falha de autenticação
Número reconecta | 1

@wolverinevn PS: você não está usando AP's do mikrotik por acaso?

Não. Estou usando um roteador com firmware Padavan (tipo ASUS).

@ TD-er, eu sabia. Estou inspecionando o motivo, pode ser ruído do módulo Buck nas proximidades. Outro tem 0 reconectar após 2 horas.

Não. Estou usando um roteador com firmware Padavan (tipo ASUS).

Infelizmente eu não conheço este FW ... Alguma chance de ajustar os parâmetros da camada 2? Algo como tempos limite de confirmação de quadros ou semelhante? Algum tipo de configuração de "distância"?

@clumsy-stefan Infelizmente, não vejo nada parecido.

@ clumpsy-stefan A unidade foi reinicializada 2 vezes na noite passada com o limite de 50 falhas definido. A boa notícia é que não há mais congelados. Hoje vou tentar melhorar a conexão wi-fi com algumas pequenas alterações na configuração do hardware.

3 unidades Wemos na mesma sala, conectadas ao mesmo AP.
Reconecta nas últimas 16 horas ou mais,
Com regra: On WiFi # Connected ....

26 reinicializações do WD e 104 reconexões:

9 reinicializações WD e 32 reconexões

2WD reinicializações e 40 reconexões

Todos têm 50 limites de falha definidos

@Domosapiens & @wolverinevn mais uma coisa que você pode tentar é aumentar o group-key-timeout em seu AP (se você tiver essa opção). Normalmente são cerca de 5 minutos. Você pode tentar aumentar para 30min. ou mesmo 1h e ver se melhora (contanto que não seja em uma rede de super alta segurança, o que eu não presumo se você tiver IoT's nela) ...

@ TD-er

O mais estável está funcionando por 20 dias 11 horas 46 minutos agora e apenas 1 reconectar.

Também tenho atualmente unidades que funcionam por mais de 3 dias agora e outras que reiniciam em um dia ...

Eu vi alguns problemas com o rekeeying da chave de grupo. de alguma forma, parece que em versões mais novas do núcleo pode acontecer que a recodificação chegue ao tempo limite ... no entanto, o aplicativo deve agir sobre isso e não entrar em um modo de carga alta não responsivo ... mas eu não certeza de onde está falhando ..

@ desajeitado-stefan obrigado por sua sugestão.
Vejo no meu roteador dd-wrt um parâmetro. "Intervalo de renovação de chave" com valor 3600 (em segundos).
Então está tudo bem?

recodificação chega a um tempo limite

Isso explicaria apenas uma reconexão imho de hora em hora.
Graças ao ótimo recurso de regra _WiFi # Connected_ podemos ver isso.
Não tenho ideia de como as versões mais antigas funcionaram nisso.
Um problema escondido já há muito tempo?

depois de definir minha renovação de chave de grupo de 5min. a 1h as unidades funcionam muito mais estáveis. Suponho que com 40 clientes conectados em um AP fazendo a cada 5min. um rekey apenas deixou o ar um pouco ocupado .. depois disso eu poderia até diminuir o tempo limite de frame-ack novamente e as unidades ficaram mais responsivas novamente, eu também obtive menos "tempos limite de conexão" após alterar esses parâmetros ...

@ TD-er ainda acho que esse "tempo limite de chave de grupo" e a "falha associada" depois precisam ser capturados e tratados pelo aplicativo. Tenho a impressão de que a unidade continua a tentar enviar mensagens enfileiradas ao controlador / servidor enquanto tenta fazer uma recodificação, o que torna a unidade muito lenta e a recodificação falha ... portanto, desconectando na camada 2.

apenas uma ideia grosseira, ainda estou tentando realmente definir, mas foi o mais perto que pude chegar até agora.

@ TD-er jsut agora experimentei novamente um nó que entra em um loop indefinido de tentativas de reconexão e sempre expira (consulte o log abaixo). O interessante é que ele obviamente percebe que não está conectado e não tenta enviar dados para o controlador, o que significa que as "tentativas de conexão com falha" não aumentam mais e, portanto, nunca atinge o limite de conexão com falha.

também a carga mostra sempre 100%, é por isso que eu acho que não consegue reconectar porque é sempre muito lento para realmente fazer o aperto de mão .... sems como uma mordida de rabo para mim ... apenas a memória está diminuindo lentamente (até Presumo que trava por causa de mem) ...

Vou testar com # 2073 e ver se essa situação ocorre novamente ... no entanto, ocorre muito raramente nos dois nós conectados em série, de modo que posso realmente rastrear o que está acontecendo ...

105587 : EVENT: WiFi#Disconnected
3105617 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 129 ms
3131325 : WD   : Uptime 52 ConnectFailures 84 FreeMem 12976
3134621 : EVENT: WiFi#Disconnected
3134652 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 5141 ms
3141487 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3141488 : WIFI : Connecting clumsy_ap2 attempt #53
3142671 : EVENT: WiFi#Disconnected
3142700 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1122 ms
3153443 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3153444 : WIFI : Connecting clumsy_ap2 attempt #54
3153713 : EVENT: WiFi#Disconnected
3153743 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 157 ms
3161324 : WD   : Uptime 53 ConnectFailures 84 FreeMem 12976
3165518 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3165519 : WIFI : Connecting clumsy_ap2 attempt #55
3178542 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3178543 : WIFI : Connecting clumsy_ap2 attempt #56
3179728 : EVENT: WiFi#Disconnected
3179757 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1122 ms
3189704 : SYS  : 31.00,12808.00,100.00,53.00
3189708 : EVENT: sysinfo#rssi=31.00
3189743 : EVENT: sysinfo#mem=12808.00
3189773 : EVENT: sysinfo#load=100.00
3189804 : EVENT: sysinfo#uptime=53.00
3191297 : WD   : Uptime 53 ConnectFailures 84 FreeMem 12800
3191441 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3191442 : WIFI : Connecting clumsy_ap2 attempt #57
3191576 : EVENT: WiFi#Disconnected
3191606 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 125 ms
3200507 : EVENT: Clock#Time=Tue,10:25
3204458 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3204459 : WIFI : Connecting clumsy_ap2 attempt #58
3217493 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3217493 : WIFI : Connecting clumsy_ap2 attempt #59
3218677 : EVENT: WiFi#Disconnected
3218707 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1122 ms
3221325 : WD   : Uptime 54 ConnectFailures 84 FreeMem 12800
3245444 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3245445 : WIFI : Connecting clumsy_ap2 attempt #61
3249673 : SYS  : -80.00,12632.00,100.00,54.00
3249677 : EVENT: sysinfo#rssi=-80.00
3249709 : EVENT: sysinfo#mem=12632.00
3249741 : EVENT: sysinfo#load=100.00
3249772 : EVENT: sysinfo#uptime=54.00
3250620 : EVENT: WiFi#Disconnected
3250650 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 5130 ms
3251307 : WD   : Uptime 54 ConnectFailures 84 FreeMem 12624
3259435 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3259436 : WIFI : Connecting clumsy_ap2 attempt #62
3260490 : EVENT: Clock#Time=Tue,10:26
3260650 : EVENT: WiFi#Disconnected
3260679 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1121 ms
3273521 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3273522 : WIFI : Connecting clumsy_ap2 attempt #63
3273659 : EVENT: WiFi#Disconnected
3273689 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 125 ms
3281281 : WD   : Uptime 55 ConnectFailures 84 FreeMem 12624
3287445 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3287446 : WIFI : Connecting clumsy_ap2 attempt #64

É difícil conectar com rssi - 80

O valor RSSI não é confiável quando o nó ESP não está conectado! mesmo nó tem menos de -70 quando conectado ... em nós de sono profundo eles até mostram o padrão "não conectado" de +31 ao enviar os valores!
e após uma reinicialização, ele funciona sem problemas ... (sem movê-lo ...) se você leu acima, é um problema da camada 2 que pode ser reproduzido quando você ajusta os parâmetros no AP ....

PS: você pode tentar você mesmo! Basta conectar 20-30 nós e diminuir o tempo limite da tecla de grupo para 5min. e o valor do limite de resposta do quadro para algo como 7 ... veja o que acontece!

Eu acho que é o lugar errado para problemas com a camada 2, você deve preencher o problema no núcleo esp8266 ou talvez melhor no projeto sdk nonos
Mas por favor não grite aqui

Isso só acontece com o ESPeasy e não com outros tipos de firmwares que experimentei. Presumo que o nó fique muito ocupado em algum momento e não deixando tempo suficiente para o núcleo fazer a recriação (tudo explicado várias vezes), então fique à vontade para ler as depurações e explicações ...
mas concordo, você não precisa realmente responder ...
PS: @ uzi18 você já teve 30 nós rodando com sucesso ao mesmo tempo?

@ TD-er: em ESPEasyWifi.ino linhas 650 - 669 a correspondência padrão da instrução switch sai do switch e, portanto, tryConnectWiFi() retorna true mesmo que WiFi.status() seja não necessariamente WL_CONNECTED mas pode estar em qualquer outro estado (apenas 2 falsos estados de retorno são verificados ..).

Alterar e retornar true apenas se WiFi.status() realmente retornou WL_CONNECTED resolve pelo menos um dos problemas de desconexão / exceção da camada 2 que estou enfrentando!

O que você acha?
Estou faltando alguma coisa ou por que tryConnectWiFi() deveria retornar quando WiFi.status() não está? WL_CONNECTED`?

@ desajeitado-stefan É bom ver que você ainda está investigando o código WiFi.

https://github.com/letscontrolit/ESPEasy/blob/5ee18ec556c9c58802af29f5fd78593905ef35c1/src/ESPEasyWifi.ino#L604 -L671

A ideia inicial desta função era iniciar a sequência de conexão WiFi.
Talvez sua função tenha mudado um pouco ao longo de todas as mudanças desde então.
Mas você pode estar no caminho certo aqui.
Eu acho que pode ser uma mudança adequada para return true (no final dessa função) apenas se o status retornar está conectado.

Você pode descrever o que parece ser o outro problema da camada 2 que você está enfrentando?

não posso dizer exatamente quando a outra exceção ocorre, mas pelo menos há uma diferença se esta função retorna apenas true quando o status é WL_CONNECTED Eu anexei a depuração antes e depois da mudança. .

antes

156874 : EVENT: WiFi#Disconnected Processing time:74 milliSeconds
156876 : WIFI : Disconnected! Reason: '(0) Unknown' Connected for 2 m 32 s
156877 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_DISCONNECTED
157208 : WIFI : Connecting clumsy_ap2 attempt #0
157212 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_DISCONNECTED
scandone
160069 : Fatal exception 9(LoadStoreAlignmentCause):
epc1=0x40105cd4, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000003, depc=0x00000000

Exception (9):
epc1=0x40105cd4 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000003 depc=0x00000000

depois de

108304 : EVENT: WiFi#Disconnected Processing time:73 milliSeconds
108307 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 2014 ms
108308 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_DISCONNECTED
109217 : WIFI : Connecting clumsy_ap2 attempt #1
109220 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_DISCONNECTED
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt

connected with clumsy_ap2, channel 9
dhcp client start...
112113 : WIFI : Connected! AP: clumsy_ap2 (4C:5E:0C:39:F6:55) Ch: 9 Duration: 2895 ms
112115 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_CONNECTED
ip:10.0.10.117,mask:255.255.0.0,gw:10.0.0.2
113751 : WIFI : DHCP IP: 10.0.10.117 (wemos-mini-17-17) GW: 10.0.0.2 SN: 255.255.0.0   duration: 1636 ms
113765 : EVENT: WiFi#Connected

Hmm .. Acabei de perceber que, depois disso, o status interno (ainda) não corresponde ao status do Arduino ... isso também pode levar a problemas, eu acho ...

@ desajeitado-stefan esse status é porque não podemos retransmitir no status wi-fi do Arduino, é por isso que @ TD-er introduziu o status ESPEasy, mas ok, talvez possamos tentar verificar se todos os status no código estão devidamente verificados.

Pode ser que o status do wifi tenha sido corrigido no núcleo 2.5.0, então talvez nosso próprio status tenha se tornado obsoleto.
Isso seria bom, pois torna o código WiFi bastante complicado e, portanto, sujeito a erros.

Editar:
Estou vendo este erro que você deu:
Fatal exception 9(LoadStoreAlignmentCause):
Uma das correções mais recentes no núcleo 2.5.0 é sobre o construtor de IPAddress , que deve corrigir problemas quando o alinhamento da sequência de bytes fornecida não está alinhado com 32 bits.
Talvez isso seja algo semelhante?

Essa é uma das minhas suposições, que o status ESPEasy nem sempre está sincronizado com o status do Arduino. Especialmente as desconexões temporárias na camada 2 (por exemplo, rekeeyings de WiFi) provavelmente não são realmente tratadas / realizadas.

Outra coisa pode ser o oposto, que o ESPEasy pensa que está desconectado e tenta se reconectar, mas o núcleo ainda está conectado e, portanto, leva a uma exceção. mas não posso provar isso ainda ...

sobre o alinhamento, sim, pode ser, mas também não consigo acertar ...

então a única coisa que tenho certeza é que o código de retorno de tryConnectWiFi() deve corresponder ao status real da conexão ou pelo menos verificar WL_CONNECTED ...

@ TD-er estou um pouco mais preocupado com

connected with clumsy_ap2, channel 9
dhcp client start...
112113 : WIFI : Connected! AP: clumsy_ap2 (4C:5E:0C:39:F6:55) Ch: 9 Duration: 2895 ms
112115 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_CONNECTED

Para mim, as duas últimas linhas indicam que o núcleo ainda não atualizou o status, embora ESPEasy pense que sim ... então pode acabar em alguma condição de corrida aqui ...

depois que isso acontece, às vezes eu começo a ver muito

7989956 : Read settings: ControllerSettings index: 0
7989997 : Read settings: ControllerSettings index: 0
7990130 : Read settings: ControllerSettings index: 0
7990267 : Read settings: ControllerSettings index: 0
7990399 : Read settings: ControllerSettings index: 0
7990531 : Read settings: ControllerSettings index: 0
7990664 : Read settings: ControllerSettings index: 0
7990799 : Read settings: ControllerSettings index: 0
7990938 : Read settings: ControllerSettings index: 0

do qual nunca se recupera ...

um pouco depois ele me diz:

8185850 : ip:169.254.37.119,mask:255.255.0.0,gw:0.0.0.0
Read settings: ControllerSettings index: 0
8185975 : WIFI : DHCP IP: 169.254.37.119 (wemos-mini-18-18) GW: (IP unset) SN: 255.255.0.0
8185990 : EVENT: WiFi#Connected

Não tenho ideia de onde isso vem ... mas depois disso, ele começa a tentar se conectar ao controlador / servidor, o que obviamente falha até esgotar as tentativas (100) e reiniciar ...

EDIT: btw, você pode forçar este comportamento se você chutar o nó do AP manualmente ... às vezes ele apenas se reconecta, às vezes acontece o que está descrito acima ...
EDIT2: às vezes ele trava com a exceção 9 ... então parece ser algum tipo de condição de corrida como exatamente ele se recupera de uma desconexão! minha culpa, teve um addLog() no retorno de chamada de onDisconenct() ...

é mais ou menos sempre a mesma situação. depois que o handshake de 4 vias falha (rekeeying), ele nunca se recupera mais ... não tenho certeza de como forçar uma recuperação disso.

adicionar pelo menos delay(100) em processConnect() e processDisconnect , dando ao núcleo tempo para atualizar o status do WiFi, faz com que os satuses WiFi sincronizem novamente. Isso também faz com que as unidades entrem na situação abaixo com muito menos frequência!

900695 : WIFI : DHCP renew probably failed
900697 : Reset WiFi.
900699 : WIFI : Connecting clumsy_ap2 attempt #0
901713 : EVENT: WiFi#Disconnected
901772 : WIFI : Disconnected! Reason: '(8) Assoc leave' Connected for 14 m 56 s
902326 : WD   : Uptime 15 ConnectFailures 44 FreeMem 20248 WiFiStatus 0
907048 : EVENT: WiFi#Disconnected
907106 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 6172 ms
907786 : WIFI : Connecting clumsy_ap2 attempt #1
911821 : EVENT: WiFi#Disconnected
911879 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 3860 ms
911894 : WIFI : Connecting clumsy_ap2 attempt #2
912793 : EVENT: Clock#Time=Sat,08:29
919974 : EVENT: WiFi#Disconnected
920033 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 7962 ms
920824 : WIFI : Connecting clumsy_ap2 attempt #3
922083 : EVENT: WiFi#Disconnected
922141 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1125 ms
922805 : WIFI : Connecting clumsy_ap2 attempt #4
923138 : EVENT: WiFi#Disconnected
923196 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 133 ms
925831 : WIFI : Connecting clumsy_ap2 attempt #5
931179 : EVENT: WiFi#Disconnected
931238 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 5165 ms
931775 : WIFI : Set WiFi to AP+STA
932701 : EVENT: WiFi#APmodeEnabled
932778 : WIFI : AP Mode ssid will be wemos-mini-17_17 with address 192.168.4.1
932778 : WIFI : Connecting clumsy_ap2 attempt #6
933023 : WD   : Uptime 16 ConnectFailures 44 FreeMem 17856 WiFiStatus 0
934065 : EVENT: WiFi#Disconnected
934122 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1123 ms
935712 : WIFI : Connecting clumsy_ap2 attempt #7
936042 : EVENT: WiFi#Disconnected
936106 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 169 ms
938745 : WIFI : Connecting clumsy_ap2 attempt #8
939079 : EVENT: WiFi#Disconnected
939138 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 131 ms
941778 : WIFI : Connecting clumsy_ap2 attempt #9
947130 : EVENT: WiFi#Disconnected
947189 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 5140 ms
947725 : WIFI : Connecting clumsy_ap2 attempt #10
948976 : EVENT: WiFi#Disconnected
949035 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1121 ms
951805 : WIFI : Connecting clumsy_ap2 attempt #11
952140 : EVENT: WiFi#Disconnected
952199 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 134 ms
955778 : WIFI : Connecting clumsy_ap2 attempt #12
956115 : EVENT: WiFi#Disconnected
956174 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 142 ms
959734 : WIFI : Connecting clumsy_ap2 attempt #13
960064 : EVENT: WiFi#Disconnected
960123 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 129 ms

@ TD-er tryConnectWiFi() está retornando um true ou false caso a conexão tenha sido bem-sucedida ou não ... no entanto, WiFiConnectRelaxed() na verdade nunca verifica isso ...

esta função é de alguma forma anterior ao WiFi baseado em eventos? parece que nunca atinge as 2 últimas linhas nessa função ...

Sim, foi uma espécie de sobra de antes do wi-fi baseado em eventos.
Acho que realmente deveríamos considerar dar uma boa olhada nesse código WiFi novamente, já que ele não é tão estruturado quanto deveria ser.

ok ... Ainda estou depurando o que exatamente acontece devido ao tempo limite do handshake 4way e porque o nó não se reconecta novamente ... mas acho que ainda estou cutucando um pouco no escuro, no entanto, encontrando pequenos pedaços aqui e lá, o que poderia somar ...

um outro pequeno parece estar em WifiCheck() ... lá, a verificação da conectividade da camada 2 só é feita quando o IP não é mais válido (por exemplo, todos os octetos são 0). Isso pode levar à situação de que a camada 2 está des- (ou re-) conectando / handshaking, etc., mas o IP ainda é válido porque ainda não expirou (DHCP). Essa é provavelmente a razão pela qual a "renovação do DCHP provavelmente falhou" só acontece depois de um longo tempo, quando o aluguel realmente acabou ... mas ainda estou verificando isso ...

também há wifiCheck() , WiFiConnected() e connectionCheckHandler() que fazem algum tipo de verificação de conexão e se chamam também resetWiFi() sob certas condições. .especialmente connectionCheckHandler() parece ser chamado apenas quando mqtt_reconnect_count > 10 . Então, o que acontece em um ambiente não MQTT?

PS: Estou apenas documentando minhas descobertas aqui, procurando os problemas de WiFi subjacentes ... Portanto, estou feliz por quaisquer ideias sobre isso, mas não necessariamente o esperado ...

deve haver algum tipo de condição de corrida misteriosa em algum lugar. quando o AP inicia um reauth ou rekeeying, às vezes o nó / núcleo não obtém tempo de cpu suficiente para concluir o handshake ou é interrompido ao fazer isso, especialmente em nós com sinal baixo (e, portanto, o handshake leva muito mais tempo). . (ver abaixo).

esses rekeesings / reauths parecem gerar um evento de desconexão pelo núcleo, mesmo que o núcleo faça uma renegociação automática ou reconecte (pelo que entendi). mas então parece que este processo de handshake é interrompido pela máquina de estado ESPEasy quando uma reconexão manual é acionada ... este processo se repete e nunca termina (ou em alguns casos gera wdt's).

` 810114 : EVENT: WiFi#Disconnected 810146 : WIFI : Disconnected! Reason: '(16) Group key update timeout' Connected for 13 m 16 s 810977 : WIFI : Connecting clumsy_ap2 attempt #0 811081 : WIFI : Connection lost to: clumsy_ap2 813089 : EVENT: WiFi#Disconnected 813120 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 2011 ms 814977 : EVENT: Clock#Time=Thu,08:55 821529 : WD : Uptime 14 ConnectFailures 0 FreeMem 22000 WiFiStatus 0 831976 : WIFI : Connecting clumsy_ap2 attempt #1 832079 : WIFI : Connection lost to: clumsy_ap2 836831 : EVENT: WiFi#Disconnected 836863 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 4753 ms

Então, talvez devêssemos usar os eventos de wi-fi apenas para monitorar o processo, e não agirmos nós mesmos?
Alterar isso tornará as compilações 2.3.0 e talvez 2.4.0 inutilizáveis.

Não, eu não faria isso ... No meu ramo já fiz algumas alterações (não tão intrusivas) que parecem fazer com que esses casos ocorram com menos frequência ...

acabei de encontrar outra coisa pequena: em tryConnectWiFi() o cheque de WiFi.status() para o final depois que a chamada WiFi.begin() começa a retornar WL_DISCONNECTED . De acordo com a documentação, isso significa "se o módulo não estiver configurado no modo de estação". tentando descobrir por que isso acontece ou se realmente ajuda colocar o esp explicitamente no modo AP antes de chamar WiFi.begin()

Portanto, ainda espero encontrar a "real" questão subjacente por que essas paradas acontecem ... Se sim (dedos cruzados), eu sugiro que eu faça uma RP com todas as mudanças para você (e outros) revisar ....

Saiba que também vi muitas e muitas situações em que o estado de WiFi.status() não estava correto.
Então, talvez as bibliotecas centrais agora tenham correções e muito provavelmente eu também estraguei em algum lugar todas as tentativas de fazer o WiFi se comportar de maneira estável.
Essa depuração foi muito difícil de fazer, já que não consigo reproduzir esses problemas sozinho e tive que agir em relatórios de outros usuários.
Ultimamente eu tenho um módulo que também está se comportando mal em relação ao WiFi, então é meu módulo de teste de WiFi favorito. Mas também pode ser uma indicação de que o problema ficará pior quando algumas peças estiverem quase fora das especificações. Por exemplo, fonte de alimentação ou capacitores de desacoplamento ausentes, (também) traços de PCB finos, menos blindagem, etc.

claro, não que eu esteja descartando questões de HW. Mas eu tenho ~ 40 nós em execução, com todos os tipos diferentes de fontes de alimentação, placas, marcas diferentes, etc ... e em algum ponto no tempo a maioria deles enfrenta problemas de conectividade ... especialmente aqueles com cobertura wi-fi fraca ou muitos GPIO está em uso ..

E atualmente eu tenho um pouco de tempo para fazer alguma depuração e ainda acho isso muito interessante e desafiador;) Agora eu até começo a entender como funciona toda a sequência de conexão, verificação, desconexão e assim por diante;)

Então, se estiver tudo bem para você, continuarei me aprofundando nessas questões de conectividade ... você é o chefe ...

Continue cavando :)
Eu realmente quero me livrar de todos aqueles problemas de desconexão que são quase impossíveis de reproduzir.
Eles já demoraram muito agora e seria ótimo se eles fossem corrigidos.

Estou tendo cerca de 4 a 24 horas de tempo de atividade seguidas por 2 a 10 horas de tempo de inatividade em média.
Durante o tempo de inatividade, o nó continua a funcionar, mas não há conexão wi-fi.

O ponto de acesso (MikroTik) mostra:

18:16:15 wireless,info 80:xx:xx:xx:xx:xx<strong i="8">@iotnet</strong>: connected, signal strength -62 
18:16:20 wireless,info 80:xx:xx:xx:xx:xx<strong i="9">@iotnet</strong>: disconnected, unicast key exchange timeout 
18:17:31 wireless,info 80:xx:xx:xx:xx:xx<strong i="10">@iotnet</strong>: connected, signal strength -60 
18:17:36 wireless,info 80:xx:xx:xx:xx:xx<strong i="11">@iotnet</strong>: disconnected, unicast key exchange timeout 

ESP Easy | Informações
----- | ----- |
Build: ⋄ | 20103 - Mega |
Bibliotecas: ⋄ | ESP82xx Core 2_4_2, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3 suporte PUYA |
Versão GIT: ⋄ | mega-20190110 |
Plugins: ⋄ | 7 [Normal] [Sonoff POW R1 / R2] |
Tempo de compilação: ⋄ | 10 de janeiro de 2019 03: 21: 19 |
Nome de arquivo binário: ⋄ | ESP_Easy_mega-20190110_hard_SONOFF_POW_4M.bin |

Este não era o problema na versão anterior (quando eu ainda podia usar o canal 14 e ter minha rede SSID oculta).

Você tem o canal WiFi fixo ou é variável?
Estive lendo na página de solução de problemas da Tasmota e eles recomendam fortemente que o canal WiFi seja consertado.
Se o canal 14 não for utilizável, algo relacionado às configurações regionais pode ter mudado em algum lugar, uma vez que apenas os canais 1-11 são permitidos em todos os países.
Além disso, os canais 1, 6 e 11 são, na verdade, os únicos canais utilizáveis ​​sem interferência de outros canais.

apenas os canais 1-10 funcionam, não 11. Veja isto: https://github.com/letscontrolit/ESPEasy/issues/1337#issuecomment -394118989

O canal Wifi é fixo, é claro.

Qualquer canal pode ter interferência de outros canais, não há como controlá-lo. Inferno, pode até haver interferência do mesmo canal.

btw, em relação ao problema que estou enfrentando - o LED de status do wifi (GPIO13 inverso) é normalmente azul sólido, mas quando o dispositivo está offline, ele vai no padrão 0,0,0,0,0,1,2,3, 4,5,6,7,8,9,0,0,0,0,0,0,0,0,0,1,2,3,4,5,6,7,8,9,0,0, 0,0,0, ... de brilho.

IP e DCS fixos, mas os canais nunca mudaram no passado.

Von: Gijs Noorlander [mailto: [email protected]]
Gesendet: Freitag, 11. Januar 2019 21:47
An: letscontrolit / ESPEasy
Cc: inscrito
Betreff: Re: [letscontrolit / ESPEasy] [BUG] [Estabilidade WiFi] Exceção ESP 3/29 quando a camada 2 se desconecta (# 1987)

Você tem o canal WiFi fixo ou é variável?
Estive lendo na página de solução de problemas da Tasmota e eles recomendam fortemente que o canal WiFi seja consertado.
Se o canal 14 não for utilizável, algo relacionado às configurações regionais pode ter mudado em algum lugar, uma vez que apenas os canais 1-11 são permitidos em todos os países.
Além disso, os canais 1, 6 e 11 são, na verdade, os únicos canais utilizáveis ​​sem interferência de outros canais.
-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/letscontrolit/ESPEasy/issues/1987#issuecomment-453651579 ou mudo https://github.com/notifications/unsubscribe-auth/AomgSxPjVKWrp0MSQTtbESKxFqaPVt90ks4vPg thegax https://github.com/notifications/beacon/AomgS_fhHQnmg1AdpX11mVL9yNra8S_kks5vCPgxgaJpZM4YDivP.gif

Coisas do Mikrotik dão grande poder, mas mesmo as configurações padrão para wifi não estão certas.

• Certifique-se de não ter nas configurações de segurança tkip e habilitar apenas a criptografia aes ccm
• Insira uma atualização de grupo chave como 30 min ou 1 hora
• em canais tem largura de canal de 20Mhz e na opinião dich banda B e vá só para G / N
• Canal de extensão desativado
• Apenas desabilitar PMKID (recomendado se você está histérico sobre segurança) parece deixar o Esp veeeery infeliz
• Adicione seu país às configurações de wi-fi (ou veja qual é a sua potência máxima para o AP que você tem e diminua a potência de transmissão em 3). Isso muitas vezes aumenta o desempenho do wi-fi (contra-intuitivo, eu sei)

Geralmente não tenho desconexões (exceto quando eu tinha esse PMKID)

De qualquer forma, seria útil postar suas configurações de AP :-)

Essas são boas dicas. No entanto, sou bastante versado em redes e ainda mais experiente em mikrotik e configurei tudo como você diz exceto chave de grupo.

A atualização da chave de grupo tem a ver apenas com a chave de grupo, não com a chave unicast onde está o problema, mas eu rebaixei essa configuração para os propósitos do experimento.

@ 0ki Cool não sabia que você era um especialista em RouterOS!

Concluí que é claramente um bug no software ESPEasy. Você pode ver o comportamento problemático à direita que corresponde ao RouterOS desconectando o cliente com comportamento inadequado à esquerda. O espectro de rádio é claro como você vê.

Infelizmente, não tenho tempo para mergulhar na base de código ESPEasy agora, mas acredito que esta comparação entre comunicação ruim e boa será útil.
Legenda: __red - ponto de acesso | azul - espeasy | verde - outro dispositivo na minha rede iot__

Eu acredito que ESP_easy por algum motivo decide mudar para o modo AP depois de receber uma resposta assoc (quadro 380 à esquerda) e não continuar o handshake de quatro vias. Observe a mudança de endereço macespeasy também - o primeiro octeto muda de 80 para 82.

@ 0ki

Concluí que é claramente um bug no software ESPEasy.

Eu também, mas não tenho ideia de onde o bug deveria estar.
Parece que o estado interno do ESPeasy em relação ao estado desconectado não está em sincronia com o estado verdadeiro.
É muito possível que eu tenha cometido algum erro ao escrever esse código ou seja um bug nas bibliotecas principais.

Qual arquivo você quer dizer especificamente com "aquele código"? Se você apontar para um ou dois arquivos, posso dar uma olhada nele.

Caso contrário - como agora você vê o momento exato em que isso acontece, espero que possa dar uma olhada mais de perto.

Como também estou investigando esse problema (há cerca de 2 meses), não tenho mais certeza se é o próprio código ESPEasy. mais uma interação entre o ESPEasy e o núcleo / biblioteca WiFi ... Meus debugs / logs mostram que a "Desconexão" sempre acontece após uma troca / rekeeying de chave de grupo. MAS o retorno de chamada só é chamado após o tempo limite de recodificação e, posteriormente, após a falha de autenticação ... Então, atualmente, meu palpite é que ESPEasy não deixa tempo de cpu suficiente para o núcleo realmente fazer o recheio ... até agora eu não não encontre uma maneira de descobrir quando o nó está neste nó de rekeeying ou no modo reauth e, portanto, sendo capaz de adicionar delay() chamadas suficientes para que o reauth rekeeying seja bem-sucedido ...

Para ajudar a identificar o problema da mesma forma - estava funcionando bem com:

Build   20100 - Mega (core 2_3_0)
GIT version mega-20180224
Plugins 48 [Normal]
Build Md5   719b94a4d6bc257b86916e4989eed3a0
Md5 check   passed.
Build time  Feb 24 2018 03:03:12

E por ok quero dizer que não só não houve desconexão, mas também que conectar ao AP oculto no canal 14 não foi um problema.

@ desajeitado-stefan, eu apoio totalmente a detecção do problema que causa a desconexão em primeiro lugar, mas honestamente, pode haver uma série de razões pelas quais uma associação wi-fi pode cair, é claro que uma troca de chave de grupo não deve ser uma das eles.

O problema mais urgente é - por que ele não pode se reconectar depois de desconectado. Não pode ser um problema de tempo, já que estou dando espeasy impressionantes 5000ms para responder com a mensagem 2 do 4way HS.

Eu acho que o problema é que você só consegue se desconectar APÓS a falha da troca de chaves ... então você nunca, quando a troca realmente começa, é aí que você precisa dar mais tempo ao núcleo ...

nos logs você pode ver que ESPEasy pensa por algum tempo que ainda está conectado, mesmo se não estiver (até mesmo um ping para o nó falha), mas o nó ainda tenta enviar dados (e obviamente a conexão falha então) ...

a segunda questão que concordo totalmente é, mesmo se houver uma desconexão, por que não pode se reconectar com uma sequência de conexão completamente nova ... provavelmente o módulo ou núcleo está preso em algum estado estranho?

EDIT: PS: o 4way HS nem sempre falha, (eu faço isso a cada 10min.), Então parece ser uma combinação do estado / ocupação do ESPEasy e o tempo em que o HS acontece.

O que posso fazer é tentar desligar completamente o WiFi (desligar o modem também) e iniciar uma nova reconexão completa quando uma desconexão inesperada está acontecendo.
Não tenho certeza se estava neste tópico, mas em um desses problemas, alguém respondeu com um tweet de alguém da Shelly, que mencionou que precisava reiniciar a pilha wi-fi completamente após desconectar.

@ TD-er é também o que coloquei na minha versão mais recente. dentro de processDisconnect() adicionei um setWifiMode(WIFI_OFF); não tenho certeza, se isso for suficiente ... atualmente está sendo executado em alguns nós de teste (desde cerca de 1h) ...

@ TD-er, essa é uma ideia legal. empurre um git release e eu irei mostrar minhas coisas!

Acabei de começar a ler parte da base de código há 5 minutos, então isso pode ser irrelevante, mas: Certifique-se também de que wifi_connect_attempt esteja definido como 0 nesse ponto.

hmm ... adicionar alguns delay(0) em backgroundtasks() após cada uma das chamadas de sub-rotina, parece estabilizar ainda mais o primeiro problema um pouco (4way-HS). Não tenho certeza se é uma coincidência difícil ...
@ TD-er poderia ser, que backgroundtasks() está bloqueando a execução em algum momento?

de modo geral: adicionar delay(0) em todos os tipos de lugares diferentes onde as estatísticas de tempo mostram longos tempos de processamento parece melhorar muito o manuseio do 4way-HS. Eu tenho mais watchdogs de SW / HW em ação agora do que problemas de rekeeying (mas ainda tenho alguns) ... sintomaticamente, então eu diria que está realmente relacionado ao núcleo / wi-fi não ter ciclos suficientes para realmente fazer (bastante rápido) coisas como rekeeying e a AP então cansada de esperar uma resposta ...

O que também vejo é que às vezes client.connect() ou sendData() podem levar muito tempo (até 2 segundos). Em alguma documentação, descobri que se algo levar mais de 50 ms, você deve chamar delay(0) meio .... mas você não pode dividir essas chamadas, pois são realizadas pela biblioteca ...

Há também outro retorno de chamada onStationModeAuthModeChanged no núcleo. Provavelmente valeria a pena dar uma olhada, já que esse provavelmente é disparado antes que a desconexão real aconteça. mas é muito pouco documentado ... Alguém tem experiência com isso?

EDITAR: parece ser uma coincidência / condição de corrida com algumas outras coisas sendo feitas no momento em que o AP solicita uma recodificação ... mas novamente apenas observações ...

Não sei com que freqüência essas solicitações enviadas pelo AP são retransmitidas.
Normalmente, o sinal de beacon do AP é enviado a cada 102,4 ms. Se algumas tarefas exigirem mais do que isso, o ESP perde um desses quadros de beacon. Portanto, não tenho certeza de como isso é ruim.
Eu sei que às vezes as solicitações ARP são perdidas, o que leva a problemas que um switch não sabe mais como rotear pacotes para aquele endereço MAC e, portanto, torna o ESP inacessível, embora ele mesmo possa enviar dados.

faltar quadros de farol não é nada. ele nem mesmo deve precisar de frames de beacon, já que deve estar ativamente sondando minha rede oculta de qualquer maneira.

Não sou especialista em wi-fi.
Pelo que entendi, o intervalo do beacon é o único momento - um tanto - garantido que o ESP está tentando escutar o WiFi e, entre eles, tentará dormir o máximo possível.

E, pelo que entendi, a única diferença entre redes 'ocultas' e redes 'não ocultas' é que o SSID não está sendo transmitido. Então, na verdade, ele está se conectando apenas com base em BSSID (endereço MAC do AP).
É também o que o ESP faz ao se conectar a redes WiFi (não ocultas), com a única diferença de que fará uma varredura antes e tentará encontrar um BSSID que tenha um SSID que corresponda ao fornecido.
Ao realizar uma reconexão automática, ele tentará a última combinação de canais BSSID + conhecida primeiro, sem realizar uma varredura. Em outras palavras, ele só difere ao fazer uma conexão.

Pelo que sei, enquanto houver uma conexão a uma rede, ele também ouvirá os quadros de beacon.

Não sou especialista em wi-fi.
Pelo que entendi, o intervalo do beacon é o único momento - um tanto - garantido que o ESP está tentando escutar o WiFi e, entre eles, tentará dormir o máximo possível.

E, pelo que entendi, a única diferença entre redes 'ocultas' e redes 'não ocultas' ..........

Oh, isso me lembra algo que pode ser muito importante. Eu executo meus ESPs em um SSID oculto
A propósito, ainda não desconectei ou reinicializou em meus nós (tentando atualizações de chave de grupo de 5 minutos)

Um dos meus nós foi reiniciado em 5 de dezembro devido a uma queda de energia.

Este é daquele:

Unidade: | 5
- | -
Hora local: | 15/01/2019 23:27:32
Tempo de atividade: | 41 dias 12 horas 46 minutos
Carregar: | 15,80% (LC = 9135)
Mem grátis: | 12160 (5360 - sendContentBlocking)
Pilha grátis: | 3552 (1520 - SensorSendTask)
Bota: | Inicialização a frio (0)
Motivo da reinicialização: | Sistema Externo
Rede ❔
Wifi: | 802.11N (RSSI -67 dB)
Configuração de IP: | DHCP
IP / sub-rede: | 192.168.1.89 / 255.255.255.0
GW: | 192.168.1.1
IP do cliente: | 192.168.1.67
DNS: | 192.168.1.1 / 0.0.0.0
Faixa de IP permitida: | Todos permitidos
STA MAC: | 5C: CF: 7F: B1: 3F: 12
AP MAC: | 5E: CF: 7F: B1: 3F: 12
SSID: | Lurch4 (34: 31: C4: B1: 8D: C7)
Canal: | 11
Conectado: | 20h04m
Razão da última desconexão: | (202) Falha de autenticação
Número reconecta: | 61
Firmware
Construir: ⋄ | 20102 - Mega
Bibliotecas: ⋄ | ESP82xx Core 2_4_2, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3 suporte PUYA
Versão GIT: ⋄ | mega-20181109
Plugins: ⋄ | 46 [Normal]
Build Md5: | 47f19d99d0c3f083314b45668b1f5c
Verificação Md5: | passado.
Tempo de construção: ⋄ | 9 de novembro de 2018 03:23:22
Nome de arquivo binário: ⋄ | ESP_Easy_mega-20181109_normal_ESP8266_4096.bin

Como você pode ver, em média, mais de uma desconexão por dia. Ele está conectado a um AVM Fritzbox 1750E

Acho que os frames do beacon não são tão críticos ... Ainda não estou claro porque, após uma desconexão, a sequência normal de WiFi.begin() sempre falha com '(2) Auth expire' .

A única indicação é que a carga da CPU neste ponto sempre mostra 100% e indica que o núcleo simplesmente não tem tempo suficiente para fazer o handshake ...

Meu palpite é que há algo errado nas bibliotecas principais (LWIP ou Arduino ou ESP) e devemos redefinir o wi-fi.
Portanto, desligue o wi-fi e comece tudo de novo. Também pode esperar entre essas etapas para garantir que os buffers sejam esvaziados ou, pelo menos, liberados e as solicitações pendentes sejam ativamente canceladas.

@ TD-er você pode empurrar essa mudança, para que eu possa ver se funciona?

A mudança discutida nos últimos 2 posts?
Ainda não foi implementado, mas posso tentar codificá-lo esta noite e fazer um teste de compilação.

Sim, reiniciando o wi-fi.

@ TD-er escreveu:

Portanto, desligue o wi-fi e comece tudo de novo. Também pode esperar entre essas etapas para garantir que os buffers sejam esvaziados ou, pelo menos, liberados e as solicitações pendentes sejam ativamente canceladas.

Não tenho certeza sobre a descarga ... já que removi todas as chamadas de client.flush() antes de client.stop() . Também parecia que a desconexão acontece com menos frequência. Ao ler alguma documentação, vi que o flush esvazia todos os buffers de entrada (tcp), então, teoricamente, pode acontecer que as respostas se percam ...

Apenas adicionando meu 2c, eu tenho alguns APs Mikrotik, com alguns sonoffs rodando espurna e alguns NodeMCUs rodando ESPEasy. Tive que adicionar um AP extra para os dispositivos ESP, porque durante um período de alto tráfego na minha rede, como backups, eu perderia meus dispositivos ESP. Acho que essa foi a intensidade do sinal WiFi e o tráfego relacionado. Depois que o AP extra foi adicionado, não me lembro de ter visto esse problema novamente.

Mas meus dispositivos NodeMCUs e ESPEasy têm algumas desconexões. Vou configurar um monitor de ping netdata para dispositivos e ver se consigo descobrir quando, como e por que isso pode estar acontecendo e ver se dou alguma informação de volta.

Outra observação, não tenho mais de 40 dispositivos como @ clumsy-stefan, apenas cerca de 5 usuários e seus dispositivos móveis e um dispositivo inteligente estranho como TV, mas pode ser que o dispositivo Mikrotik esteja sobrecarregado ou a rede WiFi RF saturada ?

Eu gostaria de ter uma maneira de ver a quantidade de ruído RF. Tenho um aplicativo (WiFi Analyzer) que me mostra o número de APs e como eles se espalham dos canais WiFi. Usei essa ferramenta para definir meus canais WiFi para diferentes APs WiFi.

Mas realmente não posso dizer se pode haver outra interferência de RF.

Quanto à ideia de dispositivo Mikrotik sobrecarregado, estou usando MikroTik 951UI-2HND como meu roteador principal e MikroTik RB9412nD hAP lite como meu ESP AP.

Eu me pergunto se essa informação é útil de alguma forma?

@LeeNX, obrigado pelas dicas. meus nós são distribuídos em 3 APs e o RF é um tanto equilibrado (máx. 20 clientes por AP ou mais), de modo que haja o mínimo de interferência possível (é claro que não pode haver nenhuma ...). Então, eu não acho que os MTs estão sobrecarregados (eu trabalho em uma empresa que fornece conectividade de backbone de rede e WLAN para eventos profissionais, etc., então tenho alguns testes aprofundados da infraestrutura), mas concordo que o tempo de transmissão sobrecarregado pode ser um problema ... no entanto, mesmo que seja, um nó nunca consegue se reconectar por> 250 vezes após uma desconexão e depois de reiniciá-lo ele se reconecta imediatamente, acho que não pode ser um problema de tempo de antena ... além disso, eu não não vejo isso em qualquer outro dispositivo ...
então eu ainda acho que é alguma coincidência ou condição de corrida entre o estado do chip wi-fi interno, a quantidade de tempo de CPU que o núcleo wi-fi obtém e quais outras tarefas estão sendo executadas na parte ESPEasy ...

@ desajeitado-stefan Concordo com seus insights. Eu só queria ressaltar que usando o pequeno AP Mikrotik com mais de 40 nós, poderia ter sido um Mikrotik CPU ou RAM limitada, mas esse não parece ser o problema.

Estou me perguntando se dpeloying um dispositivo ESP32 e NodeMCU com nada além do núcleo ESPEasy básico e deixá-lo funcionar, para que pudéssemos testar ESP CPU e nenhuma outra influência de plugin. Veja o que posso implantar e teste de ping netdata.

Se isso nos fornecer alguma informação útil, farei um relatório.

Obrigado rapazes!!!

Eu tenho um nó aqui rodando quase nada (IR RX / TX) e está rodando há semanas sem problemas.
O outro nó que tem um tempo de atividade de mais de 40 dias está executando Domoticz MQTT e BME280 + MH-Z19 CO2.
Portanto, provavelmente também dependerá de qual plug-in está sendo executado e com que freqüência e talvez também se o intervalo de leitura sempre coincide com o intervalo de leitura de outros plug-ins.

Já defini algumas chamadas de função periódicas (10 / seg, 1 / seg e 30 seg) com um deslocamento inicial no agendador para que continuem executando o máximo possível em diferentes chamadas de loop.

Talvez eu deva também adicionar algum evento controlado por temporizador de interrupção como o Tasker faz (ou simplesmente usar o tasker em vez do agendador que escrevi) e definir uma tarefa em intervalo de 10 ms para executar o atraso (0).
A única coisa é que ele pode interromper outras transferências GPIO e, assim, perturbar as leituras do sensor.

isso provavelmente resolveria o problema do 4way-HS, mas acho que não o problema de reconexão ... ainda é o mais estranho ... Acabei de ter meu nó de teste falhando novamente por 12 horas tentando reconectar por> 300 vezes ao AP sem sucesso. depois de reiniciá-lo (soft-), ele se reconectou instantaneamente (reiniciar + reconectar levou cerca de 5 segundos ou mais) ...

Acabei de encontrar este problema que parece bastante relacionado ao que estamos vendo aqui:
https://github.com/esp8266/Arduino/issues/5527

parece semelhante, sim ... mas desligar o wifi não parece mudar isso (tentei isso), atualmente estou tentando com WiFi.setOutputPower(0) antes de ligar para WiFi.begin() como sugerido aqui
https://github.com/esp8266/Arduino/issues/2235
e aqui
https://github.com/esp8266/Arduino/issues/2186#issuecomment -233853152
ainda esperando que isso aconteça agora difícil ...

é semelhante, mas não é o mesmo. De fato, no nosso caso reiniciar o AP resolve o problema, no problema postado por Gijs, reiniciar o AP não resolve o problema.

@ giig1967g reiniciar o AP não resolve para mim! apenas reiniciar o nó faz com que ele se reconecte novamente (embora no meu ambiente) ...

@ giig1967g No problema mencionado por @ clumsy-stefan esta reinicialização do AP também é mencionada: https://github.com/esp8266/Arduino/issues/2235#issuecomment -248851270

Portanto, parece que temos vários problemas em mãos.

@ desajeitado-stefan
Ah ok. E no meu caso só com Mikrotik ... :(
@ TD-er
talvez você deva perguntar qual marca / modelo AP eles estão usando ...

@ giig1967g Também tive alguns nós aqui inacessíveis, mas o intervalo desses eventos foi muito mais do que 10 dias, por isso é um pouco difícil dizer se está relacionado a algum desses problemas.
Cerca de metade dos meus nós agora estão conectados a um Mikrotik e a outra metade está conectada ao Fritzbox 1750E

@ giig1967g Eu também só tenho MT's ... e parece acontecer com mais frequência nos nós com sinal mais fraco e nós com GPIOs em uso (especificamente PCF's) ...

Eu gostaria de ter uma maneira de ver a quantidade de ruído RF. Tenho um aplicativo (WiFi Analyzer) que me mostra o número de APs e como eles se espalham dos canais WiFi. Usei essa ferramenta para definir meus canais WiFi para diferentes APs WiFi.

Mas realmente não posso dizer se pode haver outra interferência de RF.

Você pode fazer /interface wireless registration-table print interval=1 no seu mikrotik para ver o snr.

infelizmente, o WiFi.setOutputPower(0) também não ajudou ... depois de quase 6 horas funcionando sem problemas (sem nenhuma alteração na infraestrutura wi-fi, de repente ele entra em um impasse novamente (veja a saída serial abaixo) do qual nunca mais se recupera, exceto se por coincidência um SW ou HW WDT entra em ação ...

isso só parece acontecer após um "tempo limite de atualização da chave de grupo" ou uma "falha de handshake de 4 vias". se eu chutar o nó do AP manualmente, ele também obtém um "auth expire", mas pode reconectar instantaneamente ...

saída serial (nothe que a carga vai para 100% então) ...

20457441 : WIFI : Disconnected! Reason: '(16) Group key update timeout' Connected for 2h19m
20457593 : WIFI : Connecting clumsy_ap2 attempt #0
20458607 : WIFI : Not configured in Station Mode!!: clumsy_ap2
20459707 : EVENT: WiFi#Disconnected
20459763 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 2012 ms
20470762 : SYS  : 31.00,20048.00,66.70,341.00
20470766 : EVENT: sysinfo#rssi=31.00
20470824 : EVENT: sysinfo#mem=20048.00
20470882 : EVENT: sysinfo#load=66.70
20470940 : EVENT: sysinfo#uptime=341.00
20472658 : EVENT: Clock#Time=Thu,14:22
20473264 : WD   : Uptime 341 ConnectFailures 22 FreeMem 20040 WiFiStatus 0
20477609 : WIFI : Connecting clumsy_ap2 attempt #1
20478135 : WIFI : Not configured in Station Mode!!: clumsy_ap2
20482577 : EVENT: WiFi#Disconnected
20482635 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 4771 ms
20503270 : WD   : Uptime 342 ConnectFailures 22 FreeMem 18440 WiFiStatus 0
20505709 : WIFI : Connecting clumsy_ap2 attempt #2
20506235 : WIFI : Not configured in Station Mode!!: clumsy_ap2
20509784 : EVENT: WiFi#Disconnected
20509845 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 3879 ms
20530897 : SYS  : 31.00,16248.00,100.00,342.00
20530902 : EVENT: sysinfo#rssi=31.00
20530963 : EVENT: sysinfo#mem=16248.00
20531025 : EVENT: sysinfo#load=100.00
20531087 : EVENT: sysinfo#uptime=342.00
20532688 : EVENT: Clock#Time=Thu,14:23
20533158 : WD   : Uptime 342 ConnectFailures 22 FreeMem 16240 WiFiStatus 0
20533716 : WIFI : Connecting clumsy_ap2 attempt #3
20534242 : WIFI : Not configured in Station Mode!!: clumsy_ap2
20537788 : EVENT: WiFi#Disconnected
20537851 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 3865 ms

apenas uma observação rápida: adicionar wifi_set_phy_mode(PHY_MODE_11G); e forçar o nó no modo 802.11g parece ser pelo menos uma solução alternativa. Não tenho reinicializações de nenhuma das unidades desde algumas horas e também uma ou duas vezes uma unidade se recuperou do problema de tempo limite da chave de grupo acima ...
provavelmente relacionado a

• ESP8266 SoftAP suporta apenas 802.11b / g.

que é anotado nos documentos ...

Vou atualizar mais tarde / amanhã se ficar estável ...

Como já foi observado (algumas vezes) por outra pessoa, a sensibilidade também deve ser aumentada mudando para 802.11G.
Meu objetivo contra isso é (era?) Que a maioria dos AP tem problemas ao alternar entre N, G e B.
Você tem clientes mistos? (G e N) ativos no mesmo AP?

Eu uso modos diferentes em todos os Mikrotik. B / G / N / AC mistos, também ambas as bandas 2 / 5GHz incluindo APs virtuais definidos ... Clientes diferentes se conectam com modos diferentes no mesmo AP, sem problemas (exceto o esp8266) ..

boas notícias (pelo menos para mim) ... meus nós funcionaram nas últimas 12 horas sem desconectar / reiniciar / congelar!

forçar o nó em 802.11g parece funcionar sem problemas junto com os APs MikroTik. pelo menos esta é uma solução simples (contanto que você não precise da velocidade adicional de 802.11n).

se alguém quiser se testar, basta adicionar ESPEasyWifi.ino ao redor da linha 644 na função tryConnectWiFi() a seguinte linha (após setupStaticIPconfig(); ):
WiFi.setPhyMode(WIFI_PHY_MODE_11G);

Eu só posso imaginar que os problemas surgem porque o modo SoftAP não suporta 802.11ne o nó está conectado no modo N e o núcleo fica "confuso" de alguma forma ... mas acho que esse é um problema a ser levantado com o pessoal do núcleo. ..

Para ESPEasy isso poderia ser feito configurável eu acho (@ TD-er?) Para que pudesse ser escolhido na página de configuração em qual modo o ESP deve ser executado (B / G / N) ...

Sim, vou adicionar uma opção de seleção nas configurações avançadas.
Esqueci quem perguntou primeiro, mas irei procurar e creditar a ele também no commit;)

perfeito!! Não preciso do crédito, só preciso trabalhar;) fique à vontade para dedicar a ele !! 😄

Durante a depuração, encontrei algumas outras pequenas coisas que sugiro alterar (como chamar delay() incondicionalmente após chamadas de plug-in, alguns {} adicionais e algumas adições à saída de registro. Devo fazer um PR para estes ASPIT ou você gostaria de mantê-los como estão (eu acho que essas mudanças não são vitais, apenas algumas pequenas melhorias, provavelmente)?

Por favor, faça um PR.
Isso pelo menos ajudaria na discussão e manteria o controle de suas descobertas.
Além disso, adicionar comentários ao que você verificou seria útil

Para referência # 2012
Todos os créditos para o dev. equipe!

Este patch também inclui a ideia WiFi.setOutputPower (0)?

Estou fazendo uma experiência há 7 dias.
nó mega-20180224 - zero reinicializações
nó mega-20190110 - 35 reinicializações; 9 deles hoje.

Eu deixei a linha relevante no código, mas a comentei. Portanto, você precisaria remover // (sobre a linha 644) em ESPEasyWiFi.ino e recompilá-lo!

@oki desculpe, acabei de ver que li sua pergunta incorretamente ... Não, isso não está incluído, pois não pude ver nenhuma diferença ao definir a energia para 0 antes de reconectar ... Então, descartei esse novamente!

Estou fazendo uma experiência há 7 dias.
nó mega-20180224 - zero reinicializações
nó mega-20190110 - 35 reinicializações; 9 deles hoje.

Isso está efetivamente comparando:

• núcleo 2.3.0 sem wi-fi baseado em eventos
• núcleo 2.4.2 com wi-fi baseado em eventos.

boas notícias (pelo menos para mim) ... meus nós funcionaram nas últimas 12 horas sem desconectar / reiniciar / congelar!

forçar o nó em 802.11g parece funcionar sem problemas junto com os APs MikroTik. pelo menos esta é uma solução simples (contanto que você não precise da velocidade adicional de 802.11n).

Eu fiz o contrário para os testes.
Eu configurei meu Mikrotik para N-Mode apenas e bem ... todos os ESPs estão rodando desde> 12h sem uma única reinicialização.

abordagem boa e válida também! Infelizmente não posso fazer isso, pois faço vários clientes sem capacidade N ...

Basta desabilitar o modo B e habilitar apenas G / N. Você está melhor sem o modo B. A menos que você tenha telefones antigos ou (normalmente) leitores de código de barras wi-fi de 10 anos atrás que só suportam o modo B e taxas.

A sensibilidade adicionada da antena no modo B também não vai desempenhar nenhum papel significativo no alcance. O modo B apenas consome o tempo de antena. Não há literalmente nenhuma desvantagem em não usar o modo B e nenhuma desvantagem em usar o modo N em vez de G também. O modo N tem um alcance ainda melhor que o B e G também.

@ jimmys01 você está certo, o modo B provavelmente não é mais usado em nenhum lugar ... mas eu não posso ir apenas para N ... portanto, caberia testar o que acontece no modo G / N se os nós permanecerem estáveis e são capazes de se reconectar em caso de tempo limite do HS de 4 vias.

g / n é instável para mim.

Isso significa que o esp8266 tem problemas cada vez que faz a transição entre um modo (B / G / N)?

Isso significa que o esp8266 tem problemas cada vez que faz a transição entre um modo (B / G / N)?

Muito provavelmente.
Tenho visto muitos problemas com alguns dispositivos (não os ESP) que suportam apenas o modo G.
Se você usá-los misturados com dispositivos N, eles podem parecer inacessíveis.
Notórios são o HomeWizard e algumas câmeras WiFi.

Com esta nova versão mega-20190121 o ESP parece estar mais estável, não tive problemas de crash / Wlan até agora.
Mas agora não consigo mais desligar o OLED (framedPlugin). Quando envio OLEDFRAMEDCMD, desligado, ele desliga a tela por um breve momento e liga novamente.
Fiz um teste back to back com uma versão antiga (de 2018) o display reage conforme o esperado.

Acabei de experimentar o mega-20190121 e a estabilidade WiFi é a mesma. Ele trava em cerca de uma hora após o início.

@ TD-er, quando você acha que poderia empurrar uma versão com a mudança discutida para que eu possa testá-la?

atualização rápida: desde a configuração do modo de correção para 802.11g, não tenho mais travamentos, reinicializações, etc.! mesmo que os AP operem em modo g / n misto ... então eu também votaria em um patch que torne o modo wi-fi configurável no esp!

Espero um patch logo também 😉

Acabei de adicionar um commit para selecionar apenas o B / G.
Ele ainda não está funcionando bem no ESP32, então desativei a opção de selecioná-lo para o ESP32.
Também adicionei uma opção de fall-back para poder conectar novamente se o AP não permitir apenas B / G.

@ TD-er, quero dizer esta mudança:

Meu palpite é que há algo errado nas bibliotecas principais (LWIP ou Arduino ou ESP) e devemos redefinir o wi-fi.
Portanto, desligue o wi-fi e comece tudo de novo. Também pode esperar entre essas etapas para garantir que os buffers sejam esvaziados ou, pelo menos, liberados e as solicitações pendentes sejam ativamente canceladas.

A mudança discutida nos últimos 2 posts?
Ainda não foi implementado, mas posso tentar codificá-lo esta noite e fazer um teste de compilação.

@oki Tentei as duas variantes, definindo a potência de saída para 0 e desconectando / reconectando ativamente quando o problema ocorre. ambas as versões não ajudaram a resetar / reconectar ao AP ... (no meu ambiente) ... mais detalhes acima ...
a única coisa que o tornou estável foi usar o N-Mode.

Estou bem ciente disso. Esperando por um patch em breve, para poder continuar minha depuração.

@ 0ki posso fazer um testbuild para você usando este último commit.
Ou você também quer testar com a desativação do WiFi?

E em caso afirmativo, quais opções você deseja / precisa? Ligar / desligar o WiFi e reiniciar todos os serviços?
Essa última parte (reiniciar os serviços) também é algo para se dar uma boa olhada, uma vez que não tenho certeza se todos os serviços que usam um soquete foram reiniciados corretamente.
Isso também pode causar alguns problemas, eu acho, quando a conexão WiFi é recriada.

Desligar totalmente (e ligar) automaticamente o transmissor wi-fi quando for detectada uma desconexão.

Vejo que você adicionou algum código. Qual versão posso usar para testar isso?

Não tenho certeza, farei uma nova compilação para teste.
Isso será feito em +/- 30 minutos.

construção de teste
É baseado no que eu mesclei hoje mais cedo e no PR # 2235, que tem as alterações para conexão no modo B / G.
Parece que há problemas com alguns plug-ins nesse PR, então esse é o motivo pelo qual ainda não foi mesclado.

Obrigado! A versão de teste foi atualizada.

Eu tenho as seguintes configurações agora:
Connection Failure Threshold: 0 Force WiFi B/G: NO Restart WiFi on lost conn.: YES

Você acha que eu deveria testar algo diferente considerando que tenho o PLATFORMIO_ESP12E?
Ou seja, eu esqueci se b / g vai funcionar no esp12e e qual foi exatamente o limite de falha de conexão.

Esse limite é apenas um contador para iniciar uma reinicialização se várias tentativas de conexão malsucedidas excederem esse valor.
0 é o padrão e significa que não será realizada uma reinicialização.

Acho que defini-lo como 50 ou 100 ajudará você a reiniciá-lo quando estiver em um lugar difícil de alcançar e ele entrar em algum loop de reconexão.

Mesmo com essa configuração, ele ainda pode mostrar reinicializações de watchdog de HW, como vários de meus nós já mostraram.
Pode ser mais difícil reproduzir aqueles com o modo B / G ativo.

construção de teste
É baseado no que eu mesclei hoje mais cedo e no PR # 2235, que tem as alterações para conexão no modo B / G.
Parece que há problemas com alguns plug-ins nesse PR, então esse é o motivo pelo qual ainda não foi mesclado.

Obrigado pela compilação de teste.
Meu ESP12F antes mais instável está funcionando há 59 horas sem uma reinicialização :)

EDITAR: As configurações são:
Forçar WiFi B / G: SIM
Reinicie o WiFi ao perder a conexão: SIM

Acho que vou dividir esse commit (B / G WiFi) em um PR separado, para que possa ser mesclado antes de corrigir o resto do PR no qual está aguardando para ser mesclado.

Boa ideia!

Minhas configurações anteriores RestartWifi = YES não fizeram nada útil.

Agora mudei para

Connection Failure Threshold: 0
Force WiFi B/G: YES
Restart WiFi on lost conn.: NO

e já está há dois dias sem reinicialização ou mesmo uma única desconexão. Surpreendente. Eu não acho que vou nem mesmo me afastar desta versão de teste.

Após aprox. 100 horas o módulo finalmente fez um reset. :(

Motivo da reinicialização: Watchdog de hardware

No entanto, isso também pode ser causado pela configuração desafiadora (sensores 12 x 1 fio e um servidor FHEM).

Você também pode tentar adicionar este patch: https://github.com/letscontrolit/ESPEasy/pull/2235/commits/9a05eaf828a737ae416ab11c8df8c4a5b03ceaf2
Talvez isso também ajude a melhorar a estabilidade.
Está incluído nesta construção de teste

Você também pode tentar adicionar este patch: 9a05eaf
Talvez isso também ajude a melhorar a estabilidade.
Está incluído nesta construção de teste

Obrigado!
Instalado em duas unidades configuradas completamente diferentes e dará feedback.

tive uma execução em um dos meus nós de teste, incluindo
https://github.com/letscontrolit/ESPEasy/commit/9a05eaf828a737ae416ab11c8df8c4a5b03ceaf, infelizmente, levou apenas cerca de 2 horas até que o problema de grupo-chave-tempo limite novamente e não se recuperasse ou se reconectasse ao AP. Com "reiniciar wi-fi na conexão perdida" habilitado e não forçando para B / G .... então N ainda parece ser um problema ..
Portanto, para mim, o modo B / G ainda é a única opção de trabalho estável.

Podemos considerar a eliminação total do suporte N? Precisamos dos benefícios fornecidos por N para um dispositivo tão simples?

@ 0ki com a "nova" opção para forçar o modo B / G que o @ TD-er embutiu, basicamente eliminando N no nível do software, você não pode removê-lo das bibliotecas principais, presumo ...

Ao mover isso para as configurações principais, eu recomendo que esta opção seja enviada ATIVADA por padrão.

Poderíamos torná-lo dinâmico.
Se nenhuma conexão for possível, tente novamente com a opção N ativada.

Existem várias configurações que têm apenas N verificado no AP. Portanto, nesses ambientes você não pode voltar se estiver desabilitando o suporte N no ESPeasy.

Você também pode tentar adicionar este patch: 9a05eaf
Talvez isso também ajude a melhorar a estabilidade.
Está incluído nesta construção de teste

Obrigado!
Instalado em duas unidades configuradas completamente diferentes e dará feedback.

Até agora, um módulo reiniciou após 2 dias, o outro após 5 dias.
Ambos mostraram "Hardware Watchdog" como motivo de reinicialização.
Ambos os módulos estão definidos para "Forçar WiFi B / G: Sim" e "Reiniciar WiFi em caso de conexão perdida: Sim".
O AP é um Mikrotik configurado apenas para B / G (uptime 49 dias).
Distância entre AP e módulos aprox. 2 ... 3 m.

Eu estava me perguntando por que minha sugestão de torná-lo dinâmico (para voltar para a configuração N de B / G apenas) recebeu 2 "votos" negativos.
Explique por que não é uma boa sugestão.

Eu estava me perguntando por que minha sugestão de torná-lo dinâmico (para voltar para a configuração N de B / G apenas) recebeu 2 "votos" negativos.
Explique por que não é uma boa sugestão.

Na minha opinião, se alguém liga esta opção, ele já está procurando desesperadamente por mais estabilidade e sabe o que isso significa para suas configurações de AP.
Eu prefiro uma solução estática porque quando eu seleciono a opção B / G apenas, eu absolutamente nunca quero estar em uma situação em que eu acho que está usando B / G, mas não o faz.
No entanto, como meus nós estão reiniciando de qualquer maneira (embora com muito menos frequência), eu adoraria ter uma solução real para o problema relacionado ao núcleo mais recente.

Eu entendo isso, mas você também precisa entender o problema quando os usuários não sabem o que uma configuração faz e acabam com nós inacessíveis.
Portanto, deve haver um grande limite antes de voltar para o suporte N.
Por exemplo, o fallback para plug-ins corrompidos é:
Após 10 reinicializações malsucedidas, ele desabilitará 1 plugin ou controlador para ver se a reinicialização pode ser bem-sucedida.

Algo semelhante também pode ser aplicado à conexão wi-fi.
Após X tentativas malsucedidas de reconexão, ele permitirá a conexão com 802.11N permitido
A qualidade de recepção é melhor para redes de modo G, então se você colocar X em algo como 10, é muito improvável que ele se conecte com N em vez de G. Especialmente se você zerar este contador toda vez que tentar no modo N.

Hmm, as últimas semanas de menos tempo para ESPeasy aparentemente ofuscaram minha memória do que planejei implementar ou do que foi implementado.

Acabei de olhar o código para isso e descobri:

void setConnectionSpeed() {
  #ifdef ESP8266
  if (!Settings.ForceWiFi_bg_mode() || wifi_connect_attempt > 10) {
    WiFi.setPhyMode(WIFI_PHY_MODE_11N);
  } else {
    WiFi.setPhyMode(WIFI_PHY_MODE_11G);
  }
  #endif

Então, aparentemente, ele já foi implementado para permitir apenas N quando wifi_connect_attempt for> 10.
Este contador é redefinido para 0 assim que houver uma tentativa bem-sucedida de conexão ao Wi-Fi.

Esta é uma solução aceitável?

Hmm, as últimas semanas de menos tempo para ESPeasy aparentemente ofuscaram minha memória do que planejei implementar ou do que foi implementado.

Acabei de olhar o código para isso e descobri:

void setConnectionSpeed() {
  #ifdef ESP8266
  if (!Settings.ForceWiFi_bg_mode() || wifi_connect_attempt > 10) {
    WiFi.setPhyMode(WIFI_PHY_MODE_11N);
  } else {
    WiFi.setPhyMode(WIFI_PHY_MODE_11G);
  }
  #endif

Então, aparentemente, ele já foi implementado para permitir apenas N quando wifi_connect_attempt for> 10.
Este contador é redefinido para 0 assim que houver uma tentativa bem-sucedida de conexão ao Wi-Fi.

Esta é uma solução aceitável?

Bem ... eu diria que sim (esperando que o bug no 2.5.0 seja encontrado em breve).

Feedback sobre a configuração de B / G apenas.
Acabei de instalar o test fw em uma unidade que reiniciava a cada 20 minutos no máximo. Antes era conectado a N com -72dBi. Isso deveria ter sido um sinal bom o suficiente para não desconectar. Estou operando APs de nível empresarial com recursos de recepção de -105dBi. Então, novamente, nunca deve cair o canal.

Depois de algumas horas com o teste FW e não houve reset até o momento.
Vou mantê-lo funcionando e apresentar um relatório.

PS: Concordo que está relacionado a N de alguma forma.
PSS: Estou executando 20 nós ESP-07 que foram atualizados para 4M. Demorado, mas compensando quando o re-flash é necessário.

Tenho mais de 120 nós em execução no GN (mega-20190202) sem nenhum problema. Todos eles estão relatando estar conectados a N

@ jimmys01 Quantos nós estão se conectando ao mesmo AP?
E qual é a marca desse AP? (Mikrotik?)

Quase todos eles se conectam a um AP diferente (um por quarto de hotel). Eles têm um switch (sensor PIR), um sensor de temperatura e umidade HTU e leds IR.
A marca AP é Mikrotik.
As configurações são as seguintes:
País está definido
Canal de controle: 20Mhz
Banda: GN
Canal de extensão: desativado
Tipo de autenticação: apenas WPA2 PSK
Criptografia: aes ccm apenas
Criptografia de grupo: aes ccm
Atualização da chave Groyp: 00:01:00

Feedback sobre a configuração de B / G apenas.
Acabei de instalar o test fw em uma unidade que reiniciava a cada 20 minutos no máximo. Antes era conectado a N com -72dBi. Isso deveria ter sido um sinal bom o suficiente para não desconectar. Estou operando APs de nível empresarial com recursos de recepção de -105dBi. Então, novamente, nunca deve cair o canal.

Depois de algumas horas com o teste FW e não houve reset até o momento.
Vou mantê-lo funcionando e apresentar um relatório.

PS: Concordo que está relacionado a N de alguma forma.
PSS: Estou executando 20 nós ESP-07 que foram atualizados para 4M. Demorado, mas compensando quando o re-flash é necessário.

Infelizmente, a unidade continua a reiniciar após um tempo aleatório. Qualquer coisa dentro de 1-4 horas.
B / G apenas FW não resolve meus problemas

Eu estava me perguntando por que minha sugestão de torná-lo dinâmico (para voltar para a configuração N de B / G apenas) recebeu 2 "votos" negativos.
Explique por que não é uma boa sugestão.

Digamos que o wi-fi caia por uma hora devido a circunstâncias externas / ambientais. Meu (s) nó (s) mudam para N e se tornam altamente instáveis ​​novamente (meu aplicativo é sensível a reinicializações - o wi-fi não precisa estar lá 100% do tempo, mas o próprio nó deve estar operacional o tempo todo).

Eu gostaria de uma configuração para meus nós que evitasse a instabilidade e nunca conectar a N faria isso por mim agora.

Ao mover isso para as configurações principais, eu recomendo que esta opção seja enviada ATIVADA por padrão.

Como solução, poderíamos enviar isso para o modo fallback (B / G-depois-N) por padrão, podendo ser alternado apenas para B / G ou B / G / N.

Quanto à solução real para 2.5.0, tente o seguinte:

#include "esp_wifi.h"
esp_wifi_set_ps(WIFI_PS_NONE);

Tenho mais de 120 nós em execução no GN (mega-20190202) sem nenhum problema. Todos eles estão relatando estar conectados a N

Como você atualiza mais de 120 nós dentro de um período de tempo aceitável?
"... nenhum problema ..." você verificou o tempo de atividade de cada nó e o que é?
São todos iguais desde a última reinicialização pretendida?

Os tempos de atividade contam dias e todos eles têm 0 reconexões. Meses agora eu nunca tive nenhum problema com a conectividade, exceto quando desativei o PMKID nos APs. Provavelmente o núcleo mais recente ficou mais exigente quanto às configurações de wi-fi ou não sei o quê .. Eu também executo todos aqueles com fontes de alimentação 2A. Planejamos no próximo mês implantar mais 80 esp8266. A propósito, se @ TD-er quiser ter acesso para dar uma olhada na configuração específica, terei o prazer de dar a você. Eu realmente quero que o ESPEasy floresça, ele nos ajudou muito.

Edit: @ chunter1 Eu os atualizo usando scripts em lote

curl -# -o /dev/null --form update=@ESP_Easy.bin --max-time 40 --connect-timeout 20 --retry 1 http://x.x.x.x/update

@ jimmys01 Recentemente comprei um Mikrotik para poder testar coisas.

E apenas um aviso sobre as compilações do núcleo 2.5.0.
Nas próximas compilações noturnas, as compilações 2.5.0 não estão incluídas, já que há um bug no núcleo 2.5.0 que faz o servidor web parar de responder e deixar o nó travar.
Assim que isso for consertado, haverá compilações do núcleo 2.5.0 novamente.
Na última compilação noturna, há um núcleo 2.6.0 alfa incluído, que é essencialmente o código mais recente do github da biblioteca principal para que você possa ver por si mesmo.

Consegui o 2.6.0 com B / G rodando há 4 dias em dois módulos e o primeiro reiniciou.
O motivo da reinicialização foi o "cão de guarda do hardware" usual.
O que observo desde que o modo "B / G" está ativo é um tempo de execução de 3 a 5 dias antes de ocorrer uma reinicialização.

Talvez também compare o número de desconexões wi-fi, já que essas desconexões parecem estar relacionadas aos travamentos.

Ambos os módulos ficam na adega, distando apenas 2..3m do AP Mikrotik.
Acabei de verificar o segundo módulo executando a mesma versão do FW e mostra 0 reconexões e tempo de atividade 4d02h (sem reinicialização desde o flashing).
Acredito muito que o outro módulo, que fez o reset. também teve 0 reconexões antes de redefinir.

Em relação às tarefas configuradas nos dois módulos de teste:
O módulo que fez o reset possui 12 sensores DS18B20 configurados que enviam seu valor a cada 120s para um servidor FHEM.
O módulo que não foi resetado até agora tem apenas dois gpios configurados que também enviam seu valor a cada 120s para o mesmo servidor FHEM.

Então, AP (Mikrotik) é o mesmo, a distância (2..3mm) é a mesma, o servidor FHEM é o mesmo - só o módulo com os 12 sensores de temperatura definitivamente reseta mais frequente que aquele com os 2 gpios.

em meus nós isso acontece principalmente quando fhem está muito lento para responder ou não pode ser alcançado porque eu defini uma tentativa máxima de 100 e então os nós reinicializam (que também mostra uma reinicialização manual).

em meus nós isso acontece principalmente quando fhem está muito lento para responder ou não pode ser alcançado porque eu defini uma tentativa máxima de 100 e então os nós reinicializam (que também mostra uma reinicialização manual).

Por que seus nós devem reiniciar quando as tentativas são mais de 100?
(Eu defini novas tentativas para 0 para teste)

ferramentas -> avançado -> limite de falha de conexão

para ter certeza de que se o wi-fi nos módulos bloquear por algum motivo ele reinicialize após algum tempo ...

Ahh com "novas tentativas" você quer dizer o "Limite de falha de conexão:" e não o "Máximo de tentativas:" nas configurações do controlador de FHEM.
Eu defini o limite de falha de conexão para 0.

BTW: pela primeira vez eu tive um nó que travou no problema de tempo limite 4WHS, embora "apenas B / G" estivesse ativo ... nunca tinha tido isso antes até agora (auto-compilado, núcleo 2.5.0) .... Vou continuar assistindo, se isso for apenas uma coincidência ...

Observe que haverá um núcleo 2.5.1 muito em breve que reverte o SDK usado para SDK2.2.1, uma vez que existem muitos problemas com SDK3.0.0
Isso também pode alterar a forma como os nós reagem ao wi-fi e talvez seja comparável ao núcleo 2.4.2 novamente.
Não tenho certeza de quais correções no núcleo 2.5.0 estão incluídas, o que pode corrigir alguns outros problemas que estamos enfrentando.

@ chunter1 Sobre os nós que você possui.
Parece que aquele que foi reinicializado estava enviando muito mais mensagens para o controlador, então estatisticamente falando, ele tem uma chance maior de tentar enviar algo que parou em algum lugar no processo.

@ clumsy-stefan Você pode testar o código atual no Github? (ou a última compilação)

Fiz algumas mudanças em como realizar atividades relacionadas à rede.

Você quer dizer este?

ESP_Easy_mega-20190227_test_core_260_sdk3_alpha_ESP8266_4M.bin

Praticamente qualquer construção da noite passada.
Eu também adicionei uma versão "normal" para o núcleo 2.6.0 usando SDK2.
O Core 2.6.0 SDK2 agora está rodando em vários nós e só teve um watchdog HW em um deles que está excepcionalmente com poucos recursos (executando muitos plug-ins de alta memória) e também aquele com a memória flash provavelmente gasta (deveria jogue fora, já que teve 1000 atualizações de firmware

@ TD-er Eu compilei e instalei do git cerca de 6 horas atrás em nós 2test .. mas como eu ainda tenho acesso à internet muito limitado, provavelmente só poderei relatar em 24 horas, então ...

Estou testando o firmware mais recente com "Force B / G mode" com o roteador Mikrotik e até agora parece funcionar estável. Apresentarei um relatório.

@ TD-er Uma pergunta: Qual é a regra para o fallback para o modo N quando "Forçar modo B / G" é definido?

@ giig1967g
Se ele falhou ao se conectar por mais de 10 vezes ao AP com _B / G apenas_, ele reverterá para o modo BGN padrão.

Portanto, isso deixa a possibilidade de se conectar no modo N se o AP estiver offline por algum tempo.
Se isso parecer um problema real, posso tentar defini-lo para fazer isso apenas a cada dez tentativas, mas preciso ter certeza de que ele também tentará isso quando o ssid de fallback for tentado.

Olá @ TD-er
Acho que o fallback é uma má ideia.
Veja este cenário: Eu tenho minha unidade forçada para o modo B / G rodando bem com meu Mikrotik.
Por algum motivo meu Mikrotik fica offline (atualização, reinicialização, qualquer coisa).
Sempre que o mikrotik voltar a tocar, o ESP vai então conectar no modo N e perdi a estabilidade do aparelho.

Em outras palavras, se eu definir o modo Force B / G e a conexão falhar, ele deve se tornar um AP (192.168.4.1), mas não deve retornar ao modo N. A possibilidade de fallback cria uma falsa expectativa para o usuário.

Não me leve a mal, o substituto foi bom para testar a validade da alteração, mas agora que comprovou que resolve o problema (pelo menos o meu até agora), o substituto deve ser removido.

Concordo com o comentário de @ chunter1 : https://github.com/letscontrolit/ESPEasy/issues/1987#issuecomment -462295204

O que você pensa sobre o próximo cenário então.
Assim que for possível conectar-se a determinados APs usando apenas B / G, um sinalizador extra será definido para não fornecer mais fallback.
Se algumas dessas configurações (apenas B / G ou outras configurações de AP) forem alteradas, o fallback será habilitado novamente até que a conexão com o AP fornecido seja bem-sucedida.

Editar:
Com substituto, quero dizer essas configurações extras, não o "SSID substituto"

Em outras palavras, o fallback permanece ativo apenas até a primeira conexão bem-sucedida com o AP e, em seguida, é removido. Nesse caso, seria útil ver na página do sistema o modo wi-fi.
É uma solução possível, mesmo que eu ainda prefira evitar fallbacks para N se eu definir Force B / G.
Eu entendo a possibilidade do usuário cometer erros, mas aí o usuário poderia digitar o SSID errado e não conseguir acessar o aparelho em nenhum caso ...

Outra questão: na implementação atual em que cenário a unidade vai se tornar um AP?
Porque me parece que a unidade tentará B / G 10 vezes e depois N, mas ela acabará desistindo e se tornando um AP?

Não, o modo AP permanece ativo enquanto ainda testa a conexão aos APs fornecidos.
Talvez devêssemos adicionar uma verificação opcional de tempo de atividade e permitir o início do modo AP apenas nos primeiros 10 minutos em que o nó for inicializado.
Apenas para segurança extra e também para excluir a possibilidade de o modo AP ter um efeito sobre o ESP não ser capaz de alcançar as redes wifi fornecidas.

E devemos manter o foco na parte "fácil" do projeto.
Isso significa padrões adequados e nenhuma quantidade excessiva de configurações oferecidas, mas dá ao especialista a opção de fazer tudo.
Isso também significa que deve haver um recurso adequado para o usuário menos experiente.
Especialmente para configurações apenas B / G. Acho que mais de 90 por cento das pessoas que começam com ESPeasy não estão cientes das diferenças entre 802.11B / G / N Então, se eles tiverem problemas, que podem ser tratados muito bem usando um substituto, pode fazer com que procurem outros projetos .
Eu também entendo por que esse fallback não deve dar uma falsa sensação de 'estabilidade', então eu realmente entendo por que a implementação atual tem espaço para melhorias. Mas se a "primeira tentativa de conexão bem-sucedida => desabilitar fallback" for automatizada, também será perfeita para o usuário mais experiente. (que também comete erros estúpidos, como sei por experiência própria;))

Concordo que deve ficar mais claro qual configuração de conexão é ativamente usada.

Entendido.
Então, o prosal é:
A unidade Boots.
O sinalizador N-fallback está definido como verdadeiro.
Se FORCE B / G estiver definido, ele tentará 10 vezes se conectar ao AP wi-fi em B / G.
Se ele puder se conectar, ele definirá o flack N-fallback como falso.
Se não conseguir se conectar, ele tenta o modo N.

Considere também este cenário com Forçar conjunto B / G: falha de energia.
ESP e roteador Wifi estão desligados.
Em seguida, a energia retorna e o ESP é ativado mais rápido do que o roteador wi-fi.
Neste caso, pode acontecer que após 10 vezes o AP wi-fi não esteja escutando.
Portanto, a unidade tentará o modo N e, eventualmente, terá sucesso.
O usuário (experiente) não saberá que a conexão estava no modo N e pensa que ela está no modo B / G com falta de estabilidade.

Não quero insistir, mas realmente esses problemas de HW e congelamento acontecem há 1 ano. Agora que você, com a ajuda da comunidade, encontrou uma solução de trabalho, recomendo fortemente que ela continue sendo aplicada. O risco de um usuário inexperiente definir o "Modo B / G forçado" é menor do que ele definir o SSID errado com os mesmos resultados: nenhum acesso ao ponto de acesso.

SUGESTÃO:
Para garantir que o usuário menos experiente não cometa erros, por que você não adiciona um botão para "Testar modo B / G". Se tiver sucesso habilita o "modo FORCE B / G", caso contrário fica desabilitado.

Neste caso, usuários menos experientes saberão o que estão fazendo e usuários mais experientes terão certeza de que quando o modo ForceB / G for definido, ele não poderá voltar para N.

O que você acha?

Você poderia

Não apenas se ele inicializar, mas a opção de fallback será desativada nas configurações e salva.

Está bem. Então, uma verificação manual é ainda mais apropriada em vez de uma verificação automática. Você não acha?

Sim, primeiro adicionarei uma marca de seleção simples para desativar as substituições.
Mas depois deve ser feito mais dinâmico nisso para nos ajudar também, os "experts" a cometer menos erros :)

Está bem

A versão 2019_02_16 agora funcionava por 9 dias sem reinicialização (forçado para B / G). Ontem começou a reiniciar novamente. O watchdog de hardware forçou isso duas vezes.
Depois de um tempo, a unidade não estava mais acessível. A troca do roteador WLAN não ajudou (tentei 3 vezes, até 30 minutos). Reiniciar o ESP trocando o fusível de alimentação também não ajudou.
Tive que desligar o wlan novamente e conectar ao ESP via 192.168.4.1 direto para obter acesso a ele

Eu não tenho absolutamente nenhuma ideia do que aconteceu

@kischde Que tipo de ponto de acesso você está usando?
Ontem à noite eu mesmo experimentei algo semelhante ao experimentar instalar um novo AP.
Eu estava tentando instalar um MikroTik AP e tudo estava funcionando bem até o ESP precisar se reconectar.
Pela interface web do MikroTik, pude ver que o nó estava conectado ao WiFi, mas não recebia um endereço IP.
Mesmo quando tentei conectá-lo ao hotspot do meu telefone, consegui reiniciar o ESP, mas ele repetiu esse comportamento.
Somente quando eu defini a configuração do AP principal para outro AP ele começou a se conectar como deveria.

Observe que o nó não foi reinicializado para isso.

Uma coisa que está definida como "incorreta" naquele AP, em comparação com outro MikroTik que eu tenho, é que ele tem a configuração "Distância" definida como "dentro de casa".
Vou realizar mais testes para ver qual é a diferença aqui, mas como discutido antes, parece haver uma configuração de tempo limite para uma resposta em um pacote.
E posso imaginar que o ESP leve algum tempo para responder às solicitações de DHCP, que podem ser muito curtas para essa configuração.

Estou usando um Swisscom AP (provedor de telecomunicações suíço AP), mas tive todos os mesmos problemas escritos aqui em lugares diferentes como os caras com o MikroTik. Talvez tenha o mesmo chipset, mas não consigo mudar muito na configuração, por exemplo aquelas configurações estendidas.
Antes de religar, também tentei me conectar com meu celular, como você fez, com o mesmo comportamento que você.
Eu uso fix IP, sem DHCP
Mudei agora para o atual 2019_03_05, vou ver o que acontece ...

Você alterou recentemente as configurações de WiFi?
Por exemplo, ponto de acesso com endereço MAC AA: AA: AA: AA: AA na posição 1 do outro AP do SSID com endereço MAC BB: BB: BB: BB: BB: BB
Tenho a impressão de que ainda restam algumas configurações em algum lugar do ESP onde não as armazenamos.

Também tentarei ver nos documentos do NonOS como eles podem ser eliminados com eficácia quando alteramos as configurações de WiFi.
Também em meus testes, parece ser muito útil ter mais de 2 SSIDs para serem usados.
Também tentarei adicionar mais campo para isso, ou talvez até mesmo permitir o armazenamento de algum arquivo criptografado em SPIFFS para ter uma quantidade quase ilimitada de APs WiFi armazenados.

Você alterou recentemente as configurações de WiFi?

Não, como eu tenho apenas um AP, este foi IMO não necessário

ESTÁ BEM. Bom saber.
Como ainda não sei o que está causando isso, estou tentando eliminar o máximo possível de incógnitas.
Portanto, a única coisa que você precisa fazer para que funcione novamente é adicionar a configuração de wi-fi novamente.

Não menos ainda
Obriguei a conectar direto ao esp via 192.168.4.1 (desabilitei o AP)
Então eu verifiquei tudo, mas não achei nada de anormal ... Então eu tentei reiniciar meu AP, depois reiniciei o ESP e ele rodou novamente. Então, IMO, eu só tive que forçar para fazer uma conexão WLAN "normal / outra".
BTW eu também vi conectado no AP, mas também nenhum endereço IP atribuído, porém é estático

Hmm, estou brincando um pouco com ele, com 5 nós conectados ao MikroTik que estou usando.

Assim que eu definir "Hw. Fragmentation Threshold" (apenas 'desdobrar' a opção), os nós ESP não são mais capazes de receber qualquer endereço IP.
O valor padrão dessa configuração é 256. Se eu definir para 1600 (caberá em um MTU completo), todos os nós receberão um endereço IP e continuarão a trabalhar.

Isso é mostrado na IU do MikroTik quando os nós são capazes de se comunicar:

E isso quando eles não são capazes de enviar / receber quaisquer dados (mas estão conectados à camada WiFi)

@ TD-er, você viu que há uma opção no novo núcleo esp8266 chamada LWIP_FEATURES que eu acho que ativará a remontagem de IP ... Provavelmente isso não está definido em sua compilação?

veja aqui: https://github.com/esp8266/Arduino/blob/192aaa42919dc65e5532ea4b60b002c4e19ce0ec/tools/sdk/lwip2/include/lwipopts.h#L748 -L754

também o suporte para fragmentação de IP é definido com isto:
https://github.com/esp8266/Arduino/blob/192aaa42919dc65e5532ea4b60b002c4e19ce0ec/tools/sdk/lwip2/include/lwipopts.h#L756 -L763

Hmm, não tenho certeza de quais são os padrões.
Os números fornecidos na primeira linha da documentação do

Não sei ... Só sei que no IDE do Arduino, no arquivo de definição de plataformas, você pode selecionar se deseja que seja incluído e definido ou não ..

Sempre pensei que as partes LWIP fossem incluídas como bibliotecas pré-compiladas na distribuição principal.
Portanto, é muito difícil garantir que o LWIP seja reconstruído usando os sinalizadores corretos.

sim, mas depende de qual você vincular (de boards.txt):

-llwip2-1460-feat
-llwip2-536-feat
-llwip2-536
-llwip2-1460
-llwip2

Então, eles estão usando estes sinalizadores:

https://github.com/esp8266/Arduino/blob/192aaa42919dc65e5532ea4b60b002c4e19ce0ec/boards.txt#L357 -L387

| Etiqueta | build.lwip_lib | build.lwip_flags |
| --- | --- | --- |
| v2 Memória inferior | -llwip2-536-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 0 |
| v2 Maior largura de banda | -llwip2-1460-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 0 |
| v2 Memória inferior (sem recursos) | -llwip2-536 | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 0 -DLWIP_IPV6 = 0 |
| v2 Maior largura de banda (sem recursos) | -llwip2-1460 | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 0 -DLWIP_IPV6 = 0 |
| v2 IPv6 Memória inferior | -llwip6-536-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 1 |
| v2 IPv6 maior largura de banda | -llwip6-1460-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 1 |
| v1.4 Largura de banda superior | -llwip_gcc | -DLWIP_OPEN_SRC |
| v1.4 Compilar da fonte | -llwip_src | -DLWIP_OPEN_SRC |

Portanto, todas as versões v2 têm LWIP_FEATURES=1 exceto aquelas rotuladas como "sem recursos"

sim, mas se você olhar as instruções -l , você precisa ler as bibliotecas com -feat no final (ao contrário do rótulo, um pouco contra-intuitivo) ...