2.6.17.1: fails to fully get webpage

2.6.17.1: fails to fully get webpage

[CaT]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

I had recently upgraded to 2.6.17.1 and tried to go to

http://submit.spam.acma.gov.au/acma_submit.cgi?lang=EN

to report an australian spammer. Unfortunately the loading of the
webpage cuts out at 5472 bytes. I can repeat this each and every time
under 2.6.17.1 with

( echo 'get /acma_submit.cgi?lang=EN http/1.1'; echo 'Host: submit.spam.acma.gov.au'; echo ) | nc submit.spam.acma.gov.au 80

Under 2.6.16.18 the site works without problems.

Now I found a thread about tcp window scaling affecting the loading of
some sites but I fail to load the above site with
/proc/sys/net/ipv4/tcp_adv_win_scale set to 6 and 2 under 2.6.17.1
whilst it works just fine with the /proc entry set to either 7, 6 or 2
under 2.6.16.18.

I have attached a tcpdump of the transaction under 2.6.17.1 and a copy
of the networking section of the .config. If there's any more info
required I'll do my best to grab it.

-- 
    "To the extent that we overreact, we proffer the terrorists the
    greatest tribute."
    	- High Court Judge Michael Kirby

[-- Attachment #2: wscale --]
[-- Type: text/plain, Size: 1720 bytes --]

16:28:51.829502 IP 192.168.1.93.49140 > 210.193.176.194.80: S 3496794602:3496794
602(0) win 5840 <mss 1460,sackOK,timestamp 4294784053 0,nop,wscale 7>
16:28:51.841919 IP 210.193.176.194.80 > 192.168.1.93.49140: S 4198909797:4198909
797(0) ack 3496794603 win 5792 <mss 1380,sackOK,timestamp 2593750330 4294784053,
nop,wscale 2>
16:28:51.841995 IP 192.168.1.93.49140 > 210.193.176.194.80: . ack 1 win 46 <nop,nop,timestamp 4294784065 2593750330>
16:28:51.842111 IP 192.168.1.93.49140 > 210.193.176.194.80: P 1:466(465) ack 1 win 46 <nop,nop,timestamp 4294784065 2593750330>
16:28:51.849376 IP 210.193.176.194.80 > 192.168.1.93.49140: . ack 466 win 1716 <nop,nop,timestamp 2593750332 4294784065>
16:28:52.184832 IP 210.193.176.194.80 > 192.168.1.93.49140: . 1:1369(1368) ack 466 win 1716 <nop,nop,timestamp 2593750416 4294784065>
16:28:52.184875 IP 192.168.1.93.49140 > 210.193.176.194.80: . ack 1369 win 69 <nop,nop,timestamp 4294784408 2593750416>
16:28:52.187593 IP 210.193.176.194.80 > 192.168.1.93.49140: . 1369:2737(1368) ack 466 win 1716 <nop,nop,timestamp 2593750416 4294784065>
16:28:52.187632 IP 192.168.1.93.49140 > 210.193.176.194.80: . ack 2737 win 91 <nop,nop,timestamp 4294784411 2593750416>
16:28:52.187801 IP 210.193.176.194.80 > 192.168.1.93.49140: P 2737:4105(1368) ack 466 win 1716 <nop,nop,timestamp 2593750416 4294784065>
16:28:52.187824 IP 192.168.1.93.49140 > 210.193.176.194.80: . ack 4105 win 114 <nop,nop,timestamp 4294784411 2593750416>
16:28:52.194277 IP 210.193.176.194.80 > 192.168.1.93.49140: . 4105:5473(1368) ack 466 win 1716 <nop,nop,timestamp 2593750418 4294784408>
16:28:52.194337 IP 192.168.1.93.49140 > 210.193.176.194.80: . ack 5473 win 137 <nop,nop,timestamp 4294784418 2593750418>

[-- Attachment #3: config.net --]
[-- Type: text/plain, Size: 6547 bytes --]

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
CONFIG_NET_KEY=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_XFRM_TUNNEL=y
CONFIG_INET_TUNNEL=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_QUEUE=y
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y
CONFIG_NETFILTER_XT_TARGET_CONNMARK=y
CONFIG_NETFILTER_XT_TARGET_MARK=y
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y
CONFIG_NETFILTER_XT_TARGET_NOTRACK=y
CONFIG_NETFILTER_XT_MATCH_COMMENT=y
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=y
CONFIG_NETFILTER_XT_MATCH_CONNMARK=y
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
CONFIG_NETFILTER_XT_MATCH_DCCP=y
CONFIG_NETFILTER_XT_MATCH_ESP=y
CONFIG_NETFILTER_XT_MATCH_HELPER=y
CONFIG_NETFILTER_XT_MATCH_LENGTH=y
CONFIG_NETFILTER_XT_MATCH_LIMIT=y
CONFIG_NETFILTER_XT_MATCH_MAC=y
CONFIG_NETFILTER_XT_MATCH_MARK=y
CONFIG_NETFILTER_XT_MATCH_POLICY=y
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y
CONFIG_NETFILTER_XT_MATCH_REALM=y
CONFIG_NETFILTER_XT_MATCH_SCTP=y
CONFIG_NETFILTER_XT_MATCH_STATE=y
CONFIG_NETFILTER_XT_MATCH_STRING=y
CONFIG_NETFILTER_XT_MATCH_TCPMSS=y

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_CT_ACCT=y
CONFIG_IP_NF_CONNTRACK_MARK=y
CONFIG_IP_NF_CONNTRACK_EVENTS=y
CONFIG_IP_NF_CONNTRACK_NETLINK=y
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IRC=y
CONFIG_IP_NF_NETBIOS_NS=y
CONFIG_IP_NF_TFTP=y
CONFIG_IP_NF_AMANDA=y
CONFIG_IP_NF_PPTP=y
CONFIG_IP_NF_H323=y
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_MATCH_HASHLIMIT=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
CONFIG_IP_NF_NAT_IRC=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_NAT_TFTP=y
CONFIG_IP_NF_NAT_AMANDA=y
CONFIG_IP_NF_NAT_PPTP=y
CONFIG_IP_NF_NAT_H323=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_DSCP=y
CONFIG_IP_NF_TARGET_TTL=y
# CONFIG_IP_NF_TARGET_CLUSTERIP is not set
CONFIG_IP_NF_RAW=y
# CONFIG_IP_NF_ARPTABLES is not set

#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set

#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
CONFIG_NET_CLS_ROUTE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set

#
# Device Drivers
#
...
#
# Network device support
#
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# PHY device support
#
# CONFIG_PHYLIB is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
CONFIG_E100=y
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=y
# CONFIG_PPP_MULTILINK is not set
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=y
CONFIG_PPP_SYNC_TTY=y
CONFIG_PPP_DEFLATE=y
CONFIG_PPP_BSDCOMP=y
CONFIG_PPP_MPPE=y
CONFIG_PPPOE=y
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_MON is not set

Re: 2.6.17.1: fails to fully get webpage

[David Miller]

From: CaT <cat@zip.com.au>
Date: Thu, 29 Jun 2006 11:59:15 +1000

> Now I found a thread about tcp window scaling affecting the loading of
> some sites but I fail to load the above site with
> /proc/sys/net/ipv4/tcp_adv_win_scale set to 6 and 2 under 2.6.17.1
> whilst it works just fine with the /proc entry set to either 7, 6 or 2
> under 2.6.16.18.

You must have misread those threads.  To work around the problem,
you don't modify tcp_adv_win_scale, instead what you do is set
tcp_window_scaling to 0.

Re: 2.6.17.1: fails to fully get webpage

[CaT]

On Wed, Jun 28, 2006 at 07:46:27PM -0700, David Miller wrote:
> From: CaT <cat@zip.com.au>
> Date: Thu, 29 Jun 2006 11:59:15 +1000
> 
> > Now I found a thread about tcp window scaling affecting the loading of
> > some sites but I fail to load the above site with
> > /proc/sys/net/ipv4/tcp_adv_win_scale set to 6 and 2 under 2.6.17.1
> > whilst it works just fine with the /proc entry set to either 7, 6 or 2
> > under 2.6.16.18.
> 
> You must have misread those threads.  To work around the problem,
> you don't modify tcp_adv_win_scale, instead what you do is set
> tcp_window_scaling to 0.

Yup. Must've. Just tried it now and setting tcp_window_scaling to 0
makes the site load. Sorry about that. Looks like I'll have to remember
to make sure that gets set to zero on any servers I wind up having to
upgrade to 2.6.17 and beyond.

Bugger. :/

-- 
    "To the extent that we overreact, we proffer the terrorists the
    greatest tribute."
    	- High Court Judge Michael Kirby

Re: 2.6.17.1: fails to fully get webpage

[David Miller]

From: CaT <cat@zip.com.au>
Date: Thu, 29 Jun 2006 13:09:23 +1000

> Yup. Must've. Just tried it now and setting tcp_window_scaling to 0
> makes the site load. Sorry about that. Looks like I'll have to remember
> to make sure that gets set to zero on any servers I wind up having to
> upgrade to 2.6.17 and beyond.
> 
> Bugger. :/

You can save yourself that hassle by informing the site admin
of the affected site that they have a firewall that misinterprets
the RFC standard window scaling field of the TCP headers.  These
devices assume it is zero because they don't remember the window
scale negotiated at the beginning of the TCP connection.

Your TCP performance will suffer greatly if you disable window
scaling across the board.  It means that only a 64K window will
be usable by TCP, and you'll not be able to fill the pipe.

Please don't use a screwdriver to pound in a nail :)

Re: 2.6.17.1: fails to fully get webpage

[CaT]

On Wed, Jun 28, 2006 at 08:47:09PM -0700, David Miller wrote:
> You can save yourself that hassle by informing the site admin
> of the affected site that they have a firewall that misinterprets
> the RFC standard window scaling field of the TCP headers.  These
> devices assume it is zero because they don't remember the window
> scale negotiated at the beginning of the TCP connection.
> 
> Your TCP performance will suffer greatly if you disable window
> scaling across the board.  It means that only a 64K window will
> be usable by TCP, and you'll not be able to fill the pipe.
> 
> Please don't use a screwdriver to pound in a nail :)

Indeed. The hassle I'm thinking of is the reverse situation (and please
correct me if this does not apply). Say for example I run a web server.
I have customers and they have customers (lets call them CCs :). Somewhere
along the path between me and CCs there is such a misbehaving device.
The CCs try to get to my customers website and fail (I assume). If my
assumption is right, what's the probability of the CCs ever informing my
customer that there is a problem? I think it's more likely they would
just move on to another site offering the same thing, especially since
they would mostlikely need to load the site in order to get the
appropriate contact details.

Basically the mostlikely end-result is I don't know what there is a
problem and my customer doesn't know that there is a problem but they're
just not getting as many hits to their site that they otherwise would.

Ofcourse, this all depends if such a situation is possible. If it is
possible would it affect dns and mail in a similar manner too?

-- 
    "To the extent that we overreact, we proffer the terrorists the
    greatest tribute."
    	- High Court Judge Michael Kirby

Re: 2.6.17.1: fails to fully get webpage

[Bill Davidsen]

CaT wrote:
> On Wed, Jun 28, 2006 at 08:47:09PM -0700, David Miller wrote:
>> You can save yourself that hassle by informing the site admin
>> of the affected site that they have a firewall that misinterprets
>> the RFC standard window scaling field of the TCP headers.  These
>> devices assume it is zero because they don't remember the window
>> scale negotiated at the beginning of the TCP connection.
>>
>> Your TCP performance will suffer greatly if you disable window
>> scaling across the board.  It means that only a 64K window will
>> be usable by TCP, and you'll not be able to fill the pipe.
>>
>> Please don't use a screwdriver to pound in a nail :)
> 
> Indeed. The hassle I'm thinking of is the reverse situation (and please
> correct me if this does not apply). Say for example I run a web server.
> I have customers and they have customers (lets call them CCs :). Somewhere
> along the path between me and CCs there is such a misbehaving device.
> The CCs try to get to my customers website and fail (I assume). If my
> assumption is right, what's the probability of the CCs ever informing my
> customer that there is a problem? I think it's more likely they would
> just move on to another site offering the same thing, especially since
> they would mostlikely need to load the site in order to get the
> appropriate contact details.
> 
> Basically the mostlikely end-result is I don't know what there is a
> problem and my customer doesn't know that there is a problem but they're
> just not getting as many hits to their site that they otherwise would.
> 
> Ofcourse, this all depends if such a situation is possible. If it is
> possible would it affect dns and mail in a similar manner too?
> 
I'm glad David Miller clarified this, because I was about to send a 
"don't do that" followup ;-)

