Kicsit fura ez a tcpdump kimenet, de pár anomália látszik.
- Egyrészt ahogy fentebb mondták, a helyes sorrend SYN, SYN|ACK, ACK. A vissza jövő nem tudni mire ACKot egy jól szituált stateful csomagszűrő el fogja dobni, mert még nincs a connection established állapotban.
- Másrészt elég látványos, hogy TCP proto 74en jön be a kérés, és 54en megy ki, ami, hát elég gyanús, ráadásul ilyen elborult izék ja, az a length, nem szóltam
- kissé fura, hogy seq=0 és 1 miközben az ACK valami rendesnek látszó sequence numberre van (az a normális, hogy a seq number nem 0-val kezdődik). Persze lehet, hogy az ott nem a seq number csak valami absztrakció, jó volna látni az igazit.
"Linux tűzfal kizárva, mert alaposan utánaolvastam és a tcpdump a bejövő csomagokat még az iptables előtt rögzíti" -> ebből pont az következik, hogy bizony akár még a szerver tűzfala is el tudja dobni a hibás ACKt. Mondjuk ha tippelnem kellene, inkább valamelyik router csinálja, mert ez már max az OUTPUTon akadna fent, ott meg nem szokott szabály lenni sűrűn Meg akkor jó eséllyel nem is látszana a dumpban, mert:
Ráadásul az van, hogy ez a kijelentés nem is teljesen igaz. A tcpdump a kártyán captureol (kissé pongyolán fogalmazva), szóval befele a local tűzfal előtt, kifele viszont utána. Vagyis befele még látod, ha eldobja is majd, kifele viszont nem látod, amit eldobott. Szóval simán lehet, hogy a local tűzfal dobta el a SYN|ACKot és nem látod. Mondjuk, hogy akkor mire válasz az az ACK
Szóval de, ez egyébként valami szerver oldali elkeffnek tűnik, vagy a tűzfalban, vagy a network stackben, vagy az alkalmazás hálózat kezelésében (ez a legkevésbé valószínű, de java alkalmazást láttam már hasonló szitut szarul kezelni)