Nodemcu: UDP-Kommunikation wird beeinflusst, wenn es UDP-Listener gibt/gibt?

Question

Ich habe ein seltsames Problem mit nodemcu Firmware (2.1.0) auf einem ESP8266, wo mir die Ideen ausgehen, was ich sonst noch versuchen könnte, um das Problem zu lösen.

Ich habe ein einfaches Lua-Skript ausgeführt, das auf UDP für Befehle zum Ein- und Ausschalten eines Relais und zum Senden aktiver Nachrichten über UDP alle 60 Sekunden an eine definierte IP-Adresse wartet.

Wenn nichts auf der Serverseite zu hören ist, die die UDP "am Leben" Nachrichten erhalten soll, reagiert ESP gut, alles gut. Sobald ich Netcat starte, um die UDP-Pakete zu hören, die von ESP kommen, fängt das ESP an, alle paar Minuten für mindestens 30-60 Sekunden zu hängen. Es ist besonders verwirrend, da ich erwarte, dass UDP ein verbindungsloses Protokoll sein wird. Wie kann also ein Hörer auf UDP das Verhalten des Senders beeinflussen? Dies sind die relevanten Teile des Lua Script:

[...] 
alive=60000 
[...] 

function srvupd(s) 
if (connected==1) then 
    s = s .." "..ip 
    srv:send(serverport, serveradr, s.."\n") 
    end; 
end; 

if (alive>0) then 
tmr.alarm(2, alive, 1, function() 
    srvupd("alive") 
    end) 
end 

srv=net.createUDPSocket() 
srv:listen(80) 
srv:on("sent", function() 
    srv:close(); 
    srv:listen(80); 
    end) 
srv:on("receive",function(client,request, port, ip) 
    if (alive>0) then tmr.stop(2) end 
    print(string.format("received '%s' from %s:%d", request, ip, port)) 
    buf="unknown" 

    if (request == "ch1on") then gpio.write(relay1, relayon);buf="ok" end 

[...] 

    client:send(port, ip, buf) 
    if (alive>0) then tmr.start(2) end 
end) 

Und das ist, wie ich netcat verwenden, um die UDP-Nachrichten von ESP in einem Bash-Skript zu hören:

#!/bin/bash 
while true 
do 
msg=$(netcat -4 -u -n -l -D 192.168.0.5 2701 -w0 -q0) 
echo -e "$msg" 
done 

In der Situation, in der ESP reagiert nicht mehr auf UDP-Befehle, die aktiven Nachrichten senden noch jede Minute. Die UDP-Kommandos werden sogar vom ESP empfangen, denn sobald die Verarbeitung fortgesetzt wird, wird ein "channel-on" -Befehl ausgeführt, der vor einiger Zeit gesendet wurde.

Diese temporären Sperren von ESP passiert nur, wenn ich seine UDP-Nachrichten abhöre. Ich habe alle Arten von Kombinationen überprüft, wie separate UDP-Sockets für den Listener und das Live-Senden auf dem ESP, Schließen und Öffnen des Servers, nachdem Nachricht gesendet wurde (wie in der aktuellen Version oben) usw. Ich habe versuchte sogar Befehle über TCP zu empfangen und nur die aktiven Nachrichten über UDP zu senden. Verhalten bleibt gleich. Alles funktioniert, solange nichts die UDP-Nachrichten von ESP empfängt. Sobald ich netcat starte, beginnt ESP innerhalb weniger Minuten zu hängen.

Irgendwelche Ideen? Wie es UDP ist, ist es schon schwer zu verstehen, wie es überhaupt passieren kann.

freundlichen Grüßen Tjareson

Answer 1

Das Problem mittlerweile gelöst. Ein Freund von mir wies mich auf die einzige gemeinsame Basis für die UDP-Frage hin, nämlich ARP.

Das Verhalten trat nur auf, wenn ESP in einem anderen Netzwerk als der UDP-Listener war. (wie 192.168.1.x und 192.168.5.y) Auch wenn es ein wenig unklar bleibt, ist das Vermuten, dass netcat wahrscheinlich eine ARP-Anfrage macht, wenn eine Nachricht empfangen wird und diese irgendwie vom Router nicht richtig verarbeitet wird wenn es zwischen zwei verschiedenen Netzwerken stattfindet.

Nachdem Sie den Listener Bashscript in das gleiche Netzwerk (im Grunde genommen durch die Himbeere, auf der es läuft eine zweite IP im Netzwerk der ESP ist in), die blockierte ESP-Kommunikation ist nicht wieder geschehen.