But your example is misleading, or at least doesn't reflect customers I 
know. While a few clients with broken network connections may be 
unhappy, disabling scaling will make your web server really, really, 
slow, and that will make everyone unhappy. Particularly if the web 
content is flash or 2MB jpegs, or other ill-chosen stuff. You don't want 
people to think you are running at dial-up speeds.

-- 
Bill Davidsen <davidsen@tmr.com>
   Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.

Re: 2.6.17.1: fails to fully get webpage

[CaT]

On Thu, Jun 29, 2006 at 10:50:00AM -0400, Bill Davidsen wrote:
> >Basically the mostlikely end-result is I don't know what there is a
> >problem and my customer doesn't know that there is a problem but they're
> >just not getting as many hits to their site that they otherwise would.
> >
> >Ofcourse, this all depends if such a situation is possible. If it is
> >possible would it affect dns and mail in a similar manner too?
> >
> I'm glad David Miller clarified this, because I was about to send a 
> "don't do that" followup ;-)

:) I don't know how I got the wrong config option to modify but there
you go. :)

> But your example is misleading, or at least doesn't reflect customers I 
> know. While a few clients with broken network connections may be 
> unhappy, disabling scaling will make your web server really, really, 
> slow, and that will make everyone unhappy. Particularly if the web 
> content is flash or 2MB jpegs, or other ill-chosen stuff. You don't want 
> people to think you are running at dial-up speeds.

