Finding root cause of TigerVNC multi-minute pauses via ComCast; why "* * *"

Question

What are some techniques for tracking down root cause(s) of intermittent, sometimes very long delays in TigerVNC sessions?

Working remotely via SSH using TigerVNC. Most of the time the screen is responsive. However, many times a day, there are delays in response; these can range from half a second to as high as several minutes, with characters typed and mouse movement and actions remaining buffered. This is very disruptive, when it occurs in the middle of writing a line of code.

During these delays, pings go through (so far) without any issues, and other Internet access works fine.

We are on ComCast with a relatively high performance plan. WiFi is not an issue, as my laptop is hardwired through a switch to our router / cable modem. The company I'm working for is on a different ISP. IT says that others with ComCast have had similar problems, however there are no other ISP options currently available where I live.

A traceroute (slightly redacted)... pauses at Hop 9, and shows * * * for that hop.

scott@scott-HP-Pavilion-15-dk0xxx:~$ traceroute <redacted>.com
traceroute to <redacted> (<redacted>), 64 hops max
  1   192.168.0.1  0.660ms  1.224ms  0.691ms 
  2   <redacted>  12.768ms  13.083ms  9.222ms 
  3   24.153.80.113  12.028ms  9.766ms  10.039ms 
  4   69.139.164.217  11.650ms  17.848ms  10.298ms 
  5   24.124.128.249  14.816ms  10.285ms  10.711ms 
  6   68.86.93.165  11.076ms  15.245ms  11.115ms 
  7   96.110.40.89  11.764ms  12.553ms  10.458ms 
  8   96.110.32.234  10.686ms  9.901ms  10.849ms 
  9   *  *  *    <---  this part runs slowly.
 10   64.125.23.46  11.342ms  9.551ms  8.964ms 
 11   64.125.29.3  10.094ms  11.916ms  11.782ms 
 12   64.125.36.106  11.953ms  9.912ms  9.900ms 
 13   <redacted>  14.820ms  9.314ms  10.101ms 
 14   <redacted>  12.224ms  9.792ms  10.748ms 
 15   <redacted>  10.585ms  11.545ms  12.545ms 
 16   *  *  * 
...
 64   *  *  *

A call to Comcast tech support has so far produced a support ticket number, a perhaps-reflexive attempt to get me to change our (fairly new) cable modem, and (to date) no return call. However the problem is not slow speed during normal operation, and our connection does not (to my knowledge) drop; pings and other Internet access continue working with no delays during the pauses, and keystrokes and mouse actions remain buffered.

I would appreciate any ideas for:

How to isolate the issue to software, a networking issue or ?
Tools to help isolate
If the latter, how to tell our ISP what is wrong, in the hopes that this will percolate through to someone with the access to fix it
How to get past this (just possibly renting an office where another ISP is available)

Edit: per suggestion to use sudo journalctl -b 0 -u NetworkManager:

logs show many triplets of:

connectivity: (en01) timed out, immediately followed by:
manager: NetworkManager state is now CONNECTED_SITE,
Then after a 4 min 31 second delay(?) every time:
manager: NetworkManager state is now CONNECTED_GLOBAL sequences.

Example, with system name trimmed:

Oct 24 17:14:06 <name> NetworkManager[1065]: <info>  [1635120846.1948] connectivity: (eno1) timed out
Oct 24 17:14:06 <name> NetworkManager[1065]: <info>  [1635120846.1949] manager: NetworkManager state is now CONNECTED_SITE
Oct 24 17:18:37 <name> NetworkManager[1065]: <info>  [1635121117.3196] manager: NetworkManager state is now CONNECTED_GLOBAL

Step 9 "runs slowly" because the node at hop 9 doesn't respond to the IP packets sent by `traceroute`. The only way `traceroute` can tell that there is no response is by an expiring timeout. Timeouts are long. Times 3. — waltinator, Oct 23 '21 at 05:23
Does your system have `journalctl`? `systemd`? Please describe your system. Read https://askubuntu.com/questions/-to-ask — waltinator, Oct 23 '21 at 05:28
@waltinator it has `journalctl` and `systemd`. The 'askubuntu' link is broken. — Technophile, Oct 24 '21 at 21:58
Then look at the logs! `sudo journalctl -b 0 -u NetworkManager`. Read `man journalctl`. — waltinator, Oct 25 '21 at 01:00

score 2 · Answer 1 · edited Feb 22 '23 at 10:21

IP packets have a Time-To-Live field designed to prevent packets looping forever.

Every router is required to reduce the TTL field each time the packet is forwarded.

When the TTL gets below 1, the router should send back an ICMP packet saying that the TTL field had expired. In addition it must drop the packet.

traceroute works by sending out 3 packets with TTL 1, and listening for the ICMP packets. It reports the time required and where the report came from. It then sends out 3 packets with TTK 2, and reports the hosts and times. The a TTL of 3, then a TTL of 4 and so on. The program however doesn't wait indefinitly. If ur doesn't get an ICMP response the it prints a *.

So for TTL of 9 no ICMP responses are received. This might be because the router is configured not to send the responses or there might be firewall rules blocking the packets. The slowness is just waiting for the responses.

For TTL values of 16 to 64 I would blame a firewall.

All of this is perfectly normal. It doesn't provide any evidence that there is a problem.

Since you don't provide the ping data, we can't tell if there is congestion in the network.

You might find mtr https://github.com/traviscross/mtr gives you some better insight.

Finding root cause of TigerVNC multi-minute pauses via ComCast; why "* * *"

1 Answers1