David Gubler a écrit : > > Starting a fifth download fails: > > $ wget --limit-rate=1 http://localhost:8080/.... > --2013-02-04 11:48:41-- http://localhost:8080/... > Auflösen des Hostnamen »localhost (localhost)«... 127.0.0.1 > Verbindungsaufbau zu localhost (localhost)|127.0.0.1|:8080... fehlgeschlagen: Verbindungsaufbau abgelehnt. > (connection rejected) > > # conntrack -L | grep 8080 > tcp 6 431949 ESTABLISHED src=127.0.0.1 dst=127.0.0.1 sport=60279 dport=8080 src=127.0.0.1 dst=127.0.0.1 sport=8080 dport=60279 [ASSURED] mark=0 use=1 > tcp 6 431990 ESTABLISHED src=127.0.0.1 dst=127.0.0.1 sport=60278 dport=8080 src=127.0.0.1 dst=127.0.0.1 sport=8080 dport=60278 [ASSURED] mark=0 use=1 > tcp 6 431956 ESTABLISHED src=127.0.0.1 dst=127.0.0.1 sport=60284 dport=8080 src=127.0.0.1 dst=127.0.0.1 sport=8080 dport=60284 [ASSURED] mark=0 use=1 > tcp 6 431963 ESTABLISHED src=127.0.0.1 dst=127.0.0.1 sport=60285 dport=8080 src=127.0.0.1 dst=127.0.0.1 sport=8080 dport=60285 [ASSURED] mark=0 use=1 > tcp 6 71 SYN_SENT src=127.0.0.1 dst=127.0.0.1 sport=60291 dport=8080 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 sport=8080 dport=60291 mark=0 use=1 > > Note: The rejected connection is in the conntrack table in the state SYN_SENT. It appears that you're testing over the loopback interface. Note that the connection tracking behaves a bit differently on this interface : the connection is confirmed when the first packet reaches the end of POSTROUTING chains, before entering back the PREROUTING and INPUT chains. So even though the packet is dropped in the INPUT chain, the conntrack entry is not new any more and left in the SYN_STATE. > Killing one of the four running downloads with CTRL+C: > > # conntrack -L | grep 8080 > tcp 6 431950 ESTABLISHED src=127.0.0.1 dst=127.0.0.1 sport=60279 dport=8080 src=127.0.0.1 dst=127.0.0.1 sport=8080 dport=60279 [ASSURED] mark=0 use=1 > tcp 6 7 CLOSE src=127.0.0.1 dst=127.0.0.1 sport=60278 dport=8080 src=127.0.0.1 dst=127.0.0.1 sport=8080 dport=60278 [ASSURED] mark=0 use=1 > tcp 6 431958 ESTABLISHED src=127.0.0.1 dst=127.0.0.1 sport=60284 dport=8080 src=127.0.0.1 dst=127.0.0.1 sport=8080 dport=60284 [ASSURED] mark=0 use=1 > tcp 6 431965 ESTABLISHED src=127.0.0.1 dst=127.0.0.1 sport=60285 dport=8080 src=127.0.0.1 dst=127.0.0.1 sport=8080 dport=60285 [ASSURED] mark=0 use=1 > tcp 6 17 SYN_SENT src=127.0.0.1 dst=127.0.0.1 sport=60291 dport=8080 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 sport=8080 dport=60291 mark=0 use=1 > > Now we have a connection in state CLOSED and one in state SYN_SENT in > the table. wget still fails as it did before. As expected, as there are already four active (SYN_SENT and ESTABLISHED) connections. > On 03.02.2013 12:51, Pascal Hambourg wrote: > > > > This is not the expected behaviour. AFAIK, when a packet creating a new > > connection is DROPPed or REJECTed, the conntrack entry should be > > deleted. This is what I observe on my system. Edit : I observe this if the connections are from a remote host. If the connections are from the local host over loopback, I observer the same behaviour as you. I tested both conditions with a Debian Squeeze 2.6.32 kernel. I could not test with other kerne versions. > Ok this is weird. I have made a similar (although not exactly the > same) attempt on "Linux 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC > 2012 x86_64 GNU/Linux" (Debian stable with stock kernel). On that kernel > it behaves as you describe it! No SYN_SENT entries pop up in the > conntrack table, instead the denied connections directly go into > TIME_WAIT, and the connection limit works fine. > > On "Linux 3.2.0-2-amd64 #1 SMP Mon Jun 11 17:24:18 UTC 2012 x86_64 > GNU/Linux" (Debian stable with backports kernel), on the other hand, I > get the exact same behavior as with 3.2 in Ubuntu (broken). Did you test all kernels in the exact same conditions, connecting either from a remote host or over loopback ? -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
