Kernel: Versions since 2.4.0
You use Deutsche Telekom's T-DSL, or an IP-over-IP, or the so-called CIPE tunnel to transmit data to your Internet provider. Some computers on the Internet are not completely reachable, which can be noticed because connections can be partially established, but the subsequent data transfer hangs. You also recall that this used to work with older SuSE Linux versions containing Kernel 2.2.
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 this 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 this ICMP packets. This is the real 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.
Actually, it must be distinguished between two cases:
Since you cannot influence other firewalls and routers, workarounds are your only chance.
The workaround consists of trying to prevent that the Path MTU discovery is executed. In other words, you tell the operating system to send smaller packets than usual and to tell the remote machine also to send smaller packets. The size of these packets must make it possible to send them "in one piece" through the PPPOE route. Luckily enough, this can be achieved in several ways.
Let's observe first the second case. You use a central masquerading router for several computers. The clients cannot reach certain computers on the Internet.
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 charachters 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
ressemble 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
As to the first case: actually this error should not occur directly on the T-DSL
router because the PPPOE, i.e. PPPOE's ppp0
device, is usually configured with
the right MTU. This can be seen in ifconfig
's output. Anyway, if you encounter
any difficulties, try to edit the file /etc/ppp/peers/pppoe
(until SuSE Linux 7.2
there are two files named pppoe
or pppoe24
for Kernel 2.4).
There you will find, among others
mru 1490 mtu 1490
You can try to modify these values. Assign the same value for MRU and MTU, since packets can have the same size in both directions. You can assign 1492 (actually the highest possible value) or again 1400, which has already been assigned to the potential clients above.
MSS
for a route can be set
through the route
command. The MSS
is similar to the MTU.