Kernel: Versions since 2.4.0
The Internet dial-in works properly and you can view many web pages and use other Internet services. Yet, you are not able to establish any connection to a number of servers, e.g. a www.postbank.de or www.mediamarkt.de. However, you can view the pages when you use a web proxy. Nevertheless, as soon as you try to connect to other web pages using https (e.g. the online banking pages of www.postbank.de), the pages do not appear.
This phenomenon can have two different causes. Below you will be shown how the error can be examined and eliminated.
The first error usually occurs in connection with T-DSL or other ADSL providers that make use of the PPPoE protocol. With these providers, the maximum size of a data packet is no longer 1500 Byte but only 1492 Bytes, as the PPoE header occupies a total of 6+2 Byte.
The second error occurs in case you have set the option DISABLE_ECN
in the
file /etc/rc.config
to "no". This can only happen if you have changed this
setting manually, as this setting is set to "yes" during the installation. Thus, "ECN"
is inactive by default. A detailed technical description of what exactly "ECN" is
can be found in RFC 2481.
An exhaustive approach to problem 1 is presented in the article "T-DSL (among others): Some Servers Are Unreachable" (http://sdb.suse.de/en/sdb/html/cg_pmtu2.html).
The solution of problem 2 is also simple. Please enter the following command:
echo "0" > /proc/sys/net/ipv4/tcp_ecn
In this way, ECN is deactivated. Attempts to reach the server should now be successful.
In order to keep this setting after a reboot, please modify /etc/rc.config
as
follows:
Search for the line
DISABLE_ECN="no"
replace this line with
DISABLE_ECN="yes"
You can also analyze and single out the error with the commands
tcpdump
and lynx
(both in series n
).
For this purpose, open an xterm or a console and enter the following command:
tcpdump -p -i any port 80
The effect of this command is that the data packets of the web request you send via a network interface are displayed on screen.
In order to limit the amount of activity, use the console web browserlynx. Enter the following in a second console:
unset http_proxy lynx http://www.postbank.de/
www.postbank.de stands for the web server you want to analyze.
If you have activated ECN and the server (www.mediamarkt.de
in our example) can not be accessed, the screen output of the tcpdump
command will
look somewhat like
11:11:03.624736 babbage.suse.de.33045 > 62.26.5.66.http: S [ECN-Echo,CWR] 304018638:304018638(0) win 5840 <mss 1460,sackOK,timestamp 492568 0,nop,wscale 0> (DF) 11:11:06.624765 babbage.suse.de.33045 > 62.26.5.66.http: S [ECN-Echo,CWR] 304018638:304018638(0) win 5840 <mss 1460,sackOK,timestamp 492868 0,nop,wscale 0> (DF) 11:11:12.624823 babbage.suse.de.33045 > 62.26.5.66.http: S [ECN-Echo,CWR] 304018638:304018638(0) win 5840 <mss 1460,sackOK,timestamp 493468 0,nop,wscale 0> (DF) 11:11:24.624939 babbage.suse.de.33045 > 62.26.5.66.http: S [ECN-Echo,CWR] 304018638:304018638(0) win 5840 <mss 1460,sackOK,timestamp 494668 0,nop,wscale 0> (DF)
Symptom: As you can see, the remote server does not respond at all.
In growing intervals, your host tries to establish a connection (you can
see this from the highlighted S) but receives no response. In addition,
ECN is active (which can be seen from [ECN-Echo,CWR]
).
Workaround solution: Deactivate ECN as described above.
Actual cause: A wrongly configured firewall or an operating system that does not comprehend the ECN option and (erroneously) dumps the packets.
Start both programs as described above. Monitor the output of tcpdump
:
11:21:05.943114 Plato.suse.de.3874 > www.postbank.de.http: S 933875796:933875796(0) win 32120 <mss 1460,sackOK,timestamp 1892930261 0,nop,wscale 0> (DF) 11:21:06.088764 www.postbank.de.http > Plato.suse.de.3874: S 3593485934:3593485934(0) ack 933875797 win 10136 <nop,nop,timestamp 422243768 1892930261,nop,wscale 0,nop,nop,sackOK,mss 1460> (DF) 11:21:06.088832 Plato.suse.de.3874 > www.postbank.de.http: . 1:1(0) ack 1 win 32120 <nop,nop,timestamp 1892930276 422243768> (DF) 11:21:06.090514 Plato.suse.de.3874 > www.postbank.de.http: P 1:927(926) ack 1 win 32120 <nop,nop,timestamp 1892930276 422243768> (DF) 11:21:06.264159 www.postbank.de.http > Plato.suse.de.3874: . 1:1(0) ack 927 win 9210 <nop,nop,timestamp 422243782 1892930276> (DF)
Symptom: As you can see, in contrast to the above example, the connection between the two hosts is established correctly. Both hosts have successfully exchanged "synchronization pacekts" (the packets with the highlighted S). Even data was transmitted correctly, which can be seen from the packet with the highlighted 926 in brackets. However, only the request to the web server works (here: www.postbank.de). Following the packet confirming that the data has been received, the connection "hangs". Normally the web server would now transmit the home page, but obviously this does not work.
Analysis: The packet from the web server gets lost somewhere on its way to you. Probably it was too large and could not be fragmented (this is prohibited by the "DF" bit at the end of the line).
Workaround solution: See "T-DSL (among others): Some Servers Are Unreachable" (http://sdb.suse.de/en/sdb/html/cg_pmtu2.html)
Actual cause: The firewall of the web server operator dumps ICMP packets because it was configured incorrectly.
See also:SDB-cg_internet
)