Hi all.
First of all, excuse my (poor) english, i'm french.
Me and a friend have discover a stange behaviour since kernel 2.6.17.
Let me explain.
We use to go to a ssh website, our bank website. One day my friend has
notice than he cannot acces this site from his linux workstation, but
can from his windows workstation. On my side, i still access on this
website form my linux workstation. And several days laters i notice i
can access this website too from my workstation, but my linux laptop on
the same network can...
After many tests, we have found that the problem is linked with kernel
version. We don't have the same linux distribution (i'm on slackware
current, he is on a debian unstable), but the same behaviour.
Let see the tests i have made, on the same machine, with two kernel:
2.4.33 and 2.6.17.13:
First test:
darkstar@stchesmeli:~$ uname -a
Linux stchesmeli 2.4.33.3 #1 Fri Sep 1 01:48:52 CDT 2006 i686 pentium4
i386 GNU/Linux
wget --no-check-certificate "https://e.secure.lcl.fr/v_1.0/css/styleAp.css"
--11:17:58-- https://e.secure.lcl.fr/v_1.0/css/styleAp.css
=> `styleAp.css.8'
Resolving e.secure.lcl.fr... 193.110.152.59
Connecting to e.secure.lcl.fr|193.110.152.59|:443... connected.
WARNING: Certificate verification error for e.secure.lcl.fr: unable to
get local issuer certificate
HTTP request sent, awaiting response... 200 OK
Length: 42,745 (42K) [text/css]
100%[==========================================================================================================>]
42,745 --.--K/s
11:17:58 (476.32 KB/s) - `styleAp.css.8' saved [42745/42745]
--------------- END OF TEST ----------------
wget have take less than 1 second
Second test:
-----------------
darkstar@stchesmeli:~$ uname -a
Linux stchesmeli 2.6.17.11 #1 Fri Sep 1 16:36:50 CEST 2006 i686 pentium4
i386 GN
U/Linux
darkstar@stchesmeli:~$ wget --no-check-certificate
"https://e.secure.lcl.fr/v_1.
0/css/styleAp.css"
--11:44:00-- https://e.secure.lcl.fr/v_1.0/css/styleAp.css
=> `styleAp.css.9'
Resolving e.secure.lcl.fr... 193.110.152.59
Connecting to e.secure.lcl.fr|193.110.152.59|:443... connected.
WARNING: Certificate verification error for e.secure.lcl.fr: unable to
get local
issuer certificate
HTTP request sent, awaiting response... 200 OK
Length: 42,745 (42K) [text/css]
38%
[==========================================>
] 16,384 1.13K/s ETA 00:22
--------------- END OF TEST ----------------
i have kill wget after 4 mns on the second test.
I have try to change MTU on the interface, no change, same behaviour.
--
Tchesmeli serge
Administrateur syst?me & r?seau
Expert Linux et Logiciels Libres
Oops i correct myself:
> We use to go to a ssh website, our bank website.
SSL website! Sorry!
--
Tchesmeli serge
Administrateur syst?me & r?seau
Expert Linux et Logiciels Libres
On Fri, Sep 29, 2006 at 11:47:20AM +0200, Tchesmeli Serge wrote:
> Me and a friend have discover a stange behaviour since kernel 2.6.17.
Please try to switch off TCP window scaling using the command below
(as root) and retry.
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
Joerg Roedel wrote:
> On Fri, Sep 29, 2006 at 11:47:20AM +0200, Tchesmeli Serge wrote:
>
>
>> Me and a friend have discover a stange behaviour since kernel 2.6.17.
>>
>
> Please try to switch off TCP window scaling using the command below
> (as root) and retry.
>
> echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
>
>
Yes, it's work!
Test:
-------
darkstar@stchesmeli:~$ sudo su -
Password:
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
root@stchesmeli:~# logout
darkstar@stchesmeli:~$ wget --no-check-certificate
"https://e.secure.lcl.fr/v_1.0
--12:05:57-- https://e.secure.lcl.fr/v_1.0/css/styleAp.css
=> `styleAp.css.10'
Resolving e.secure.lcl.fr... 193.110.152.59
Connecting to e.secure.lcl.fr|193.110.152.59|:443... connected.
WARNING: Certificate verification error for e.secure.lcl.fr: unable to
get local issuer certificate
HTTP request sent, awaiting response... 200 OK
Length: 42,745 (42K) [text/css]
100%[=================================================================================================================>]
42,745 --.--K/s
12:06:00 (424.53 KB/s) - `styleAp.css.10' saved [42745/42745]
------------ END OF TEST ----------------
Many thanks!!
--
Tchesmeli serge
Administrateur syst?me & r?seau
Expert Linux et Logiciels Libres
Ar Gwe, 2006-09-29 am 12:08 +0200, ysgrifennodd Tchesmeli Serge:
> Joerg Roedel wrote:
> > On Fri, Sep 29, 2006 at 11:47:20AM +0200, Tchesmeli Serge wrote:
> >
> >
> >> Me and a friend have discover a stange behaviour since kernel 2.6.17.
> >>
> >
> > Please try to switch off TCP window scaling using the command below
> > (as root) and retry.
> >
> > echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
> >
> >
> Yes, it's work!
That means your bank or someone before it probably has a broken
firewall. I would worry about that given how long ago (and thus how many
firmware updates ago) almost every vendor fixed problems like this with
their products.
Alan
On Fri, Sep 29, 2006 at 12:08:13PM +0200, Tchesmeli Serge wrote:
> Joerg Roedel wrote:
> > On Fri, Sep 29, 2006 at 11:47:20AM +0200, Tchesmeli Serge wrote:
> >
> >
> >> Me and a friend have discover a stange behaviour since kernel 2.6.17.
> >>
> >
> > Please try to switch off TCP window scaling using the command below
> > (as root) and retry.
> >
> > echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
> >
> >
> Yes, it's work!
And for a less-intrusive workaround in 2.6.18, see this commit
comment:
commit 316c1592bea94ead75301cb764523661fbbcc1ca
Author: Stephen Hemminger <[email protected]>
Date: Tue Aug 22 00:06:11 2006 -0700
[TCP]: Limit window scaling if window is clamped.
This small change allows for easy per-route workarounds for broken hosts or
middleboxes that are not compliant with TCP standards for window scaling.
Rather than having to turn off window scaling globally. This patch allows
reducing or disabling window scaling if window clamp is present.
Example: Mark Lord reported a problem with 2.6.17 kernel being unable to
access http://www.everymac.com
# ip route add 216.145.246.23/32 via 10.8.0.1 window 65535
Signed-off-by: Stephen Hemminger <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
----------------------------------
Pete Harlan
ArtSelect, Inc.
[email protected]
http://www.artselect.com
ArtSelect is a subsidiary of a21, Inc.