Which would be why I wont move from 2.6.16.x for my servers unless I
really, really, really have to. I don't know how many broken sites are
out there and I cannot tell.

Another datapoint to this is that I've had this my netcat web test
running since 8:42pm yesterday. It's 8:37am now. It hasn't progressed
in any way. It hasn't quit. It hasn't timed out. It just sits there,
hung. This leads me to consider the possibility of a DOS, either
intentional or accidental (think about 2.6.17.x running on a mail server
and someone mails/spams from a broken place).

-- 
    "To the extent that we overreact, we proffer the terrorists the
    greatest tribute."
    	- High Court Judge Michael Kirby

possible dos / wsize affected frozen connection length (was: Re: 2.6.17.1: fails to fully get webpage)

[CaT]

On Fri, Jun 30, 2006 at 08:50:39AM +1000, CaT wrote:
> Another datapoint to this is that I've had this my netcat web test
> running since 8:42pm yesterday. It's 8:37am now. It hasn't progressed
> in any way. It hasn't quit. It hasn't timed out. It just sits there,
> hung. This leads me to consider the possibility of a DOS, either
> intentional or accidental (think about 2.6.17.x running on a mail server
> and someone mails/spams from a broken place).

I'm just wondering if connections hanging around this long are normal.
The above has now been running for 6 days. netstat is still reporting an
established session. netcat has not timed out. It's all just sitting
there doing nothing.

-- 
    "To the extent that we overreact, we proffer the terrorists the
    greatest tribute."
    	- High Court Judge Michael Kirby

Re: possible dos / wsize affected frozen connection length (was: Re: 2.6.17.1: fails to fully get webpage)

[linux-os (Dick Johnson)]

On Tue, 4 Jul 2006, CaT wrote:

> On Fri, Jun 30, 2006 at 08:50:39AM +1000, CaT wrote:
>> Another datapoint to this is that I've had this my netcat web test
>> running since 8:42pm yesterday. It's 8:37am now. It hasn't progressed
>> in any way. It hasn't quit. It hasn't timed out. It just sits there,
>> hung. This leads me to consider the possibility of a DOS, either
>> intentional or accidental (think about 2.6.17.x running on a mail server
>> and someone mails/spams from a broken place).
>
> I'm just wondering if connections hanging around this long are normal.
> The above has now been running for 6 days. netstat is still reporting an
> established session. netcat has not timed out. It's all just sitting
> there doing nothing.
>
> --

>    "To the extent that we overreact, we proffer the terrorists the
>    greatest tribute."
>    	- High Court Judge Michael Kirby

TCP/IP connections can continue forever. That's one of the reasons why
Berkeley sockets has SO_KEEPALIVE for a socket option. In the absence
of such an option, the physical connection can be broken for a week,
reconnected, then the session can continue.

