2016-02-18 17 views
5

rubare da here Ho creato un piccolo script Python in ascolto su una porta e stampa tutti i pacchetti UDP ricevuti:netcat invio di "X" in più pacchetti UDP

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) 

Ora sto usando netcat per inviare dati a questo script. Ecco la mia linea di comando.

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

Ed ecco l'output Python:

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

Questi primi quattro di righe "X" arrivano a circa intervalli di un secondo, poi le ultime due linee arrivano approssimativamente simultaneamente.

La mia domanda è questa: da dove provengono questi pacchetti "X" aggiuntivi, e se la fonte è netcat, allora come posso impedire a netcat di emetterli? Questo è il netcat di BSD, credo.

risposta

0

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

+1

Su quale sistema operativo esiste /d/udp'? –

+0

Ah, vedo che è una caratteristica bash, non una funzionalità del sistema operativo. Non lo sapevo. –

+0

Ho scritto un/dev/udp su QNX molto tempo fa. Sono abbastanza sicuro che ci fosse qualcosa del genere sul piano 9 anche se ha funzionato in modo diverso da quello che ricordo vagamente. –

2

Per ragioni che non è possibile determinare, quelle X pacchetti vengono inviati con l'opzione -v-nc. Prova a modificare:

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

La [documentazione] (http://linux.die.net/man/1/nc) dice semplicemente che '-v'" fornisce [s] un output più dettagliato ". Pensi che questo potrebbe essere un difetto in 'netcat'? – qntm

+0

"* Per ragioni che non riesco a determinare *" era il mio modo di dire: "Non so perché". Non so se si tratta di un difetto in netcat o di una funzionalità progettata di netcat o di un dettaglio di implementazione. –

+0

@ Robᵩ Il vantaggio dell'open source è che [si può sapere ...] (http://stackoverflow.com/a/42241513/211160) – HostileFork

6

Questa è netcat di BSD, credo.

Ho avuto lo stesso problema, e quando ho fatto nc --version anzi ho visto:

Questa è NC dal pacchetto netcat-OpenBSD. Un nc alternativo è disponibile nel pacchetto netcat-tradizionale.

saggezza convenzionale è che il BSD è il "migliore" versione (vedi What are the differences between netcat-traditional and netcat-openbsd?)

Ma in ogni caso, le fonti BSD è dove si dovrebbe cercare di trovare il relativo codice per cui la " X "in realtà viene da. E non devi sembrare troppo difficile!

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

La pistola fumante è una funzione 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); 
} 

E le condizioni in cui questo si chiama è che se vflag (Verbosity) o zflag (Port Scan Flag) sono fissati:

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

Riguardo alla motivazione f o perché lo switch -v inizia a lanciare dati casuali sulla porta UDP, direi che l'idea è che coloro che utilizzano -v vogliono ogni bit di informazioni che possono ottenere. Quindi il compromesso di ottenere un messaggio di errore vocale e precoce sulla connessione è valsa la pena per aiutare qualcuno in una situazione di debug.

Ma anche così, la mia opinione sarebbe che invece di inviare il criptico "X" che l'invio di qualcosa come "NETCAT UDP PING DUE TO -V OPTION" sarebbe meglio. : -/