SuSE Linux: Version 7.3
Kernel: Versions since 2.4.0
You use DSL with SuSE Linux 7.3 and some computers on the Internet are not reachable. This can be noticed because connections can be partially established but the subsequent data transfer hangs.
The fact that the connection "hangs" is not specific to T-DSL but related to the for T-DSL valid smaller MTU (through PPPOE).
Unfortunately, some of the "firewalls" that can be found before some servers have been wrongly configured by their operators. This is actually the reason for this problem.
Please set the value of MTU and MRU to 1492 in the following files:
/etc/ppp/options
/etc/ppp/peers/pppoe
Add the following lines to file /etc/ppp/peers/pppoe:
mtu 1492
mru 1492
Search for mtu and mru in file /etc/ppp/options and change the disabled lines as follows:
mtu 1492
mru 1492
The most important thing is that you set the same values in both files. If this is the case and all values have been set to 1492, you should not have any further problems accessing pages like gmx.de or postbank.de.
You use a central masquerading router for several computers. The clients cannot reach certain computers on the Internet. However, you have no problems whatsoever on the router side
First of all you should test if your problem is really caused
by PMTU discovery. You can do this by using the ifconfig
command on the
command line in order to define the packet-size used. Please note that you are
not allowed to reduce the network card directly connected to the T-DSL modem
in the MTU.
tux@earth:~ $ /sbin/ifconfig eth0 Protocol:Ethernet hardware address 00:10:10:00:01:A4 inet address:10.10.11.102 Bcast:10.10.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:93589710 errors:0 dropped:0 overruns:0 frame:0 TX packets:14879178 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 length send queue:100 RX bytes:3770027551 (3595.3 Mb) TX bytes:2994365512 (2855.6 Mb) Interrupt:11 base address:0xd000
Above you can see in bold characters 1500 byte as the default value for MTU. Try now to reduce the MTU (root rights required).
root@earth:~ # /sbin/ifconfig eth0 mtu 1400
If the problematic server can be reached now, you can perform the following modifications for this case:
route
command. For this purpose you can e.g. modify
the file /etc/route.conf
as follows:
default 10.10.0.8 0.0.0.0 eth0add to the end of the line
default 10.10.0.8 0.0.0.0 eth0 mss 1400in order to set the segment size to 1400 Byte (usual: 1448 Byte).
/etc/rc.config
.
Search for the network adapter's configuration in this file, which may
resemble the following one:IFCONFIG_0="10.10.11.102 broadcast 10.10.255.255 netmask 255.255.0.0"and add
IFCONFIG_0="10.10.11.102 broadcast 10.10.255.255 netmask 255.255.0.0 mtu 1400"in order to set a limit of 1400 Byte to the MTU.
213.95.15.200
) with a MSS of
1400 Byte, add the following line in /etc/route.conf
:213.95.15.200 10.10.0.8 255.255.255.255 eth0 mss 1400or -temporary - at the command line (
root
rights required!)
route add -host 213.95.15.200 gw 10.10.0.8 eth0 mss 1400
The connection's "hanging" is not specific to T-DSL, but related to the for T-DSL valid smaller MTU (through PPPOE). The valid MTU can also be smaller if you use a commercial dial-up router or Windows as your router and employ other Ethernet Frames than the usual Ethernet_II Frames in your LAN. The same also applies to IP-over-IP or CIPE tunnel.
The network packets that will be transmitted through these connections must be therefore somewhat smaller than usual.
If the size of the incoming packet is too big, the following usually happens: as soon as the packet reaches the route with a smaller MTU, it will be fragmented in a transparent way by the router containing the network adapter with the smaller MTU. The network packet will be resolved into several smaller IP packets by the router until they are small enough. These IP fragments are subsequently reassembled by the target computer.
This transparent fragmentation represents a big load for the Internet backbone-router that has to fragment its packets (e.g. Telekom's router in the case of T-DSL). In order to reduce costs for the Internet infrastructure, this load is avoided by means of a special flag in every IP packet, the so-called "DF" (Don't fragment) bit. This has already been deployed under Linux since Kernel Version 2.4. The whole process is called Path MTU discovery and is described in RFC 1191.
When the DF bit has been set in the IP packet, the routers that should normally fragment
such a big packet send an ICMP (Internet Control Message Protocol) message
"ICMP: destination unreachable: need to fragment"
back to the big packet's sender
and even suggest a new MTU. The original packet is rejected by the router. The sending computer
receives the ICMP message and reduces the packet to send it again.
In case the sender does not receive this ICMP packet, the connection will hang. Unfortunately, some of the "firewalls" that can be found before important servers have been wrongly configured by their operators, and therefore reject ICMP packets. This is actually the reason for this error.
The connection apparently hangs. Since both sides think that it is just a packet that has been lost, they retry to transfer the unmodified packet, which of course does not work either.
MSS
for a route can be set
through the route
command. The MSS
is similar to the MTU.