# bash kasm_release/install.sh fails with "httpReadSeeker" due to TLS timeout

[jkimmer]

Noob Warning!

I'm new to the Kasm Community and am trying out container streaming for a project I'm currently involved. Unfortunately I've been unable to successfully install a single server for some "experience" testing to see if this is something that will work for my project.

Rather than simply giving up and moving on, I figured I'd try to open my first issue on git for an inconvenience with a project I'd really like to give a try.

• All I was doing was following the documentation for installing a single server with the following commands:

cd /tmp
curl -O https://kasm-static-content.s3.amazonaws.com/kasm_release_1.18.1.tar.gz
tar -xf kasm_release_1.18.1.tar.gz
sudo bash kasm_release/install.sh

• I'm currently installing into a VM running RHEL 9.7 with the following specs:
  | ROLE | CPU | RAM | HDD |
  | :--- | :---: | :---: | :---: |
  | WebApp | 4 | 4 | 70 |
  | Database | 4 | 4 | 50 |
  | Agent | 2 | 4 | 120 |
  | Recording | 8 | 4 | 80 |
  | Total | 18 | 16 | 320 | <-- Current Config

• Journal Log Output (edited for brevity)

Database Initialization Complete
Not seeding default Workspaces Images.
Setting Seed file as /opt/kasm/1.18.1/conf/database/seed_data/default_agents.yaml
Mar 03 15:54:54 kasm.jfklabs.com bash[84560]:  73937cf3b07f Downloading 14.68MB
Mar 03 15:54:54 kasm.jfklabs.com bash[84560]:  645b85541537 Downloading 1.049MB
.
.
Mar 03 15:54:55 kasm.jfklabs.com bash[84560]:  73937cf3b07f Downloading 17.83MB
Mar 03 15:54:55 kasm.jfklabs.com bash[84560]:  1dfa9fdb99b4 Downloading 1.049MB
Mar 03 15:54:55 kasm.jfklabs.com bash[84560]: failed to copy: httpReadSeeker: failed open: failed to do request: Get "https://production.cloudflare.docker.com/registry-v2/docker/registry/v2/blobs/sha256/7e/7e49dc6156b0b532730614d83a65ae5e7ce61e966b0498703d333b4d03505e4f/data?expires=1772577884&signature=TECvv9cSblnnjqBYFtRT7drOSfE%3D&version=3": net/http: TLS handshake timeout
Mar 03 15:54:55 kasm.jfklabs.com systemd[1]: kasm.service: Main process exited, code=exited, status=1/FAILURE

• I'm not certain if this collection of information I've provided is of any value so if anything else is needed, please let me know and I'd be happy to do my best!

Thank you all!!!

JFK

[teja-kasm]

Hi there,
This looks like an issue with the Docker Hub's CDN delivery layer (Cloudflare) and not with the Kasm install script itself.

The error you're seeing net/http: TLS handshake timeout means the VM could not complete a TLS handshake with Cloudflare's CDN. This is not a Kasm bug - it's a network/firewall/proxy issue on the VM or host environment.

Do you have a firewall/proxy in place for your VM? If so, I'd recommend removing it temporarily and trying the installation again.

Another potential cause of the TLS handshake timeout you're seeing during the Docker image pull is an MTU mismatch between Docker and your network path.

Docker defaults to an MTU of 1500 regardless of your actual network's capacity. If your host network's MTU is smaller than the Docker's MTU, when Docker tries to send a packet larger than your network path can handle -> the packet gets silently dropped which can produce the TLS handshake error

To ensure your host's MTU and docker's MTU match, you can follow these steps:

1. Check your host interface MTU

ip link show

Look for your main network interface (e.g. eth0, ens3) and note the mtu value.

2. Check Docker's MTU

sudo docker network inspect bridge | grep -i mtu

Notice if there's a discrepancy in both the MTU values

3. Test the actual working end-to-end path MTU
   Let's say your Docker MTU is 1500, you can send ping requests of payloads of similar sizes to check if MTU is an issue.

# Note: The total payload size includes payload size + IP header + ICMP header
ping -M do -s 1472 production.cloudflare.docker.com   # tests 1500 byte path - Docker's default max MTU
ping -M do -s 1422 production.cloudflare.docker.com   # 1450 bytes total
ping -M do -s 1372 production.cloudflare.docker.com   # 1400 bytes total
ping -M do -s 1322 production.cloudflare.docker.com   # 1350 bytes total
ping -M do -s 1272 production.cloudflare.docker.com   # 1300 bytes total

The largest packet size that succeeds tells you what your path can actually carry. You would then need to change your Docker's MTU accordingly.

Hope this helps!

[jkimmer]

I appreciate you getting back to me. I've reviewed your suggestion and did some testing. At first it didn't appear as an MTU issue since all pings went through to "production.cloudflare.docker.com" just fine. I decided to run a wireshark trace to see exactly what was going on and found some interesting points to provide you:

• After executing "install.sh" script, I could see that all data download transactions were with ip address 104.16.97.215 (production.cloudflare.docker.com) using TLSv1.2
• After about 11.5 minutes, around the time you see "Setting up firewalld rules", I see the first sign of an issue:
  • A new IP address is introduced: 52.54.160.207 (registry.hub.docker.com), along with a switch to TLSv1.3.
  • The session with the new ip address is pretty short lived so nothing failed at that point.
  • Right around the time you see the message "Installing docker loggin plugin: kasmweb/kasm-logging-plugin", the flow switches back to TLSv1.2 and original host ip 104.16.97.215 for a bit longer.
• Around the time you see the message "Installing docker loggin plugin: kasmweb/kasm-logging-plugin", the flow switches back to TLSv1.2 and original host ip 104.16.97.215 for a bit longer.
• A few minutes later, right around the 12.5 minute mark or so, the installation scripts start to build everything, docker is restarted, and the Kasm Service is being Started.
• It's at this very point, the host with IP 52.54.160.207 is reintroduced along with TLSv1.3 which is when the entire script fails and aborts entirely.

When I used "ping -M do....." command with the TLSv1.3 enpoint, I certainly did have to adjust the MTU down in order to get pings to go through but it was around 1464 when the pings would go through again.

I did change the docker MTU setting 1464, 1300, 1200, and even 1000 and the failure scenerio was identical each time. The issue has something to do with communication with the registry.hub.docker.com address that's being accessed during the "Setting up Firewall Rules" and "Starting Kasm Services" areas of the install script.

That's all I could dig up out of my Wireshark capture.

Thanks again and please let me know if there's anything else I could try.

JFK

PS: I failed to mention that I'm trying the OVA to see how much luck I have with it.

[jkimmer]

The OVA method of installing took care of what I needed despite the inability to use the "install.sh" script. If you decide to troubleshoot further, I'd love to hear if you've found anything!