2016-02-18 4 views
5

von here Stehlen Ich habe einen kleinen Python-Skript einrichten, die auf einem Port lauscht und drucken alle der UDP-Pakete heraus, es erhält:netcat Senden extra „X“ UDP-Pakete

import socket 

UDP_IP = "127.0.0.1" 
UDP_PORT = 5005 

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) 
sock.bind((UDP_IP, UDP_PORT)) 

while True: 
    data, addr = sock.recvfrom(1024) 
    print "received message:", repr(data) 

Jetzt verwende ich netcat um Daten an dieses Skript zu senden. Hier ist meine Befehlszeile.

echo -e "foo:1|c" | netcat -v -u localhost 5005 

Und hier ist die Ausgabe von Python:

received message: 'X' 
received message: 'X' 
received message: 'X' 
received message: 'X' 
received message: 'X' 
received message: 'foo:1|c\n' 

Diese ersten vier oder so „X“ Linien kommen in etwa Intervallen von einer Sekunde, dann die letzten beiden Zeilen in etwa gleichzeitig ankommen.

Meine Frage ist das: Woher kommen diese zusätzlichen "X" -Pakete, und wenn die Quelle netcat ist, wie kann ich dann verhindern, dass netcat diese ausgibt? Dies ist BSD netcat, glaube ich.

Antwort

0

Verwenden echo -n "foo:1|c" > /dev/udp/localhost/5005

+1

Auf welchem ​​OS existiert '/ dev/udp'? –

+0

Ah, ich sehe, das ist eine Bash-Funktion, keine OS-Funktion. Ich wusste nichts davon. –

+0

Ich habe vor langer Zeit ein/dev/udp auf QNX geschrieben. Ich bin mir ziemlich sicher, dass es so etwas in Plan 9 gab, obwohl es anders funktionierte, als ich es vage erinnere. –

2

Aus Gründen kann ich nicht bestimmen, diese X Pakete werden von der zu nc-v Option gesendet. Versuchen Sie stattdessen:

echo -e "foo:1|c" | netcat -u localhost 5005 
+0

Die [Dokumentation] (http://linux.die.net/man/1/nc) sagt nur, dass '-v'" [s] mehr ausführliche Ausgabe geben ". Denken Sie, dass dies ein Fehler in "netcat" sein könnte? – qntm

+0

"* Aus Gründen, die ich nicht bestimmen kann *" war meine Art zu sagen: "Ich weiß nicht warum." Ich weiß nicht, ob dies ein Fehler in netcat oder ein entworfenes Feature von Netcat oder ein Implementierungsdetail ist. –

+0

@ Robᵩ Der Vorteil von Open Source ist, dass [man kann es wissen ...] (http://stackoverflow.com/a/42241513/211160) – HostileFork

6

Dies ist netcat BSD, glaube ich.

hatte ich das gleiche Problem, und als ich nc --version habe ich sah in der Tat:

Dieses aus dem netcat-openbsd Paket nc. Eine Alternative NC ist im netcat-traditionellen Paket verfügbar.

konventionelle Weisheit ist, dass die BSD die „bessere“ Version ist (siehe What are the differences between netcat-traditional and netcat-openbsd?)

Aber wie auch immer, ist die BSD-Quellen, wo man aussehen würde, müssen den entsprechenden Code zu finden, wo die " X "kommt tatsächlich von. Und du musst nicht zu hart schauen!

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/nc/netcat.c?rev=1.177

Der smoking gun ist eine Funktion udptest():

/* 
* udptest() 
* Do a few writes to see if the UDP port is there. 
* Fails once PF state table is full. 
*/ 
int 
udptest(int s) 
{ 
    int i, ret; 

    for (i = 0; i <= 3; i++) { 
     if (write(s, "X", 1) == 1) 
      ret = 1; 
     else 
      ret = -1; 
    } 
    return (ret); 
} 

Und die Bedingungen, unter denen diese aufgerufen wird, wenn vflag (Ausführlichkeit) oder zflag (Port Scan Flag) gesetzt sind:

if (vflag || zflag) { 
    /* For UDP, make sure we are connected. */ 
    if (uflag) { 
     if (udptest(s) == -1) { 
      ret = 1; 
      continue; 
     } 
    } 
    ... 

In Bezug auf die Begründung f oder warum der -v Schalter würde beginnen, zufällige Daten am UDP-Port zu werfen, würde ich die Idee vermuten, dass diejenigen, die -v verwenden, jedes bisschen von Informationen wollen, die sie bekommen können. Daher lohnt sich der Kompromiss, eine frühe und vokale Fehlermeldung über die Verbindung zu erhalten, um jemandem in einer Debugging-Situation zu helfen.

Aber auch so meine Meinung wäre, dass stattdessen die kryptischen "X" senden, dass besser wäre so etwas wie "NETCAT UDP PING DUE TO -V OPTION" senden. : -/