On Tue, 19 Aug 2008 13:38:35 +0300 (EEST)
"Ilpo Järvinen" [off-list ref] wrote:

Perhaps, though it's not at all clear how it could do that...

	I was thinking here of of some specific configuration I use.
For example, I always used the wonder shaper htb script:

http://lartc.org/howto/lartc.cookbook.ultimate-tc.html#AEN2241

	Could HTB mess with frto or cause this problem? Would it be
useful to disable completely HTB and use just the default scheduler?

Do you have net namespaces enabled CONFIG_NET_NS in .config?

	I couldn't find this specific option:

fraga@tux /usr/src/linux$ grep CONFIG_NET_NS .config
fraga@tux /usr/src/linux$ 

	But I have those:

fraga@tux /usr/src/linux$ grep CONFIG_NET_ .config
# CONFIG_NET_KEY is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
CONFIG_NET_SCHED=y
# CONFIG_NET_SCH_CBQ is not set
CONFIG_NET_SCH_HTB=m
# CONFIG_NET_SCH_HFSC is not set
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
# CONFIG_NET_SCH_TEQL is not set
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_BASIC is not set
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_NET_CLS_RSVP=m
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_CLS_FLOW is not set
# CONFIG_NET_EMATCH is not set
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=y
# CONFIG_NET_ACT_GACT is not set
# CONFIG_NET_ACT_MIRRED is not set
# CONFIG_NET_ACT_IPT is not set
# CONFIG_NET_ACT_NAT is not set
# CONFIG_NET_ACT_PEDIT is not set
# CONFIG_NET_ACT_SIMP is not set
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_SCH_FIFO=y
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_9P is not set
# CONFIG_NET_SB1000 is not set
CONFIG_NET_ETHERNET=y
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_TULIP is not set
CONFIG_NET_PCI=y
# CONFIG_NET_POCKET is not set
# CONFIG_NET_FC is not set
# CONFIG_NET_POLL_CONTROLLER is not set

	And that:

fraga@tux /usr/src/linux$ grep NAMESPACE .config
CONFIG_NAMESPACES=y

	but this one, I think, isn't related to what you asked me.

Any netfilter (iptables) rules on server which could cause those packets 
to not reach TCP layer?

	Here are the complete rules:

# Generated by iptables-save v1.3.8 on Tue Aug 19 21:28:12 2008
*filter
:INPUT DROP [627:34387]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [58771289:83128359870]
:DROP_INPUT - [0:0]
:FLDR - [0:0]
:LDR - [0:0]
-A INPUT -i lo -j ACCEPT 
-A INPUT -j DROP_INPUT 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p tcp -m multiport --dports 80,21,25,53,119,443,873,993,995
-A INPUT -s 192.168.102.1 -p tcp -m tcp --dport 3493 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT 
-A INPUT -p udp -m udp --dport 53 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 113 -j REJECT --reject-with tcp-reset 
-A INPUT -p udp -m udp --dport 1194:1196 -j ACCEPT 
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT 
-A INPUT -j LDR 
-A FORWARD -j FLDR 
-A DROP_INPUT -s 216.201.112.111 -m comment --comment "deborahsafe Spam" -j DROP 
-A DROP_INPUT -s 200.49.247.241 -p tcp -m tcp --dport 22 -j DROP 
-A DROP_INPUT -s 189.70.204.3 -p tcp -m tcp --dport 21 -j DROP 
-A DROP_INPUT -s 189.70.204.3 -p tcp -m tcp --dport 21 -j DROP 
-A DROP_INPUT -s 189.70.204.3 -p tcp -m tcp --dport 21 -j DROP 
-A FLDR -j LOG --log-prefix "DROP [FORWARD]: " --log-level 6 --log-ip-options 
-A FLDR -j DROP 
-A LDR -j LOG --log-prefix "DROP [INPUT]: " --log-level 6 --log-ip-options 
-A LDR -j DROP 
COMMIT
# Completed on Tue Aug 19 21:28:13 2008

	As you can see, it's a preetty simple set of rules, nothing exotic here.

MIBs might give some clue why those segments didn't get accepted. Most 
interesting ones are PAWSEstab, TCPAbortOnSyn and InErrs. One can use 
/bin/cut to read those from the one-line files if one wants to (however,
I attached a script which transposes them to get them somewhat 
human-readable). Also having the /proc/net/tcp output from the server 
while stalling would be (have been) useful to reveal state info (but I 
should have remembered to ask you to run it on both of them :-)). 

	Ok ;) No problem, when I get the problem, I'll provide you the requested 
information.

Also, I wonder what that [|tcp] hides, e.g., "<nop,nop,timestamp 
15980976 70381399,nop,nop,[|tcp]>" in tcpdump (and that was for an ACK 
which doesn't make too much sense to me there). It occurs because 
snaplen which was given for tcpdump is small enough to make TCP header 
partial.

	Hmmm, I don't know. This is complex to me, but I'll apply your script.

	Thank you!

-- 
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html