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

vnet: Introduce interface for vnet.Net #168

Closed
stv0g opened this issue Feb 8, 2022 · 3 comments · Fixed by #204
Closed

vnet: Introduce interface for vnet.Net #168

stv0g opened this issue Feb 8, 2022 · 3 comments · Fixed by #204
Milestone

Comments

@stv0g
Copy link
Member

stv0g commented Feb 8, 2022

Summary

I propose to add an interface for vnet.Net which dependent packages of vnet.Net should use (e.g. pion/ice in my use case).

Motivation

cunicu is user-space daemon to establish Wireguard peer-to-peer connection via ICE.

cunicu needs to provide custom implementations of net.{Dial,Listen}{UDP,Packet} in order to attach eBPF filters to the created sockets which filter STUN and let all other traffic pass to a kernel tunnel interface.

See: https://github.com/stv0g/cunicu/blob/master/pkg/proxy/ebpf.go#L43

This allows cunicu to limit itself to handling ICE and stay out of the data path which remains fully in the kernel.

By introducing an interface for vnet.Net users could provide custom implementations for most of the functions in the net package.

Describe alternatives you've considered

We are currently providing a custom implementation of ice.UDPMux which is already an interface to do the same.

Additional context

A ice.UDPMux is currently only used for host candidates. We cant use this method for relay or reflexive candidates.
See: pion/ice#400

Also:

@Sean-Der
Copy link
Member

Sean-Der commented Feb 8, 2022

Yes this would great! I have seen other use cases that would be unblocked by this also.

@stv0g stv0g changed the title Introduce interface for vnet.Net vnet: Introduce interface for vnet.Net Feb 8, 2022
@stv0g
Copy link
Member Author

stv0g commented Feb 8, 2022

Also related: #27

@stv0g
Copy link
Member Author

stv0g commented Feb 8, 2022

@Sean-Der Thats great to hear :)

Ideally, I would name that interface identically to the currently existing struct.

However this would break the existing API and hence requires a new major version.
Would this be acceptable?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants