Traceroute From Internet Modem

I am using a Nanostation loco M900 for my Internet access and my speeds at some times are worse than dialup. Trying to debug to see exactly where the problem lies I log into the M900 through my browser and run a traceroute on 8.8.8.8. The times are truly horrible with most pings taking seconds if they don't time out.

What is not clear to me is if the traceroute is being done from the M900 or if it is just being done from my PC. I'm trying to show the problem is on one side of the modem or the other... my internal problem or the ISP's problem.

Any idea how I can tell for sure?

The 900 also has a speed test and clocks some 3 to 5 Mbps depending. But I think that is just testing the air link and not the full connection to the Internet.

--

Rick
Reply to
rickman
Loading thread data ...

If you are looking at the Ubiquiti diagnostics pages in the M900, then traceroute is being run from the Ubiquiti bridge radio. If you run it from your computah's command prompt, it's being run on the PC.

The first step to solving a problem is to blame someone, or something.

Send me some traceroute results and I'll look at them. Basically, the hop with the biggest increase in latency, is the culprit. With WISP providers, it's sometime their backhaul to their ISP, which is expensive and often overloaded.

Another common culprit is interference, in this case on 900 MHz. Look at the SNR numbers in the M900. If they're low, you MIGHT have an interference problem. An easy way to test for interference is to look for variations in latency when you ping the ISP's end of the wireless link. For example, if your ping results look like this: C:\>ping 192.168.111.1 -t Pinging 192.168.111.1 with 32 bytes of data: Reply from 192.168.111.1: bytes=32 time=5ms TTL=64 Reply from 192.168.111.1: bytes=32 time=2ms TTL=64 Reply from 192.168.111.1: bytes=32 time=100ms TTL=64 Reply from 192.168.111.1: bytes=32 time=80ms TTL=64 Reply from 192.168.111.1: bytes=32 time=4ms TTL=64 Reply from 192.168.111.1: bytes=32 time=2ms TTL=64 Reply from 192.168.111.1: bytes=32 time=2ms TTL=64 Reply from 192.168.111.1: bytes=32 time=40ms TTL=64 Reply from 192.168.111.1: bytes=32 time=5ms TTL=64 the bridge radios are catching errors, and sending retries, which is what extends the delay. In extreme cases, you'll see timeouts.

Describing how to use traceroute might be a bit much. This looks like a fairly minimal description: You can find MTR ported to Windoze at:

You might also try running traceroute from an internet server to your IP address. Start here:

The speed test is testing the speed between your M900 and whatever the WISP is using for an access point. In the Ubiquiti diagnostics, it's strictly radio to radio.

Good luck.

--
Jeff Liebermann     jeffl@cruzio.com 
150 Felker St #D    http://www.LearnByDestroying.com 
 Click to see the full signature
Reply to
Jeff Liebermann

FWIW, I ran the same traceroute on my all-wired connection and everything looks reasonable, so 8.8.8.8 is a good test. The times for each hop vary from about 10 to 31 milliseconds. (Some networks don't return the ICMP packets that make traceroute work, so it can be hard to tell whether the problem is close to you or not, but 8.8.8.8 doesn't seem to have this problem.)

I can also ping 8.8.8.8 and the ten-packet average is about 20 milliseconds. My own ISP's DNS server averages 21 milliseconds.

If the traceroute results are showing up in the browser window, it's probably being done from the M900. You should be able to tell by looking at the IP address of the very first line in the traceroute output. When I do a traceroute from my (wired Ethernet) PC, the first IP is the LAN-side address of my router. If I could do one from the router, the first IP would be an address at my ISP.

If you can get a command prompt / shell on your PC, both Linux and legacy systems should have traceroute available. Linux and Mac call it traceroute and Windows calls it tracert . That way you can be sure it's running from your PC.

Is your ISP wireless? Apparently the Nanostation gets used both ways... as the first device at the customer end for wireless ISPs, or as a base station at the customer end with a wired ISP.

If you have a wired ISP, the usual method is to plug an Ethernet cable directly into the modem and your PC, and try speed tests, traceroutes, pings, etc. (If you have Windows, make sure you are up to date on updates from Microsoft before you do this.) If you have a wireless ISP, I don't know of a good way to test, other than by substituting a different radio on your end.

Matt Roberds

Reply to
mroberds

Whatever is upstream from you (first hop) can play a big role. E.g., if your connection is NAT'ed then there's a piece of *code* you are moving through. Ditto with any firewalls or filters.

ping mypc ping M900

traceroute mypc traceroute M900

Hint: first hop tells you the first thing *past* the point from which the trace was initiated.

"traceroute " may fail if any of the nodes along the path refuse to support the operation.

Run each of the above from a DOS/CLI prompt *and* your web interface and you'll see the difference.

Reply to
Don Y

If it's being done from your PC via a web interface you've got a big security problem.

--
umop apisdn
Reply to
Jasen Betts

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.