Re: ping and tracert networking question
 

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?


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


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.


For sure.


No. That's not their business model.


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


No. See attached screenshot.


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


More informative in what way? See below:

Re: ping and tracert networking question
 

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.


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!!!

Re: ping and tracert networking question
 

I take it the problem is still there?

Re: ping and tracert networking question
 

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.

Re: ping and tracert networking question
 

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

Re: ping and tracert networking question
 

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.

Re: ping and tracert networking question
 

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


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

Re: ping and tracert networking question
 

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.

Re: ping and tracert networking question
 

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

Re: ping and tracert networking question
 

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).

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 :)

Re: ping and tracert networking question
 

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.

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

Re: ping and tracert networking question
 

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.


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.

Re: ping and tracert networking question
 

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.


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.


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.


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

Re: ping and tracert networking question
 

OK, this is weird:


PC connected directly to radio:


PC connected to radio through router:


Router Connection Status:

Can anyone explain this?

Re: ping and tracert networking question
 

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.