LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)
-   -   DSL -> Linux gateway -> Netgear router: slow upload problem (https://www.linuxquestions.org/questions/linux-networking-3/dsl-linux-gateway-netgear-router-slow-upload-problem-616307/)

mtford 01-25-2008 11:51 AM

DSL -> Linux gateway -> Netgear router: slow upload problem
 
I have a network set up as follows, using a Linux gateway machine running RedHat Enterprise Linux 4 (kernel 2.6.9):

Code:

            internet
                |
                |
    SPEEDTOUCH 330 USB DSL MODEM
  (via pppd + speedtch kernel module)
                |
                |
                | aaa.bbb.ccc.ddd on ppp0
    LINUX GATEWAY RUNNING IPTABLES
                | 10.0.0.1 on eth0
                |
                |
                | 10.0.0.2
    NETGEAR ETHERNET/WIRELESS ROUTER
                | 192.168.0.1
                |
                |
      other nodes, 192.168.0.x

For iptables I have the following:

Code:

  iptables -F
  iptables -t nat -F
  iptables -A INPUT -i eth0 -j ACCEPT
  iptables -A INPUT -i ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT
  iptables -A INPUT -i ppp0 -j REJECT
  iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

The external IP of the router is manually set to 10.0.0.2/8 (I'm not running DHCP).

For downstream traffic from the internet, my network works fine. Upstream, however, my connection is about 50 times slower than it ought to be. Testing my bandwidth on http://www.ip-adress.com/speedtest/ and with SFTP to both internal and external servers, I get the following results:

Code:

                                          DOWN        UP
  Linux gateway to internet:          4000 kbps  400 kbps

  Other nodes to internet
  via router+gateway:                  4000 kbps    8 kbps (!)

  Other node to internet
  via gateway only (with crossover
  cable and no router):                4000 kbps  400 kbps

  Other nodes to Linux gateway
  via router (not to internet):          fast        fast

  Other node to internet
  via router only (same Netgear
  router connected directly to
  ethernet modem with other ISP):        fast        fast

So why is the upsteam connection through my system so slow, if both the router and the gateway work fine independently??

Matthew.

blackhole54 01-26-2008 03:48 AM

I haven't a clue what is going on. But you might try running a packet sniffer such as tcpdump or wireshark on the two ports on your gateway to see if you see anything unusual that might give a hint.

mtford 01-26-2008 11:39 AM

I tried ethereal, but unfortunately my gateway computer is not currently connected to a monitor, so I was running the packet sniffer over the network. Inevitably the sniffer was swamped by an avalanche of traffic from its own terminal, and no amount of grepping would produce sensible output.

I did find a workaround to my problem, though I still don't know the original cause. I have now connected my gateway to one of the LAN ports on the router, instead of the internet input port, and configured a static route using the router's web interface. This ensures that all traffic to external IPs is directed to the gateway on the LAN, and not to the router's non-existent external internet connection. Now I am getting full-speed uploads and downloads. No idea why this should make a difference; maybe the router's NAT/masquerading was clashing somehow with the masquerading in my gateway??

I also had to work around another bug, which I'll mention in case anybody else finds this thread in Google. There are two problems with the Netgear interface for setting up static routes: (1) you cannot include a default route, i.e. the subnet mask 0.0.0.0 is not accepted; and (2) the router's DHCP server will mysteriously stop working if you set up a static route that includes the address 255.255.255.255. To get around problem (1), you could define a default route in two parts:
Code:

  IP: 1.0.0.0,  SUBNET: 128.0.0.0,  GATEWAY: gateway's IP on the LAN
  IP: 128.0.0.0, SUBNET: 128.0.0.0,  GATEWAY: gateway's IP on the LAN

Unfortunately, the second of these two routes includes the address 255.255.255.255, so your DHCP will stop working (don't ask why!). You can get around this by using the following set of routes, which include IP addresses from 0.0.0.0 to 239.255.255.255, i.e. all except the "IANA reserved" block:
Code:

  IP: 1.0.0.0,  SUBNET: 128.0.0.0    (includes 0-127)
  IP: 128.0.0.0, SUBNET: 192.0.0.0    (includes 128-191)
  IP: 192.0.0.0, SUBNET: 224.0.0.0    (includes 192-223)
  IP: 224.0.0.0, SUBNET: 240.0.0.0    (includes 224-239)

Obviously you could continue this binary sequence to get 32 separate routes that include all addresses except 255.255.255.255, but this isn't necessary.

Matthew.

blackhole54 01-26-2008 04:27 PM

Quote:

Originally Posted by mtford (Post 3035861)
I tried ethereal, but unfortunately my gateway computer is not currently connected to a monitor, so I was running the packet sniffer over the network. Inevitably the sniffer was swamped by an avalanche of traffic from its own terminal, and no amount of grepping would produce sensible output.

I am guessing you used ssh to access the gateway. I've never used Wireshark (formerly Ethereal). But I imagine there is a way to tell it to ignore port 22 traffic. I know exactly the problem you are talking about, and it is quite impossible to handle w/o telling the sniffer to ignore those packets. (Everytime it reports an ssh packet, it generates another one or two or three; you may as well try to cut off all the heads of the Hydra.) With tcpdump, the command is:

tcpdump [options] -i <interface> not tcp port 22

Quote:

the router's DHCP server will mysteriously stop working if you set up a static route that includes the address 255.255.255.255.
You do realize that 255.255.255.255 is a reserved address for a general broadcast? It is not supposed to be routed. The implementations of all DHCP clients I have seen use it to do DHCPDISCOVER. If you are somehow routing it, that is probably what breaks DHCP.

(BTW, I am playing close attention to your experiences since I have started playing around with a NETGEAR router somebody recently gave me.)

mtford 01-26-2008 05:17 PM

Quote:

You do realize that 255.255.255.255 is a reserved address for a general broadcast? It is not supposed to be routed. The implementations of all DHCP clients I have seen use it to do DHCPDISCOVER. If you are somehow routing it, that is probably what breaks DHCP.
I assumed it was broadcasting on 192.168.255.255 (the broadcast address for my LAN), but maybe 255.255.255.255 is equivalent to this (?). Anyhow, the router does not seem to care if I try to route 192.168.x.x through my gateway - it knows that these addresses belong to my LAN - but it does get confused if I route 255.255.255.255.

Presumably the Linux kernel knows about this, so 255.255.255.255 would always be excluded from the default route in a Linux-based router?

blackhole54 01-27-2008 01:49 AM

Typically a card with IP address 192.168.0.1 would have a netmask of 255.255.255.0. (You could force it otherwise.) In that case the broadcast for that subnet would be 192.168.0.255. There is also the general broadcast of 255.255.255.255 which will work on any subnet. As I understand it, neither type of broadcast should be routed through any router (aka gateway). Obviously when such a broadcast originates from a Linux box, the kernel has to be able to send it. That is one of the subtleties of the Linux routing table I still haven't mastered. (On an old RH7.0 box of mine, there is an explicit entry in the routing table for 255.255.255.255/255.255.255.255. But I notice this entry is absent on newer software.)

The times I've looked at network traffic from DHCP clients, they have used the general broadcast (255.255.255.255) for DHCPDISCOVER. I've presumed they do this because they do not yet know what subnet they belong to.


All times are GMT -5. The time now is 09:56 AM.