Interpretacji wyniku tcpdump

sethiel · Post autor: **sethiel** » 09 marca 2012, 12:57

Mam aplikację, która na pakiety UDP wysyłane na porty 8888, odpowiada pakietem UDP na port 8887:

tcpdump -vvvv -i gre-do-orange host 10.20.0.172

Kod: Zaznacz cały

12:27:10.428591 IP (tos 0x28, ttl 128, id 44, offset 0, flags [none], proto UDP (17), length 238)
    10.20.0.172.8887 > gpsdb.gps.pl.8888: [no cksum] UDP, length 210
12:27:10.434521 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 30)
    10.9.9.1.8888 > 10.20.0.172.8887: [udp sum ok] UDP, length 2

Ale jest jeden numer IP, który nie wiedzieć czemu, zachowuje się zupełnie inaczej. I nie wiem jak interpretować wynik:

Kod: Zaznacz cały

tcpdump -vvvv -i gre-do-orange host 10.20.0.178

Kod: Zaznacz cały

12:29:24.912689 IP (tos 0x28, ttl 128, id 1, offset 0, flags [none], proto UDP (17), length 55)
    10.20.0.178.8887 > gpsdb.gps.pl.8888: [no cksum] UDP, length 27
12:29:24.913225 IP (tos 0x0, ttl 127, id 42304, offset 0, flags [none], proto ICMP (1), length 83)
    gpsdb.gps.pl > 10.20.0.178: ICMP gpsdb.gps.pl udp port 8888 unreachable, length 63
        IP (tos 0x28, ttl 127, id 1, offset 0, flags [none], proto UDP (17), length 55)
    10.20.0.178.8887 > gpsdb.gps.pl.8888: [no cksum] UDP, length 27

Skąd tam ICMP?
Czy to 10.20.0.178 informuje gpsdb.pl, że jego port 8888 jest nieczynny,
czy też gpsdb.gps.pl informuje 10.20.0.178, że jego port 8888 jest nieczynny?

Bastian · Post autor: **Bastian** » 09 marca 2012, 14:43

czy też gpsdb.gps.pl informuje 10.20.0.178 że jego port 8888 jest nieczynny?

Tak własnie jest. Dlatego dostajesz ICMP z tym komunikatem. Sprawdz firewalla, i czy w ogóle masz włączony nasłuch na tym porcie.

sethiel · Post autor: **sethiel** » 12 marca 2012, 11:39

Dzięki.
Port jest otwarty bo całe mrowie urządzeń na niego się dobijało (skutecznie) oprócz tego jednego.
Firewall pokazywał brak reguł - wszystko akceptowane.
Najdziwniejsze w tym było to że dopiero po fizycznym restarcie serwera pomogło.
Czego bardzo a to bardzo chciałem uniknąć.
Wcześniej restartowałem po kolei każdy proces łącznie z opuszczaniem i podnoszeniem interfejsów sieciowych, czyszczeniem dla pewności reguł iptables i generalnie wszystko co mi do głowy przyszło.
Niestety to musiało zacząć działać za wszelką cenę więc niestety nie mogę eksperymentować dalej i próbować dojść co było nie tak.

Bastian · Post autor: **Bastian** » 12 marca 2012, 11:56

Ważne, że pomogło. Zrestartowałeś jądro, a wraz z nim to co powodowało problem (cokolwiek to było).

PS. Dlaczego fizyczny restart maszyny to takie zło? Zdarza się najlepszym i często jest pożądane.

sethiel · Post autor: **sethiel** » 12 marca 2012, 13:49

Dlaczego fizyczny restart maszyny to takie zło?

Bo to nie mój serwer.
Bo ludek który ma jakieś pojęcie co tam jest i dlaczego i dlaczego większość procesów powinna wstawać z ręki z czarodziejskimi parametrami jest w dużej odległości.
Bo cała reszta zainteresowanych stwierdziła zgodnie - zapewne nie wstanie i dopiero będzie dramat.
Powodów jak mrówków.