2

I have a wifi router and an extender in my home and I believe that there might be some misconfiguration in the extender. I often have high latency or lower than expected throughput when connecting to the extender.

My main question is:

How do I troubleshoot a wifi extender that seems to cause a lot of duplications?

ANSWER: In my case, the problem was a faulty NIC on the PC ("d"). See EDIT3 for a full explanation and look at the comments for valiable tips on WIFI thoubleshooting.

What I have tried so far is using ping, mtr, traceroute/tracepath. I'll next describe my scenario and then give some example ping outputs:

Scenario

What I have is:

a. wire-only, ISP-provided router connected to the Internet

b. TP-Link Archer-C60 connected to "a" (the ISP router) via ethernet

c. TP-Link AC 750 (RE200) connected to "b" via a 5.8Ghz wifi channel

d. Home PC connected to "c" via 2.4Ghz wifi channel

No other device uses the 5.8Ghz channel. Other devices use either b's or c's 2.4Ghz wifi channel to access the network.

The physical model of the environment is:

Legend:
  -- and | are walls
  '  is a ethernet cable
  a  is the ISP-provided router
  b  is the TP-Link Archer-C60 wifi router
  c  is the TP-Link AC 750 (RE200) wifi extender
  d  is a home PC

                                |--------------|
                                |            d |
                                |c             |
-----------|    |------   ------|              |
|                                              |
|            b|-------   ---   -|              |
|            '|                 |--------------|
|            '|
|            a|
|             |
|-------------|

Example pings

I have ran ping from host "d" while no other device is connected to the network. When doing this, I can easily get 5 to 7 duplicates for a same ping reply. Some example outputs:

Pinging b (192.168.0.1) from d:

--- 192.168.0.1 ping statistics ---
421 packets transmitted, 421 received, +487 duplicates, 0% packet loss, time 420022ms
rtt min/avg/max/mdev = 1.053/10.543/188.536/21.423 ms

Pinging 8.8.8.8 from d:

--- 8.8.8.8 ping statistics ---
421 packets transmitted, 420 received, +867 duplicates, 0% packet loss, time 419810ms
rtt min/avg/max/mdev = 35.480/47.917/256.235/21.228 ms

EDIT1: When running tcpdump, I get lots of ICMP time exceeded in-transit. Small sample, where 192.168.0.1 is "b" and 192.168.0.100 is "d"...

EDIT2:

  • removed ICMP time exceeded in-transit log, added in EDIT1, as it was unrelated.

  • virtual topology of the environment

The virtual topology is:

a --- cat5 --- b >>> 5.8Ghz >>> c ))) 2.4Ghz ))) d and other hosts devices
               U
               U
              2.4Ghz
               U
               U
         other hosts devices

That is:

  • Internet is provided by 'a' to 'b' via cat5 and distributed by 'b' via wireless
  • router 'b' and extender 'c' communicate via the 5.8Ghz channel
  • hosts connect to either 'b' or 'c' via the 2.4Ghz channel (theoretically they could connect via the 5.8Ghz channel, but I do not have compatible devices at the moment)

EDIT3:

It turns out, it was a faulty PCI wireless NIC on my PC ("d"). The NIC was dropping a lot of packets and sending lots of duplicates. This behavior clogged the repeater and eventually the whole network, affecting other devices. I replaced the NIC and now everything works just fine.

To identify this, I simply got a pair of notebooks and attempted to test connectivity inside and outside the network. Also, I did all tests with "d" turned on and then repeated them with it turned off. The difference was very noticeable.

Connectivity inside the network: I used iputils' ping to test dropping rate while flooding (-f flag). Drop rate was near zero between the two notebooks, but was around 20% to my PC. The PC also exhibited a lot of DUPs. tcpdump showed duplicated packets as belonging from my PC or only going towards my PC. When my PC was turned on, ping between the two devices had a few DUPs and drops. When the PC was turned off, no DUPs or drops were identified.

Connectivity outside the network: I used mytraceroute, fast.com, and speedtest.net to check connectivity outside the network. The latency was very high and throughput very low when my PC was turned on. The network behaved perfectly, with very low latency and near nominal throughput, when my PC was turned off.

With the new NIC, everything is working like a charm.

ruasoliveira
  • 21
  • 1
  • 6
  • 1
    Wifi isn't very fast. Are you sure you're not simply choking the bandwidth? If either the upload or download is full, both will stall and lag will increase. Any issue with the placement of the routers would make this problem to exist all the time, not some of the time. – LPChip Jun 12 '18 at 14:53
  • Your ping values don’t look all that bad, except for the spikes. Of course, if all traffic sent multiple times, it’ll seriously reduce usable bandwidth. You should run a packet capture on both ends of the network. Perhaps ask a friend to bring their laptop to connect to `b` via Ethernet. – Daniel B Jun 12 '18 at 15:05
  • @LPChip I don't think this is the case. I'm not choking the bandwidth, as my network should have much more capacity then I was using at the time I was troubleshooting (I keep it to a minimum to avoid interference). Also, when connecting directly to 'b', I have a much better connection -- I cannot connect 'd' to 'b', however, as 'd' is fixed in place. I'm stuck at connecting 'd' via 'c'. I do occasionally have issues with my provider, requiring me to reboot 'a'. But this is not the case, as ping "DUP!"s happen all the time. – ruasoliveira Jun 12 '18 at 15:13
  • @DanielB yes, the latency is low in this case, but I often get an overall bad experience. I'll try making your test later today. In the meanwhile, I have performed a tcpdump on the ping and noticed a lot of "ICMP time exceeded in-transit". Any ideas? I'll update the post. – ruasoliveira Jun 12 '18 at 15:29
  • @rodro, wifi repeaters/extenders usually have one radio interface. The inevitable outcome of this is that you will get half of the original source bandwidth. 50% as client to the first router and 50% providing the repeated SSID. (This shouldn't be the case with yours if you are repeating on the 2.4 band) This can get much worse with interference. If you are using 5.8ghz as the wireless backbone, you should do a site survey of the environment with something like wigglewifi. I would be willing to bet that this is interference by another device (not your own) on the 5.8ghz band. – Tim_Stewart Jun 14 '18 at 18:38
  • You can stumble through the dark and try the different combos of channels for both bands. Or just use a GPS enabled wardriving app that will tell you where and on what channel the neighborhood devices are on. – Tim_Stewart Jun 14 '18 at 18:40
  • @all turns out it was a faulty NIC on my PC ("d"). It was dropping a lot of packets and sending lots of duplicates. This clogged the repeater and eventually the whole network, affecting other devices. Replaced the NIC and now everything works just fine. I'll edit the post to clarify. Thanks all for the tips! – ruasoliveira Jun 18 '18 at 14:46

1 Answers1

0

It turns out, it was a faulty PCI wireless NIC on my PC ("d"). The NIC was dropping a lot of packets and sending lots of duplicates. This behavior clogged the repeater and eventually the whole network, affecting other devices. I replaced the NIC and now everything works just fine.

To identify this, I simply got a pair of notebooks and attempted to test connectivity inside and outside the network. Also, I did all tests with "d" turned on and then repeated them with it turned off. The difference was very noticeable.

Connectivity inside the network: I used iputils' ping to test dropping rate while flooding (-f flag). Drop rate was near zero between the two notebooks, but was around 20% to my PC. The PC also exhibited a lot of DUPs. tcpdump showed duplicated packets as belonging from my PC or only going towards my PC. When my PC was turned on, ping between the two devices had a few DUPs and drops. When the PC was turned off, no DUPs or drops were identified.

Connectivity outside the network: I used mytraceroute, fast.com, and speedtest.net to check connectivity outside the network. The latency was very high and throughput very low when my PC was turned on. The network behaved perfectly, with very low latency and near nominal throughput, when my PC was turned off.

With the new NIC, everything is working like a charm.

ruasoliveira
  • 21
  • 1
  • 6