ping and tracert networking question

[Ether]

Originally Posted by nuttle

could just be marginal alignment

That doesn't fit the given facts, unless you are claiming that tracert causes a reverse DNS to be attempted on 10.0.0.1, but what would be the point of doing that?

the antenna is highly directional

It has to be. It's pulling in an 802.11 signal from over a mile away.

....strong indication that you are seeing the rooftop radio at 10.0.0.1... any DNS operation has to contact a server on the Internet

It sounds like you are saying tracert 10.0.0.1 causes a reverse DNS operation to be attempted on 10.0.0.1

Are you quite sure of that? It seems pointless to do that.

If they let you access the admin UI for the radio, you could probably tell a whole lot more.

For sure.

If there's an option to use your own radio

No. That's not their business model.

I assume you tried ubnt/ubnt to log into the radio?

That is the default for this model radio, and it was changed during installation. As mentioned previously, I do not have the password.

Did the utility tell you anything?

No. See attached screenshot.

the fact that you can bring up a login screen is another strong indication that you are seeing the rooftop radio at 10.0.0.1 ... A bridge will typically have a layer 3 IP address, but it doesn't follow that it is going to show up in tracert.

If 10.0.0.1 is the radio, then it is showing up in tracert.

If you are using Windows, try the pathping command -- it is more informative than tracert

More informative in what way? See below:

C:\>pathping 10.0.0.1

Tracing route to 10.0.0.1 over a maximum of 30 hops

  0  Ether [192.168.1.33]  <--my PC
  1  192.168.1.1           <--my router (LAN side)
  2  10.0.0.1              <--my radio?

Computing statistics for 50 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           Ether [192.168.1.33]
                                0/ 100 =  0%   |
  1    0ms     0/ 100 =  0%     0/ 100 =  0%  192.168.1.1
                                0/ 100 =  0%   |
  2    1ms     0/ 100 =  0%     0/ 100 =  0%  10.0.0.1

Trace complete.

C:\>

[nuttle]

Originally Posted by Ether

That doesn't fit the given facts, unless you are claiming that tracert causes a reverse DNS to be attempted on 10.0.0.1, but what would be the point of doing that?

This is why seeing what -n does is interesting. I don't know for sure, one could use a tool like wireshark to sniff the flows on the wire and answer for certain (see <http://www85.homepage.villanova.edu/...b2Exercise.pdf>) but I would not be surprised if the logic does this for any hop, regardless of the specific address. I also wouldn't be too surprised if it didn't depend on the version of tracert in question.

Originally Posted by Ether

If 10.0.0.1 is the radio, then it is showing up in tracert.

In which case, it is probably doing more than just bridging (which I suspect).


The idea with pathping is to get statistics taken over a larger sample size, you might find there are drops even when things seem to be working fine -- but you need to use an address that is further out than 10.0.0.1, which is why I have been using 'chiefdelphi.com'.


If it is easy for you to do, running the util without the router in the middle could make a difference. Some packets are not forwarded across routers and the util likely uses such poackets to discover radios.


Thanks for all of the info thus far!!!

[Jared Russell]

Originally Posted by Ether

I went ahead and changed my DNS as you suggested. I'll know in about a week if that fixes the problem.

I take it the problem is still there?

[Ether]

Originally Posted by Jared341

I take it the problem is still there?

It's only been 4 days since I changed it. Haven't seen the problem so far. That's encouraging, but I'm not going to declare victory until it has been problem-free for a full week.

[Ether]

Originally Posted by Jared341

Try using an open DNS service, like OpenDNS (208.67.222.222/208.67.222.220) or Google Public DNS (8.8.8.8/8.8.4.4).

Originally Posted by Ether

I went ahead and changed my DNS as you suggested. I'll know in about a week if that fixes the problem.

It's been 10 days, and so far no internet misbehavior. This is starting to look good !

[MrRoboSteve]

I'm with others who are hypothesizing that you're having link level problems. DNS issues in ISPs get fixed very quickly, as working DNS is required for nearly everything else that ordinary people do on an internet connection.

[Ether]

Originally Posted by stevep001

I'm with others who are hypothesizing that you're having link level problems.

What is a "link level problem"? How does it fit the observed facts?

DNS issues in ISPs get fixed very quickly, as working DNS is required for nearly everything else that ordinary people do on an internet connection.

The DNS hypothesis fit all the available facts, and ever since I changed my DNS (as Jared341 suggested) the problem has not recurred.

[techhelpbb]

Originally Posted by stevep001

I'm with others who are hypothesizing that you're having link level problems. DNS issues in ISPs get fixed very quickly, as working DNS is required for nearly everything else that ordinary people do on an internet connection.

Ether might be having packet loss issues that are tending to impact the small DNS transactions and so when he repoints his DNS to another source that has their DNS parameters set differently it might be more reliable.

So it could be both.

A good way to notice would be to run a ping or performance test against a relatively stable local site and see if there are periods where it takes much longer to respond. It's probable something in the link is retrying to make the delivery in that case.

I have used *a lot* of Hughes Networking satellite gear and DNS transactions were a major pain because the small transactions would easily waste a ton of time clearing the satellite uplink and back (2-4 seconds of lag to complete a DNS request over bi-directional satellite is not unusual). This sort of thing can make a big headache if the pages you most frequently visit contain absolute encoded hyperlinks with the domain listed. Sometimes the DNS will keep being looked up and avoid the requester cache...especially if they've set the time to live low. Also the DNS packets are usually small and usually satellite TCP/IP systems send a big block to give the illusion of broadband...till you only need a tiny DNS request...then the rest of the block is wasted because your need to resolve the DNS first. It was often annoying enough I'd setup a local caching DNS server and use a 56k modem to feed it (which sounds painfully slow till you realize that the modem's latency is magnitudes less).

It's true that Ether's radio connection should have much lower latency. However the path between the radios in the link is probably open to interference of many kinds. Any of them might be occasionally impacting the link performance causing headaches. I've set up hundreds of long distance wireless links and it is not an uncommon issue.

Ether is there any chance the service provider will let you use SNMP to their radio to get the statistics?
The advantage to them is that they don't need to give you the administration password for the web / command interface.

[Ether]

Guys:

My internet connection has been working flawlessly for the past 11 days (ever since I changed the DNS server setting in my router as suggested by Jared). So that seems to be a pretty strong indicator that the problem I was experiencing is not the link between my radio and the local tower. Would a WireShark capture of several tracert or WGet transactions shed any light?

I did notice something weird though. In the router's "Connection Status" window it always shows the "Lease Expires" data/time equal to the "Lease Obtained" date/time. It was not like this in the past. Is this normal?

Lease Obtained Mon Dec 02 19:24:21 2013
Lease Expires Mon Dec 02 19:24:21 2013

[techhelpbb]

Originally Posted by Ether

Guys:

My internet connection has been working flawlessly for the past 11 days (ever since I changed the DNS server setting in my router as suggested by Jared). So that seems to be a pretty strong indicator that the problem I was experiencing is not the link between my radio and the local tower. Would a WireShark capture of several tracert or WGet transactions shed any light?

Tracert probably not, the wget might.

The point I was making is that wireless has a habit of concealing subtle issues that might be temporary or recurring. TCP/IP is a pretty reliable protocol it'll generally cover for quite a bit before a total link failure.

On a long distance link you'll quite commonly loose link quality and never really notice it because the protocol will retry the delivery.

A prime example is a highly directional link I inherited from someone. It would only fail on windy days in the summer because there were trees that grew high enough that when the wind caught them and they were full of leaves it made strange interference. The link would rarely go completely down. People would start experiencing performance issues on large downloads and partially loaded pages (most of the page would load but a few large images would fail).

I did notice something weird though. In the router's "Connection Status" window it always shows the "Lease Expires" data/time equal to the "Lease Obtained" date/time. It was not like this in the past. Is this normal?

Lease Obtained Mon Dec 02 19:24:21 2013
Lease Expires Mon Dec 02 19:24:21 2013

24 hours is a common DHCP lease but that appears to be in a permanent state of assigning an IP.
Have you tried to power the computer off and on again (props to the "IT Crowd")?

In the big picture, on the other hand, if it's working for now it might be better to leave it be.
Plug and pray

[Ether]

Originally Posted by techhelpbb

A prime example is a highly directional link I inherited from someone. It would only fail on windy days in the summer because there were trees that grew high enough that when the wind caught them and they were full of leaves it made strange interference. The link would rarely go completely down. People would start experiencing performance issues on large downloads and partially loaded pages (most of the page would load but a few large images would fail).

The above does not fit the facts of my case:

My internet was flawless for the first three years (see post #19), and I still have the exact same line-of-sight access to the local tower (no new structures erected in the vicinity).

The problems I had been experiencing recently (the subject of the thread) are not correlated with weather conditions (see post #22). Downpour, dense fog, freezing rain, blizzard, gale force winds, electrical storm: no correlation.

24 hours is a common DHCP lease but that appears to be in a permanent state of assigning an IP.

So having identical "expires" and "obtained" timestamps is definitely abnormal? For example, it's not a synonym for "no expiration"?

[techhelpbb]

Originally Posted by Ether

The above does not fit the facts of my case:

My internet was flawless for the first three years (see post #19), and I still have the exact same line-of-sight access to the local tower (no new structures erected in the vicinity).

The problems I had been experiencing recently (the subject of the thread) are not correlated with weather conditions (see post #22). Downpour, dense fog, freezing rain, blizzard, gale force winds, electrical storm: no correlation.

It's possible you could still be experiencing problems either from weathering of the assemblies, the cables or equipment issues.
For example: when motherboard capacitor start to fail the computer may start exhibiting random instability.
That very same computer probably worked for years before the issues presented.
Unfortunately the state of 'working' in wireless IP links comes in many shades.
It is even possible that over time you've inherited a little mechanical slippage and the antenna pointing is slightly off.

Anyway it is really neither here nor there, if you are happy with the performance what's the sense of worrying about it?
Just as a matter of sanity when I start to have issues like this with links I try to put myself into a position where I can see clearly if there are link level issues so usually I deal with that when the urgency is low.

So having identical "expires" and "obtained" timestamps is definitely abnormal? For example, it's not a synonym for "no expiration"?

If you go to a command prompt and do an:
ipconfig /all

Does that also report the same obtain and release timestamp for that network interface?
It should because those values are stored in Unix timestamps in the registry.

I looked at 3 different Windows systems: XP, 7, 8
All pointing at DHCP servers with infinite leases.
The obtained time reports from the last update.
The renew time reports when the lease expires.
However the IP handed back to that MAC address is the same.
The servers are Windows 2003 and Windows 2008.

There is a single exception I could find:
Microsoft Remote Access Service (RAS) will clone the timestamps because it hides from the client that the assignment is DHCP and it's handing it off from a pool at startup.
In that case it should be dated: Jan 1st, 1980
This happens because RAS hands back an incomplete DHCP handshake and if you look at the DHCP server side the actual time stamps are there.

In all likelihood your equipment is NATing your public IP and some piece of equipment is handing out DHCP internally to your side of the connection (which facilitates the NAT process). Perhaps there's something a little off with how the DHCP has been implemented. However again if it's working you may as well leave it alone till it doesn't but so far as I can see generally what you see there is not normal.

If you are game:
Remove your router from the connection and use the computer directly connected.
Reboot your computer and see what your DHCP reports.

Might just be the result of your router and nothing else.

[Ether]

Originally Posted by techhelpbb

It is even possible that over time you've inherited a little mechanical slippage and the antenna pointing is slightly off.

If there was sufficient signal degradation to cause the DNS issue, I would expect to see problems correlated with weather conditions (dense fog, sleet, blizzard), but I do not.

Anyway it is really neither here nor there, if you are happy with the performance what's the sense of worrying about it?

To each his own I guess, but that's not the way I approach life. If there's something amiss I want to get to the bottom of it. This has served me well time and time again over the years.

If you go to a command prompt and do an ipconfig /all

Ethernet adapter Local Area Connection:

        Connection-specific DNS Suffix  . :
        Description . . . . . . . . . . . : Broadcom NetXtreme 57xx Gigabit Controller
        Physical Address. . . . . . . . . : [redacted]
        Dhcp Enabled. . . . . . . . . . . : Yes
        Autoconfiguration Enabled . . . . : Yes
        IP Address. . . . . . . . . . . . : 192.168.1.33
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 192.168.1.1
        DHCP Server . . . . . . . . . . . : 192.168.1.1
        DNS Servers . . . . . . . . . . . : 192.168.1.1
        Lease Obtained. . . . . . . . . . : Monday,  December 02, 2013 11:47:30 AM
        Lease Expires . . . . . . . . . . : Tuesday, December 03, 2013 11:47:30 AM

As you can see, the lease assigned by the router to the PC is for 24 hours. Maybe that's because the router software doesn't know what to do with the lease it's been assigned with the "expired" timestamp the same as the "assigned". As I mentioned in post #39, it has not always been the case that the router lease obtained/expires timestamps are identical. I didn't make a note in my journal when I first noticed they were equal. But for the first couple of years or so they were not equal.

If you are game: Remove your router from the connection and use the computer directly connected.
Reboot your computer and see what your DHCP reports.

Easy enough to do. I'll queue it up for later. Debugging some software right now.

[Ether]

Originally Posted by Ether

...I'll queue it up for later...

OK, this is weird:


PC connected directly to radio:

With PC connected directly to radio:

C:\>ipconfig/all

Windows IP Configuration

        Host Name . . . . . . . . . . . . : [redacted]
        Primary Dns Suffix  . . . . . . . :
        Node Type . . . . . . . . . . . . : Hybrid
        IP Routing Enabled. . . . . . . . : No
        WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection:

        Connection-specific DNS Suffix  . :
        Description . . . . . . . . . . . : Broadcom NetXtreme 57xx Gigabit Controller
        Physical Address. . . . . . . . . : [redacted]
        Dhcp Enabled. . . . . . . . . . . : Yes
        Autoconfiguration Enabled . . . . : Yes
        IP Address. . . . . . . . . . . . : 10.0.0.194
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 10.0.0.1
        DHCP Server . . . . . . . . . . . : 10.0.0.1
        DNS Servers . . . . . . . . . . . : 10.0.0.1
        Lease Obtained. . . . . . . . . . : Tuesday, December 03, 2013 3:30:29 PM
        Lease Expires . . . . . . . . . . : Tuesday, December 03, 2013 4:30:29 PM

PC connected to radio through router:

With PC connected radio through router:

C:\>ipconfig/all

Windows IP Configuration

        Host Name . . . . . . . . . . . . : [redacted]
        Primary Dns Suffix  . . . . . . . :
        Node Type . . . . . . . . . . . . : Hybrid
        IP Routing Enabled. . . . . . . . : No
        WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection:

        Connection-specific DNS Suffix  . :
        Description . . . . . . . . . . . : Broadcom NetXtreme 57xx Gigabit Controller
        Physical Address. . . . . . . . . : [redacted]
        Dhcp Enabled. . . . . . . . . . . : Yes
        Autoconfiguration Enabled . . . . : Yes
        IP Address. . . . . . . . . . . . : 192.168.1.33
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 192.168.1.1
        DHCP Server . . . . . . . . . . . : 192.168.1.1
        DNS Servers . . . . . . . . . . . : 192.168.1.1
        Lease Obtained. . . . . . . . . . : Tuesday,   December 03, 2013 3:34:55 PM
        Lease Expires . . . . . . . . . . : Wednesday, December 04, 2013 3:34:55 PM

Router Connection Status:

Connection Status
IP Address	10.0.0.136
Subnet Mask	255.255.255.0
Default Gateway	10.0.0.1
DHCP Server	10.0.0.1
DNS Server	208.67.222.222  8.8.8.8
Lease Obtained	Tue Dec 03 20:34:29 2013
Lease Expires	Tue Dec 03 20:34:29 2013

Can anyone explain this?

[techhelpbb]

Originally Posted by Ether

Can anyone explain this?

When you first posted this I was under the impression that your computer was seeing the identical timestamp. It seems it is actually your router reporting that information I missed that a few posts ago.

It looks like your router is either botching the timestamp decoding, simply replicating the information or just plain has a bug.
It shouldn't be reporting different information from your computer even if the MAC address of the network interface is different.

I looked real quick to see if you list the make and model of your router somewhere and I did not see it.
If you provide that and I have access to one I'll test it for you.