netdev - Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080819213417.45133573@tux>
Date:	Tue, 19 Aug 2008 21:34:17 -0300
From:	Dâniel Fraga <fragabr@...il.com>
To:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
Cc:	David Miller <davem@...emloft.net>, thomas.jarosch@...ra2net.com,
	billfink@...dspring.com, Netdev <netdev@...r.kernel.org>,
	Patrick Hardy <kaber@...sh.net>, sr@...urenet.de,
	netfilter-devel@...r.kernel.org, kadlec@...ckhole.kfki.hu
Subject: Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility
 workaround

On Tue, 19 Aug 2008 13:38:35 +0300 (EEST)
"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi> 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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html