Internet Connection: Some Web Sites Cannot Be Viewed

Support knowledgebase (cg_internet)
Applies to

Kernel: Versions since 2.4.0

Symptom

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.

Cause

This phenomenon can have two different causes. Below you will be shown how the error can be examined and eliminated.

  1. ICMP packets of the path MTU discovery do not arrive at the remote server. This situation and the elimination of the error is described in the SDB article "T-DSL (among others): Some Servers Are Unreachable" (http://sdb.suse.de/en/sdb/html/cg_pmtu2.html).
  2. You have activated the TCP option "ECN" (explicit congestion notification) which is inactive by default.

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.

Solution

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"

Troubleshooting/Background Information

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.

Example 1: ECN active

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.

Example 2: PMTU problem

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:
o T-DSL (among others): Some Servers Are Unreachable

Keywords: PMTU, DISCOVERY, INTERNET, ECN

Categories: Internet

Feedback welcome: Send Mail to cg+sdb@suse.de (Please give the following subject: SDB-cg_internet)
SDB-cg_internet, Copyright SuSE Linux AG, Nürnberg, Germany - Version: 20. Nov 2001
SuSE Linux AG - Last generated: 22. Nov 2001 by ip (sdb_gen 1.40.0)