Ok, zdaję sobie sprawę, że ta sytuacja jest nieco nietypowa, ale muszę ustanowić połączenie TCP (3-drożne uzgadnianie) przy użyciu tylko surowych gniazd (w C, w Linuksie) - tj. Muszę skonstruować nagłówki IP i nagłówki TCP samodzielnie . Piszę serwer (więc muszę najpierw odpowiedzieć na przychodzący pakiet SYN) iz jakiegoś powodu nie mogę tego zrobić poprawnie. Tak, zdaję sobie sprawę, że SOCK_STREAM zajmie się tym dla mnie, ale z powodów, dla których nie chcę tego robić, nie jest to opcja.

Samouczki, które znalazłem w Internecie na temat używania surowych gniazd, opisują, jak zbudować flooder SYN, ale jest to nieco łatwiejsze niż ustanowienie połączenia TCP, ponieważ nie trzeba konstruować odpowiedzi na podstawie oryginalnego pakietu. Pracuję nad przykładami SYN flooder i mogę dobrze odczytać przychodzący pakiet SYN z surowego gniazda, ale nadal mam problemy z utworzeniem prawidłowej odpowiedzi SYN / ACK na przychodzący SYN od klienta.

Czy więc ktoś zna dobry samouczek dotyczący używania surowych gniazd, które wykraczają poza tworzenie flooda SYN, czy też ktoś ma jakiś kod, który mógłby to zrobić (używając SOCK_RAW, a nie SOCK_STREAM)? Była bym bardzo wdzięczna.

MarkR ma absolutną rację - problem polega na tym, że jądro wysyła pakiety resetowania w odpowiedzi na początkowy pakiet, ponieważ uważa, że ​​port jest zamknięty. Jądro bije mnie na odpowiedź i połączenie ginie. Używam tcpdump do monitorowania połączenia już - powinienem był być bardziej spostrzegawczy i zauważyłem, że były DWIE odpowiedzi, z których jedna była resetem, który spieprzył sprawę, jak również reakcją mojego programu. D'OH!

Rozwiązaniem, które wydaje się działać najlepiej, jest użycie reguły iptables, zgodnie z sugestią MarkR, do blokowania pakietów wychodzących. Jednak jest to łatwiejszy sposób niż użycie opcji oznaczania, jak sugerowano. Po prostu dopasowuję, czy flaga resetowania TCP jest ustawiona. W trakcie normalnego połączenia jest mało prawdopodobne, i nie ma to większego znaczenia dla mojej aplikacji, jeśli zablokuję wszystkie wychodzące pakiety resetowania z używanego portu. To skutecznie blokuje niepożądaną odpowiedź jądra, ale nie moje własne pakiety. Jeśli port, na którym program nasłuchuje, to 9999, wtedy reguła iptables wygląda tak:

iptables -t filter -I OUTPUT -p tcp --sport 9999 --tcp-flags RST RST -j DROP