APT | TLS errors when connecting to dietpi.com #7022
Labels
Milestone
Comments
|
At which command did this happen exactly? At best, could you copy&paste the full update log/output here? In case it happens during the APT update when pulling files from our APT repo: I get this by times when accessing resource on root@micha:/tmp/apt/lists# curl -I https://dietpi.com/motd
curl: (35) Recv failure: Connection reset by peer
root@micha:/tmp/apt/lists# wget --spider https://dietpi.com/motd
Spider mode enabled. Check if remote file exists.
--2024-04-15 23:44:25-- https://dietpi.com/motd
Resolving dietpi.com (dietpi.com)... 2606:4700:20::ac43:4565, 2606:4700:20::681a:4f3, 2606:4700:20::681a:5f3, ...
Connecting to dietpi.com (dietpi.com)|2606:4700:20::ac43:4565|:443... connected.
GnuTLS: Error in the pull function.
Unable to establish SSL connection.Since APT uses GnuTLS as well, it could happen when updating/upgrading from our new APT repo. If so, I'll open a ticket to get this investigated. Disabling IPv4 solves it permanently here, but this is really not something I want to accept. We even temporarily switched to the Cloudflare Pro plan to test some routing optimisations, but while it helped for another issue, it did not help in my case. |
|
|
as workaround, you can try to disable IPv6 |
|
Yes, or just "Retry" from the error handler. Okay I'll open a ticket with Cloudflare. It is really an issue with their edge server(s), maybe in combination with some settings, as it does not happen when accessing our server directly. |
MichaIng
added
Priority 🔆
External bug 🐞
|
Retry did not work, i tried it several times but always ran into the same issue. |
|
I'm having the same problem
Details:
Steps to reproduce:
Expected behaviour:
Actual behaviour:
Extra details:
Additional logs: |
It's different problem
Somehow the public key is missing. 🤔 Usually this should be applied during update |
|
The keys are there, but all not readable: Please check the permissions for this and all parent directories: ls -dl /etc /etc/apt /etc/apt/trusted.gpg.d
ls -l /etc/apt/trusted.gpg.d |
As you told me, I think the permission for the public key file is wrong I think "Other" read permission was lost due to umask setting while downloading the public key file |
|
Ah right, it was our key only, but since it is in Probably we should set it to |
The default umask value is 0022. However, before running the detpi-update, I set the umask value to 0027 The current "/etc/apt/trusted.gpg.d/dietpi.asc" file has been successfully read and the dietpi-update has been successfully run Later, I checked the permissions of the "/etc/apt/sources.list.d/dietpi.list" file and found that you still don't have read permissions |
|
Okay, then the lists are not read by this I think it is indeed best when we actively set It aligns with the enforced |
MichaIng
changed the title
|
For the record: https://community.cloudflare.com/t/intermittent-tls-errors-when-accessing-websites-behind-cloudflare-via-ipv6/650353 Probably you can go through the tests/points and see whether it is all the same for you. Also, if you want to share, which country/location/ISP/router are you using? Probably we find some similarities/pattern. Checking logs above, |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Creating a bug report/issue
Required Information
G_DIETPI_VERSION_CORE=9 G_DIETPI_VERSION_SUB=2 G_DIETPI_VERSION_RC=1 G_GITBRANCH='master'bullseye 0Linux homePI 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/LinuxRPI Model 4or (EG: RPi3)Additional Information (if applicable)
echo $G_HW_UUIDSteps to reproduce
Expected behaviour
Actual behaviour
Extra details
The text was updated successfully, but these errors were encountered: