fix: make DialTimeout configurable via config

[parziva-1]

Summary

Makes DialTimeout configurable while keeping the default at 10s. Users on slower hardware (e.g. Raspberry Pi) can increase it via config to avoid MTProto handshake timeouts during DH key exchange.

Changes

• internal/config/config.go — add DialTimeout field with default:"10s"
• internal/tgc/tgc.go — use config.DialTimeout instead of hardcoded 10 * time.Second
• config.sample.yml — document the new dial-timeout option

Config usage

[tg]
dial-timeout = "60s"

tg:
  dial-timeout: "60s"

Also configurable via TELDRIVE_TG_DIAL_TIMEOUT=60s or --tg-dial-timeout 60s.

Fixes #554
Ref #509

[gemini-code-assist]

Code Review

This pull request makes the Telegram dial timeout configurable, replacing a previously hardcoded 10-second value. Feedback indicates that a separate hardcoded 30-second authentication timeout in the client pool may still restrict connections if the dial timeout is increased beyond that limit, suggesting that this value should also be made configurable to fully support the intended use case.

[gemini-code-assist]

While making DialTimeout configurable is a good step for supporting slow hardware, there is a hardcoded 30s timeout in internal/tgc/client_pool.go (line 169) that governs the overall authentication wait time. If a user increases DialTimeout to a value like 60s (as suggested in the PR description), the client creation will still be aborted by the pool after 30s. To fully support the intended use case, this authentication timeout should also be made configurable or at least be increased to match the DialTimeout.

[iwconfig]

@gemini-code-assist, may i suggest simply making the authentication timeout proportional to DialTimeout (3x multiplier)

[gemini-code-assist]

That is a reasonable approach to ensure the authentication timeout scales appropriately with the dial timeout. Using a multiplier like 3x helps maintain a consistent ratio between the connection attempt and the subsequent authentication phase, which should prevent premature timeouts on slower networks while still enforcing a reasonable upper bound.

[iwconfig]

Context: #555 #556

Forgive me but you're awfully quiet.

Have you actually built and tested if this solves your issue with your raspberry pi? And FYI, since the authentication timeout is hardcoded at 30s, it means you probably don't need 60s for your RPI, but somewhere between 10s and 30s.

Also, you don't need to close the PR and open a new one every time there's an issue. Just modify your branch and do a force update. You only create unnecessary noise. Tell your AI agent to get smarter or to GTFO.

For this current PR, it looks like main was merged into your branch (which created that unnecessary "Merge pull request..." commit) instead of rebased. This is a common git mix-up, but it's easy to fix. Doing a proper rebase or cherrypick via the command line will avoids these "Merge pull request" commits.

To fix this branch without opening a new PR, run these commands to drop the merge commit, rebase properly, and force update:

1. Checkout the branch:

git checkout fix/configurable-dial-timeout-v2

2. Fetch the latest from the remote:

git fetch origin

3. Rebase onto main:
(This will automatically drop the accidental merge commit and put your work cleanly on top)

git rebase origin/main

4. Resolve conflicts (Only if the rebase pauses):
If Git says there are conflicts, resolve them in your editor, then run:

git add . # or some/path/to/your/file some/path/to/your/other/file etc
git rebase --continue

(If the rebase finishes immediately in Step 3 without an error, skip this step).

5. Force push to update THIS existing PR:
Feel free to confirm with git log before pushing.

git push --force-with-lease origin fix/configurable-dial-timeout-v2

[parziva-1]

@iwconfig thanks a lot, sorry for that. And yes, this works on my undervolted Raspberry Pi 4.

[iwconfig]

Please add dial-timeout to config.sample.toml as well

[bungabear]

It works on my raspberry pi 3 occurring #509