Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure client DNS happens as soon as possible #4309

Closed
jamilbk opened this issue Mar 25, 2024 · 2 comments · Fixed by #4133
Closed

Ensure client DNS happens as soon as possible #4309

jamilbk opened this issue Mar 25, 2024 · 2 comments · Fixed by #4133
Assignees
Labels
area/apple_client Issues related to the Apple client
Milestone

Comments

@jamilbk
Copy link
Member

jamilbk commented Mar 25, 2024

No description provided.

@jamilbk jamilbk added the area/apple_client Issues related to the Apple client label Mar 25, 2024
@jamilbk jamilbk added this to the 1.0 GA milestone Mar 25, 2024
@ReactorScram
Copy link
Collaborator

ReactorScram commented Mar 25, 2024

Yeah this was something that concerned me about the set_interface_config vs on_tunnel_ready, there really must be something to mean "You can start a query / request right now and it will eventually work". Otherwise we can get stuck with an old DNS response in the cache because the user thought Firezone was ready and it was only half-ready.

I'm pretty sure I did not visit speed.cloudflare.com before I updated and opened Firezone, but I don't have any logs from Firefox to prove that.

  • macOS Sonoma 14.3.1
  • Firezone Version 1.0.0 (1711374323)
  • Network: USB-C hub with Ethernet plugged in, and Wi-Fi

Logs in our private Slack: https://firezonehq.slack.com/archives/C067DSY7TFX/p1711387570641589?thread_ts=1711385581.483049&cid=C067DSY7TFX

I think it happened around 16:45, I'll put a more precise time if I look at the logs later.

@ReactorScram
Copy link
Collaborator

ReactorScram commented Mar 25, 2024

In my specific case, Firefox was using DoH and ignoring the system DNS resolvers. So that's a KB issue (#4310), and the tunnel_ready callback might be unrelated

@jamilbk jamilbk self-assigned this Mar 25, 2024
github-merge-queue bot pushed a commit that referenced this issue Mar 27, 2024
Tried to organize this PR into commits so that it's a bit easier to
review.

1. Involves simplifying the logic in Adapter.swift so that us mortals
can maintain it confidently:
- The `.stoppingTunnel`, `.stoppedTunnelTemporarily`, and
`.stoppingTunnelTemporarily` states have been removed.
- I also removed the `self.` prefix from local vars when it's not
necessary to use it, to be more consistent.
- `onTunnelReady` and `getSystemDefaultResolvers` has been removed, and
`onUpdateRoutes` wired up, along with cleanup necessary to support that.
2. Involves adding the `reconnect` and `set_dns` stubs in the FFI and
fixing the log filter so that we can log them (see #4182 )
3. Involves getting the path update handler working well on macOS using
`SystemConfiguration` to read DNS servers.
4. Involves getting the path update handler working well on iOS by
employing careful trickery to prevent path update cycles by detecting if
`path.gateways` has changed, and avoid setting new DNS if it hasn't.

Refs #4028 
Fixes #4297
Fixes #3565 
Fixes #3429 
Fixes #4175 
Fixes #4176 
Fixes #4309

---------

Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/apple_client Issues related to the Apple client
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants