From a thread on Ubuntu Forums I tried the following commands:

 sudo modprobe -r rt2800pci
 sudo modprobe -v rt2800 pci nohwcrypt=1

it worked for someone on that thread, but for me it shows:

 modprobe: FATAL: Module rt2800 not found in directory /lib/modules/4.10.0-32-generic

I am using ubuntu 17.04

In terminal I am getting an average of about 20 kb/sec

On Windows the average is about 220 kb/sec

lspci -knn | grep Net -A3 outputs

enter image description here

  • Please edit your question and add output of lspci -knn | grep Net -A3 terminal command.
    – Pilot6
    Aug 14, 2017 at 16:27
  • 1
    And you have an extra space in the command. It should be sudo modprobe -v rt2800pci nohwcrypt=1
    – Pilot6
    Aug 14, 2017 at 16:28
  • i updated it...please check
    – Rajat Negi
    Aug 14, 2017 at 16:49
  • You have an Atheros adapter. Those commands can't be useful because they are for Ralink adapters. And PLEASE don't post text as screenshots!!!
    – Pilot6
    Aug 14, 2017 at 16:57
  • are there similar commands for atheros adapter
    – Rajat Negi
    Aug 14, 2017 at 16:59

1 Answer 1


Note: make sure your router is set to WPA2-AES.

Your problem is with the MTU setting for your DSL connection.

There's a MTU setting in Ubuntu's network configuration, and a WAN MTU setting in your router.

For DSL, a common MTU setting is 1492. Just go ahead and try this value first and see if your network performance improves.

To determine the correct setting, start with all MTU settings = 1500 and VPN = off. (VPN requires different testing).

In terminal:

ping [-c count] [-M do] [-s packet_size] [host]

The options used are:

  • c count: number of times to ping
  • M hint: Select Path MTU Discovery strategy. may be either do (prohibit fragmentation, even local one), want (do PMTU discovery, fragment locally when packet size is large), or dont (do not set DF flag).
  • s packet_size: Specifies the number of data bytes to be sent.

You should always start at 1472 and work your way down by 10 each time. Once you get a reply, go up by 1 until you get a fragmented packet. Take that value (last good value) and add 28 to the value to account for the various TCP/IP headers. Eg. let's say that 1452 was the proper packet size (where you first got an ICMP reply to your ping). The actual MTU size would be 1480, which is the optimum for the network we're working with.

ping -c 4 -M do -s 1472 # this will probably show fragmentation

ping -c 4 -M do -s 1462 # may show fragmentation

ping -c 4 -M do -s 1452 # no fragmentation?

ping -c 4 -M do -s 1453 # still no fragmentation?

reference: How to determine the proper MTU size with ICMP pings

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.