Date: Tue, 2 Dec 2008 15:10:11 -0500 From: "Benjie Chen" <benjie@addgene.org> To: freebsd-net@freebsd.org Subject: Weird TCP connect issue in FreeBSD 6 Message-ID: <c53be070812021210u736bef58v79c2f80785308a5@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi
I have a weird issue to report, and I am not sure if it's a bug or
some other configuration problem.
Server is a dual NICed FreeBSD 6.2 system. For example, one NIC is em0
= 192.168.0.1, and the other one is em1 = 192.168.0.2.
I have an Apache server listening on 80 and 443 on both IP addresses.
So we have 0.1:80, 0.1:443, 0.2:80, 0.2:443
Connections to 0.1:80, 0.1:443, 0.2:80, I have not experienced any problems.
Connections to 0.2:443, however, I get frequently connection issues.
I am connecting using telnet -- eg: telnet 192.168.0.2 443
Sometimes the connection would be established (past accept, I get to
type something or ^]q out of telnet). Sometimes, however, immediately
after connect is established, the connection would be terminated.
I traced the problem by running tcpdump -p on em0 and em1, as well as
a tcpdump on the same subnet as the client (which is on a whole
different network).
Packets to 0.2 are definitely arriving on em1, but responses from 0.2
back to client go out em0. This is just because of the default route.
Here is what's happening on the failed/terminated connects:
1. client sends SYN to 0.2:443
2. 0.2:443 responds with SYN ACK
3. on tcpdumps on server, we see that before the SYN ACK from step 2
even reaches the client,
we get repeated SYN packets to 0.2:443, and repeated (as
expected) SYN ACK for each of the packet.
we do not see the repeated SYNs on the tcpdump on the client network
4. step 3 goes on for a long time, even after the SYN ACK reaches
client and client respond with an ACK
5. client receives a bunch of SYN ACK, and sends an ACK for each
6. at some point, I believe FreeBSD syn attack prevention kicks in
and a RST is set to the server, connection
is then terminated.
Interesting observations: this does not happen all the time, just
sometimes. This also does not happen (at least I can't get it to
occur) for 0.2:80, or
any of the 0.1:80 or 0.1:443 ports.
I just switched to using IP aliasing on the same NIC, and so far I
have not been able to re-produce the same problem.
I am not familiar with the SYN cache/cookie code in FreeBSD, but is it
possible that the dual NIC is confusing that piece of code, and in
some cases, it does not see the SYN ACK from the server and
retransmits the SYN? Something is retransmitting the SYN packets!
If anyone has any information on this, please help!
Thanks,
Benjie
---
Benjie Chen, Ph.D.
Addgene, a better way to share plasmids
www.addgene.org
Manage your lab more efficiently
Addgene Labs - www.addgenelabs.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c53be070812021210u736bef58v79c2f80785308a5>