netcat wysyłając dodatkowy znak „X” UDP

okradanie here mam założyć małą skrypt Pythona, który nasłuchuje na porcie i drukuje wszystkich pakietów UDP to otrzymuje:netcat wysyłając dodatkowy znak „X” 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)

Teraz używam netcat wysłać dane do tego skryptu. Oto moja linia poleceń.

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

I tu jest wyjście z Pythona:

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

Te pierwsze cztery lub tak „X” linie dojść mniej więcej sekundowych odstępach, po czym dwa ostatnie wiersze przybywają mniej więcej równocześnie.

Moje pytanie brzmi: skąd się biorą te dodatkowe pakiety "X", a jeśli źródłem jest netcat, to w jaki sposób mogę zapobiec emisji ich przez netcat? Myślę, że jest to netcat BSD.

Źródło

2016-02-18 qntm

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

Źródło

2016-02-18 15:47:08 leongold

Na jakim systemie operacyjnym istnieje '/ dev/udp'? –

Ah, widzę, że jest to funkcja bash, a nie funkcja systemu operacyjnego. Nie wiedziałem o tym. –

Napisałem/dev/udp na QNX dawno temu. Jestem pewien, że było coś takiego na planie 9, chociaż działało to inaczej niż to, co mgliście pamiętam. –

Ze względów I nie może określić te X pakiety są wysyłane przez opcję nc-v. Spróbuj to zamiast:

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

Źródło

2016-02-18 16:06:19

[Dokumentacja] (http://linux.die.net/man/1/nc) mówi, że '-v' daje [s] bardziej szczegółowe wyniki". Czy myślisz, że to może być defekt w 'netcat'? – qntm

"* Z przyczyn, których nie potrafię określić *" był mój sposób powiedzenia: "Nie wiem dlaczego". Nie wiem, czy jest to usterka netcata, czy zaprojektowanej cechy netcata, czy szczegóły implementacji. –

@ Robᵩ Zaletą open source jest to, że [można poznać ...] (http://stackoverflow.com/a/42241513/211160) – HostileFork

To netcat BSD, wierzę.

miałem ten sam problem, a kiedy nie nc --version I rzeczywiście zobaczył:

to nc z pakietu netcat-OpenBSD. Alternatywne nc jest dostępne w pakiecie netcat-traditional.

Konwencjonalna mądrość jest, że BSD jest „lepsza” wersja (patrz What are the differences between netcat-traditional and netcat-openbsd?)

Ale w każdym razie, źródła BSD, gdzie trzeba by szukać, aby znaleźć odpowiedni kod, gdzie " X "faktycznie pochodzi z. I nie musisz wyglądać zbyt mocno!

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

Pistolet palenie jest funkcja 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); 
}

i warunki, w których jest to nazywane jest jeśli vflag (oznajmiania) lub zflag (Port Scan Flag) są ustawione:

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

Odnośnie do rationale f lub dlaczego przełącznik -v zacząłby wyrzucać losowe dane w porcie UDP, domyślam się, że ci, którzy używają -v, chcą uzyskać wszystkie potrzebne informacje. Dlatego warto uzyskać wczesny i głosowy komunikat o błędzie dotyczący połączenia, aby pomóc komuś w sytuacji debugowania.

Ale mimo to, moim zdaniem byłoby to, że zamiast wysyłać tajemniczego "X", że wysyłanie czegoś takiego jak "NETCAT UDP PING DUE TO -V OPTION" byłoby lepsze. : -/

Źródło

2017-02-15 05:42:27 HostileFork

netcat wysyłając dodatkowy znak „X” UDP

Odpowiedz

Powiązane problemy