Server na SYN odpoví podivným ACK

[Dzavy]

Mam takovej dost specifickej problem s TCP:

C->S: Seq=0, Flags=SYN
S->C: Seq=1, Ack=1418096134, Flags=ACK
C->S: Seq=1418096134, Flags=RST

Takze server (RHEL6) z nejakyho duvodu potvrdi prijem neexistujiciho packetu a klienta to rozhodi. Klient pouziva sourceport-reuse, ale ten samej port byl pouzitej docela dlouho pred tim a spojeni bylo normalne ukonceno.

Nejaky napady co s tim muzu udelat na strane serveru? Tipuju to na nejaky TCP timery, ale moc se v tom neorientuju.

[Reklama]

[Ovrscout]

Přes netstat nebo nějakou takovou utilitu můžeš kouknout jaká tam máš spojení, případně v jakém visí stavu.
Na wiki je celkem slušný popis stavů https://en.wikipedia.org/wiki/Transmission_Control_Protocol .
Na http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/ je docela dobrý popis oblíbeného "problému" s TIME_WAIT.

Pokud je to mozne, doporucuju nahodit wireshark/pcap na obě strany komunikace (ehm,ale radej ne na ostrý server) a porovnat jestli to co vidí server je to samé co vidí klient a nepokazí se to někde cestou. A také se podívat že ani jedna ze stran se nepokouší vyjednávat nějaké nekompatibilní rozšíření pro to spojení. S trochou štěstí budou ve wiresharku vyznačené i případné chyby, nebo aspoň bude vidět co kdo jak a kdy posílá a kdy a jak to přiijde na druhou stranu.

Pokud najdeš co se skutečně děje, můžeš začít študovat a ptát se co stím. Ale nastavovat parametry tcp skusmo moc nedoporučuju(zejména v systémové konfiguraci, na socketu se dá ale také ledacos nastavit). Na některé problémy s TCP se dá třeba nasadit proxy která umí spojení killnout pokud je neaktivní, případně umí vložit keepalive atp, ale zas to může způsobovat jiné potíže. Každopádně je třeba být opatrný.

[Kolemjdoucí]

Mam takovej dost specifickej problem s TCP:

C->S: Seq=0, Flags=SYN
S->C: Seq=1, Ack=1418096134, Flags=ACK
C->S: Seq=1418096134, Flags=RST

Na první paket SYN se odjakživa odpovídá SYN+ACK a ne jen ACK jak to posílá ten hloupý server!

[Dzavy]

Přes netstat nebo nějakou takovou utilitu můžeš kouknout jaká tam máš spojení, případně v jakém visí stavu.
Na wiki je celkem slušný popis stavů https://en.wikipedia.org/wiki/Transmission_Control_Protocol .
Na http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/ je docela dobrý popis oblíbeného "problému" s TIME_WAIT.

Pokud je to mozne, doporucuju nahodit wireshark/pcap na obě strany komunikace (ehm,ale radej ne na ostrý server) a porovnat jestli to co vidí server je to samé co vidí klient a nepokazí se to někde cestou. A také se podívat že ani jedna ze stran se nepokouší vyjednávat nějaké nekompatibilní rozšíření pro to spojení. S trochou štěstí budou ve wiresharku vyznačené i případné chyby, nebo aspoň bude vidět co kdo jak a kdy posílá a kdy a jak to přiijde na druhou stranu.

Pokud najdeš co se skutečně děje, můžeš začít študovat a ptát se co stím. Ale nastavovat parametry tcp skusmo moc nedoporučuju(zejména v systémové konfiguraci, na socketu se dá ale také ledacos nastavit). Na některé problémy s TCP se dá třeba nasadit proxy která umí spojení killnout pokud je neaktivní, případně umí vložit keepalive atp, ale zas to může způsobovat jiné potíže. Každopádně je třeba být opatrný.

Na obou stranach spojeni je videt to samy. Klient to zkusi viz vyse, server posle divnej ack (ve Wiresharku jako "ACK unseen segment"), klient reset. Klient to pak zkusi o sekundu pozdeji znova ze stejnejho portu a projde to. V principu by to ani nebyl problem, akorat obcas na to je potreba 2 a vic pokusu a nektery spojeni na tom padaji kvuli connect-timeout=2.

Sahat muzu vicemene na obe strany, nicmene mi prijde, ze na tom serveru to dava vetsi smysl.

[Lol Phirae]

Klient pouziva sourceport-reuse

Tak to nepoužívej a budeš mít po problému.

[Reklama]

[madarska_sova]

ako je nastaveny firewall na clientovi + servrovi ? nestracaju sa packety/nezahadzuje to nieco medzi nimi ?