Ich versuche, OpenBSD Netcat dazu zu bringen, auf UDP-Verbindungen an einem bestimmten Port (3333) und einer bestimmten Schnittstelle (10.42.0.1) zu hören und eine feste Antwort zu senden. Um dies zu erreichen, mache ich Folgendes:
echo "asd" | nc -k -u -l -p 3333 -s 10.42.0.1 -v
Und dann sende ich eine Nachricht, indem ich Folgendes tue:
echo qwe | nc -u 10.42.0.1 3333 -v
Die Ausgänge sind
# Server side
Bound on h9ct3d3 3333
XXXXXqwe
# Client side
Connection to 10.42.0.1 3333 port [udp/*] succeeded!
Wie Sie sehen, empfängt der Client keine asd. Wenn ich jedoch die entferne -k, empfängt er sie:
##### Server side
echo "asd" | nc -u -l -p 3333 -s 10.42.0.1 -v
Bound on h9ct3d3 3333
# ...
# Wait for the client to execute
# ...
Connection received on h9ct3d3 51318
XXXXXqwe
##### Client side
echo qwe | nc -u 10.42.0.1 3333 -v
# ...
# Wait for the above 'X'to finish
# ...
Connection to 10.42.0.1 3333 port [udp/*] succeeded!
asd
Ich habe versucht, eine while-Schleife ohne zu verwenden -k, aber nces kommt nie Folgendes zurück:
#!/bin/bash
while true
do
echo "Host message" | nc -q 0 -u -l -p 3333 -s 10.42.0.1 -v
echo "restarting..."
done
Wie kann ich das zum Laufen bringen?
Meine Version von Netcat ist:
OpenBSD netcat (Debian patchlevel 1.206-1ubuntu1)
PD. Warum nc„sendet“ der Server diese komischen XZeichen? Der Client liest sie nie, er wartet nur, bis sie fertig sind. Sie scheinen jede Sekunde angezeigt zu werden.
Antwort1
Der Server sendet die Xs nicht; der Client sendet sie, in Abständen von 1 Sekunde nach den ersten beiden, und der Serverzeigtsie (wie es sein sollte). Wenn Sie -vdieKlient, die Xs werden nicht gesendet oder angezeigt, und die Daten werden sofort gesendet und angezeigt (nicht nach 3 Sekunden). Ich habe keine AhnungWarum -vbedeutet „sende 5 X Zeichen langsam“!
Die Manpage für -ksagt
Bei gemeinsamer Verwendung mit der Option -u wird der Server-Socket nicht verbunden und kann UDP-Datagramme von mehreren Hosts empfangen.
In Übereinstimmung damit -vloggt sich der Server Connection from {host} {port} received!bei der Verwendung ein -ul, aber nicht bei der Verwendung von -ulk. Ichverdächtigder Code zum Senden der „Antwort“-Daten hängt davon ab, dass der Socket verbunden ist. Wenn er also nicht verbunden bleibt, wird die Antwort verhindert. Ich habe den Quellcode jedoch nicht durchsucht, um dies zu überprüfen.
-q 0wird nicht funktionieren, da es bei UDP kein erkennbares „Verbindungsende“ gibt, während es bei TCP (FIN-Austausch) eines gibt. Wenn Ihre Clientdaten etwas Erkennbares aufweisen – beispielsweise head -1wenn sie immer eine Zeile sind – sollte es logischerweise möglich sein, etwas zu schreiben, das diese Daten erkennt und den ncProzess beendet, sodass die Schleife wiederholt werden kann, aber ich konnte keinen sauberen Weg finden, die PID für nceinen solchen Erkenner/Killer verfügbar zu machen. Ich mache CW, falls jemand anders hier eine echte Lösung anbieten kann.