A Communication Problem between SUSE Linux 9.0 and Router DrayTek Vigor 2500We ------------------------------------------------------------------------------ Problem: Very (!!!) slow internet access from Linux through router Refers to: Suse Linux Support Ticket [20040129430005741] Internet Access via German DSL slow Should be corrected in: Suse Linux 9.0 - probably Linux kernel 2.4.21 resp. network component DrayTek router firmware Problem description: ------------------- I have a small local network that is connected to the internet via German DSL by means of a router that incorporates an ADSL modem. Internet access in this setup is very fast (what I call so) from Windows 98 and Windows XP (after having set appropriate MTU, Rwin and TTL values), internet pages show up almost immediately. But when accessing an internet page from Suse Linux 9.0 (on the same PC), internet access is so slow that I could almost go out for a walk before the page shows up, even after setting proper values for MTU, MRU and MSS. Hardware configuration: ---------------------- PC with Mainboard ASUS A7N8X and CPU AMD Athlon XP 2700+ and Main memory 512 MB NVIDIA nFORCE MCP Networking Adapter (that had not been recognized during Suse Linux install, drivers installed afterwards) Networking adapter connected via Ethernet cables to router DrayTek Vigor 2500We The router contains an ADSL modem that connects to German DSL (T-DSL) that in turn gives internet access. The router acts as gateway and also as name server for the internet acesses (a DNS is implemented in it). Software configuration: ---------------------- PC: Suse Linux 9.0 with Linux kernel 2.4.21 of 24.09.2003 standard installation with a few components added later network adapter: eth0 Router: DrayTek Vigor 2500We Firmware V 2.3.12 (german) of 14.11.2003 Network: IP-address: 192.168.1.21 (PC) Gateway: 192.168.1.1 (router) DSN: 192.168.1.1 (router) Problem analysis: ---------------- If my interpretation of logs from iptraf is correct, the following happens: 1. telnet: Linux sends an UDP packet to port 53 (domain) of the router (DNS server, 192.168.1.1) Router responds with UDP:domain using as sender a remote address (probably of the DNS server that returned the IP address) Linux responds with "unreachable (port)" This happens several times, for about 20 seconds Then on the same Linux request the router responds again with UDP:domain, but uses as sender address its own one (192.168.1.1) Immediately afterwards everything runs fine. 2. http: Linux sends a TCP packet to port 80 (http) of the router (192.168.1.1) I do not know the contents of this packet, likely a request for name resolution and also for data transfer. Router responds with TCP:http using as sender its own address and probably also transfers the requested data Linux responds with TCP:http and FIN and the iptraf protocol also shows a number of packets and bytes transferred, about the numbers in the final FIN after everything went ok, but only about. But no data appear on the screen, obviously Linux throws them away. My conclusion that the requested data have already been transmitted comes from the fact at that point in time under Windows XP the internet page would already appear on the screen. Of course the assumption is that Windows sends the same type of request. This happens several times, for about 20 seconds Then Linux sends an UDP:domain to the router (192.168.1.1) Then the same happens as descibed for telnet above, for about 20 seconds, until the router responds with UDP:domain using its own address as sender. Immediately afterwards Linux sends a TCP:http to the external server in the internet area and evrything runs fine. Now assume loading a page consisting of several parts (including pictures etc.) you can imagine that one can really have a coffee break in between. I did not measure the speed when a large program module is loaded down, I simply did not dare to. Conclusion: ---------- As the analysis shows it is a name resolution problem and a problem of different understandings of Linux and the router firmware as to who should or may respond to a request. 1. Address resolution: For the reason of security only responses from the servers addressed (that we trust) should be accepted. Therefore in the case of telnet above as to my feeling Linux is rigth and the router firmware must be changed. Otherwise this would be a security hole: Whoever responds gets the power. Of course in this very case it is not a problem because (hopefully) the router passes only authorized responses. That telnet works so fine (i.e. fast) with Windows shows that there is a big security risk with Windows if it is used without a router with builtin masquerading. For Linux my proposal is to provide for a switch to allow to open this security hole in order to make Linux work with current routers (may be there is already such a parameter and I only do not know of it). This might possibly be another one of the net.ipvx.ethx sysctls. 2. Data transfer: In the case of http and similar protocols to my feeling it is acceptable what the router does (provided my assumptions are correct). I do not see a security issue in immediately responding with the data requested provided they come from the server addressed by the request. In this case Linux should enhance its functions. That in the present state the internet access finally works at all seems to be due to some second level error recovery. In the case of telnet the router changes response after some time. In the case of http Linux changes requests after some time. Therefore one preliminary help for this problem might be to change to the next level of recovery earlier. Work-Around: ----------- The only way I found to get around this problem is the following: Install your own DNS server on the machine in trouble and use it locally. The DNS specification for eth0 would then just be: 127.0.0.1. This works as fast as I wish it to be. I do not know why it works, but it does. This fact may possibly also give a hint where to look for a (real) problem solution. Relation to other reported problems: ----------------------------------- Several internet fora show problems of a similar kind between Suse Linux 9 and (other) routers that connect to DSL. I do not know whether they have the same reason and can be solved with the same procedure. At least the solution to one of these problems, writing the adresses of the internet provider's DNS directly into the DNS entries for eth0, did not work in my case. In the Linux Hardware Database of Suse Support the router DrayTek Vigor 2200x is shown as 'problematic' in connection with Suse Linux. That is very likely the same problem as addressed here. Proposal: -------- Linux and DrayteK people should communicate to find a common solution. I would very much appeciate hearing some time that a solution has been planned or even implemented. ------------------------------------------------------------------------ Document created by: Gerhard Mueller, Germany, Herrenberg, mail@gmusoft.de Creation date: 15.02.2004 Document can be found at: http://www.gmusoft.de/information/linux/problems/slow-internet-access.txt Revision: 0 Copyright: Analogous to GNU General Public License Comments and questions to: mail@gmusoft.de Document (revision 0) sent to: DrayTek Support: support@draytek.com.tw Suse Support: support@suse.de -------------------------------------------------------------------------