Hi, this may be a slightly unusual request, so I want to explain the use case.
I am building a lab/networking tool called Kraken: https://github.com/yisrael-haber/kraken
The project uses gVisor user-space netstacks and Starlark scripting to let users create independent network identities and then interact with the network through those identities. The goal is to give users a UI where they can adopt/build identities, inspect and modify lower-level packet flow, and run higher-level scripts and services through the same underlying network engine.
In practice, this means I try hard to make all client/server networking go through the tool’s own network stacks instead of directly through the host OS. For example, Kraken has embedded echo/HTTP/HTTPS/SSH services and identity-backed scripting sockets, so traffic can be tied clearly to a specific modeled identity.
I have been looking at using this project as a protocol library inside that scripting/runtime layer. A lot of the code is very useful for this: packet parsing/generation, DCE/RPC, NTLM, SMB-related code, and the Windows protocol packages in general.
The main difficulty is that some subpackages appear to create their own network connections internally, or otherwise assume OS-backed dialing. That is a reasonable default for normal tool usage, but it makes it hard to use those packages in projects where the network transport needs to be supplied by the caller.
What would help a lot is having more package APIs accept one of these shapes where possible:
- an existing
net.Conn
- a small dialer interface
- a
context.Context aware dial function
- an already-created protocol client/session, such as an existing DCE/RPC client
I am not asking for the command-line tools to change behavior. The default path can still use normal OS networking. The request is mainly for the reusable packages to make the transport injectable where it is practical, so projects like mine can route traffic through custom stacks.
I would be happy to help contribute this if it fits the direction of the project. I do not want to push a design that conflicts with your goals, though, so I wanted to open an issue first and ask whether this kind of change would be welcome.
The goal is not to make every package abstract. It is just to make the network boundary injectable in places where the protocol logic is otherwise reusable.
Thanks for the work on this project. It is already useful for the kind of protocol scripting and lab tooling I am trying to build.
Hi, this may be a slightly unusual request, so I want to explain the use case.
I am building a lab/networking tool called Kraken: https://github.com/yisrael-haber/kraken
The project uses gVisor user-space netstacks and Starlark scripting to let users create independent network identities and then interact with the network through those identities. The goal is to give users a UI where they can adopt/build identities, inspect and modify lower-level packet flow, and run higher-level scripts and services through the same underlying network engine.
In practice, this means I try hard to make all client/server networking go through the tool’s own network stacks instead of directly through the host OS. For example, Kraken has embedded echo/HTTP/HTTPS/SSH services and identity-backed scripting sockets, so traffic can be tied clearly to a specific modeled identity.
I have been looking at using this project as a protocol library inside that scripting/runtime layer. A lot of the code is very useful for this: packet parsing/generation, DCE/RPC, NTLM, SMB-related code, and the Windows protocol packages in general.
The main difficulty is that some subpackages appear to create their own network connections internally, or otherwise assume OS-backed dialing. That is a reasonable default for normal tool usage, but it makes it hard to use those packages in projects where the network transport needs to be supplied by the caller.
What would help a lot is having more package APIs accept one of these shapes where possible:
net.Conncontext.Contextaware dial functionI am not asking for the command-line tools to change behavior. The default path can still use normal OS networking. The request is mainly for the reusable packages to make the transport injectable where it is practical, so projects like mine can route traffic through custom stacks.
I would be happy to help contribute this if it fits the direction of the project. I do not want to push a design that conflicts with your goals, though, so I wanted to open an issue first and ask whether this kind of change would be welcome.
The goal is not to make every package abstract. It is just to make the network boundary injectable in places where the protocol logic is otherwise reusable.
Thanks for the work on this project. It is already useful for the kind of protocol scripting and lab tooling I am trying to build.