check exponential backoff on receiving AUTH_FAILED
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 14.6k
- Forks
- 3.4k
- PR merge metrics
- No merged PRs in 30d
Description
Observation: a 2.5.6 client connects to a server that refuses entry (due to "account locked out")
Dec 9 19:48:54 hilbov ovpn-medat-ma-tun99[875]: client-XX/2003:d1:2:3::4 SENT CONTROL [client-XX]: 'AUTH_FAILED' (status=1)
will keep reconnecting every 5 seconds - for many hours (auth-retry nointeract in the config).
I think this should be subject to exponential backoff, exactly as "tls failure" or "connect failure". This just fills logs.
It needs to be tested if this is a 2.5 thing ("upgrade client") or 2.6/2.7 behave the same way.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the reconnect loop with a 2.5.6 client, a refused login, and auth-retry nointeract, then compare the behavior with 2.6 and 2.7. Trace the existing handling for TLS and connection failures; done means AUTH_FAILED no longer retries every five seconds and the behavior is covered by a regression test.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- authentication, networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100