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