search

tun2proxy / rust-tun

TUN device creation and handling.
https://docs.rs/tun2/
42 stars 20 forks source link

Error handling for Wintun device creation #113

Open mokhtarabadi opened 2 hours ago

mokhtarabadi commented 2 hours ago

When I set the TUN device name to an ID like wintun11, my app sometimes fails to start and returns the following errors:

2024-09-29T12:41:36.015942Z TRACE tun2::platform::windows: Windows configuration device GUID    
2024-09-29T12:41:36.066414Z ERROR wintun_bindings::log: WinTun: Failed to find matching adapter name: Element not found. (Code 0x00000490)    
2024-09-29T12:41:36.147522Z INFO wintun_bindings::log: WinTun: Using existing driver 0.14    
2024-09-29T12:41:36.154062Z INFO wintun_bindings::log: WinTun: Creating adapter    
2024-09-29T12:41:51.189632Z ERROR wintun_bindings::log: WinTun: Timed out waiting for device query: The wait operation timed out. (Code 0x00000102)    
2024-09-29T12:41:51.189926Z ERROR wintun_bindings::log: WinTun: Failed to setup adapter (problem code: 0x1F, ntstatus: 0xC0000035): Cannot create a file when that file already exists. (Code 0x000000B7)

Interestingly, the app works on the second attempt, successfully creating the Wintun device.

I suggest refactoring the Windows device implementation to return errors instead of just logging them. This would especially help with handling the Cannot create a file when that file already exists error in my application.

Thank you!

ssrlive commented 2 hours ago

The wintun_bindings::log: WinTun: is in a callback function. And it can not return an error to the caller.

mokhtarabadi commented 2 hours ago

Any workaround? How can I ensure the device created or error occurs? I check tun2proxy that also has this bug

ssrlive commented 2 hours ago

here is the callback setting point. PR welcome. Maybe we can use a global variant to store the error info and read it from the normal logic of wintun.

https://github.com/tun2proxy/wintun-bindings/blob/96a597907b3989e6e4ad74838bb6bf85b062809d/src/adapter.rs#L81