Re: Losing Communications with the Mount


Christopher Erickson
 

(The following is a general comment and not intended as a specific reply to anyone on this thread.)

One important and fundamental fact about troubleshooting Ethernet/WiFi/IP/TCP/UDP networking problems is that anything measured at an OSI Layer higher than the Layer where the problem is originating, will give misleading & potentiality invalid results until problems at the lower Layers are resolved. And all Layers below a particular Layer are invisible to that Layer. All it gets to see is the data coming up from the Layer immediately below it. Troubleshooting tools like Wireshark use special "promiscuous" modes that are available in SOME network interfaces. These special "promiscuous mode" functions allow user apps like Wireshark to look more deeply at the statistics at the lower OSI Levels. Some "promiscuous mode" capable network adapters are more sophisticated and feature-rich than others.

The classic OSI networking model is as follows,

Layer 1 - Physical (cables, connectors, voltages, signals, carriers, etc.)
Layer 2 - Data (Ethernet Frames, Tokens, etc.)
Layer 3 - Network (IP Packets, others)
Layers 4/5 - Transport/Session (TCP, UDP, XTP, etc.)
Layer 6 - Presentation (decryption/encryption, etc.)
Layer 7 - Application (organization & delivery to/from the OS)

For troubleshooting purposes over the years, I have added three more important Layers to the OSI model as well.

Layer 0 - The funding. NOTHING is going to ever work right at any other Layer if this Layer isn't stable and solid.

Layer 8 - THE USER. "Yea, it was definitely a Layer-8 issue! Excessive operator head-space!"

Layer 9 - THE POLITICS. "Ugh. This is a Layer-9 problem and will NEVER get fixed!"

Seriously though, Layer 7 reports the the OS (computer operating system) and the user app interacts with the OS to get the networking services. Layer 7 is NOT the user app. Just FYI.

I hope this helps (and entertains!)

-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   


On Thu, May 6, 2021, 12:35 PM Seb@stro <sebastiendore1@...> wrote:
Christopher,

As you surely know, much of all Internet communication is TCP-based nowadays and work arguably 365 days/year and almost 24hours a day (like 2 and 3 nines networks). Not sure what 30 years of experience with TCP has to do with that or any communication reliability figure for that matter. 

PingPlotter does indeed look like a valuable tool (you even convinced me to download and try it).

In regards to the old CLI vs GUI debate, I don't think it's the right place to argue on this forum, but I will only add that network command line tools are way less prone to bugs than any GUI tools. Moreover, you don't even have to download, install or update anything, they come built-in with OSes, even in 2021. There must be a good reason for that... My guess is that if you happen to be cutoff from the internet because of a communication problem, you have to rely on something to get back on your feet. Might be a good thing to learn the ropes of using simple command line tools, which anyone here - as you also stated - has the ability to grab. I'd recommend anyone to learn basic command line tools well before trying out any graphical wireshark/pcap/tcpdump analyzer. Well, it seems like you got me started after all. 😉 Sorry about that everybody. At least, now you know where I stand... 

As for your other comments, I'd say that I agree it's good practice to look at the plumbering stuff (lower layers) first, but really solving (like definitively, not "just make it work" for some time until the next software update) most common communication problems beyond those obvious ones also requires looking at least at the TCP/IP layers these days, especially if you don't have an infinite budget to replace everything out of trial and errors and/or infinite amount of time to spend on it (I'm sure most of us would rather spend this precious time under clear skies with their latest AP equipment). 

That is also exactly what PingPlotter does BTW: it compiles and presents statistics from - you stated it - ping and tracert requests which uses a L3 protocol (ICMP) running in the background.


Clear skies,
Sébastien


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Christopher Erickson <christopher.k.erickson@...>
Envoyé : 6 mai 2021 16:24
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] Losing Communications with the Mount
 
My experience with TCP comes from 30 years of telecommunications and robotics engineering. My primary concerns are much more with Layer-1 of the OSI model (cables, connectors) and Layer-2 (Ethernet frames), not Layer-3 (IP packets) or Layer-4 (TCP/UDP.) 

OSI Layers 1 & 2 are VERY opaque to the average user so consequently they are usually ignored when troubleshooting. I think this is typically a mistake. Sort of like looking for your car keys under a nice streetlight instead of next to your car, where you dropped them. 

PingPlotter is a very graphical, visual troubleshooting tool that has a free version. It is PROFOUNDLY better and more intuitive than using the DOS prompt command line Ping command. PingPlotter also incorporates a very nice, visual, graphical, dynamic traceroute. Download it and try it out. You won't go back to the nasty DOS prompt command line ever again, unless forced to on a strange machine. 

I agree Wireshark is a complicated tool. I already stated that. However I believe that the typical AP mount owner is more qualified than the average person to gain benefit from it, given some time. I would add that starting with PingPlotter instead of Wireshark would be good.

It could be bad to have a firewall or router in between the CP4/5 and the observatory PC. If there is, it might have LAN packet filtering capabilities, which I would disable, if I could.

-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   

Join main@ap-gto.groups.io to automatically receive all group messages.