In your case, you probably have a real error in which one end of the
connection crashed. However, until the other end shuts down that
socket, the connection is logically correct and should not be
forcefully terminated.

A DOS is unlikely because with no data being transferred, little
non-swapable resources are used. You can control the maximum number
of connections allowed from a host with your firewall software
(like iptables).

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.86 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: possible dos / wsize affected frozen connection length (was: Re: 2.6.17.1: fails to fully get webpage)

[CaT]

On Wed, Jul 05, 2006 at 07:54:01AM -0400, linux-os (Dick Johnson) wrote:
> >> running since 8:42pm yesterday. It's 8:37am now. It hasn't progressed
> >> in any way. It hasn't quit. It hasn't timed out. It just sits there,
> >> hung. This leads me to consider the possibility of a DOS, either
> >> intentional or accidental (think about 2.6.17.x running on a mail server
> >> and someone mails/spams from a broken place).
> 
> TCP/IP connections can continue forever. That's one of the reasons why
> Berkeley sockets has SO_KEEPALIVE for a socket option. In the absence
> of such an option, the physical connection can be broken for a week,
> reconnected, then the session can continue.

D'oh. I knew that. Sigh. It's one of the things I like about having a
static ip on a bad connection. :)

> In your case, you probably have a real error in which one end of the
> connection crashed. However, until the other end shuts down that

Well not so much crashed but became unreachable due to the wsize thing.

> socket, the connection is logically correct and should not be
> forcefully terminated.

It'll never terminate right now unless I hit ^c.

> A DOS is unlikely because with no data being transferred, little

Not all DOS' are transfer based. Just anything that uses up resources to
the point where a service is no longer able to be performed.

> non-swapable resources are used. You can control the maximum number
> of connections allowed from a host with your firewall software
> (like iptables).

After the fact really. In this case one can send mail to a box and make
it bounce to someplace behind a wsize broken network. Resources taken up
that wont return until someone spots what's wrong. You could make your
own wsize broken network, connect to someplace a few times and then move
on whilst their end hangs around, waiting for the connections to do
somthing.

In my test case I am wondering if there was/is a web process hanging
about doing nothing other then waiting for my end to do something.

-- 
    "To the extent that we overreact, we proffer the terrorists the
    greatest tribute."
    	- High Court Judge Michael Kirby

Re: possible dos / wsize affected frozen connection length

[Herbert Xu]

CaT <cat@zip.com.au> wrote:
> 
> I'm just wondering if connections hanging around this long are normal.
> The above has now been running for 6 days. netstat is still reporting an
> established session. netcat has not timed out. It's all just sitting
> there doing nothing.

TCP connections without keepalives can sit there for all eternity,
if your machine lasts that long :)
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt