Skip to content

support processing other packet from ipstack - #15

Closed
xmh0511 wants to merge 1 commit into
narrowlink:mainfrom
xmh0511:main
Closed

xmh0511 wants to merge 1 commit into
narrowlink:mainfrom
xmh0511:main

Conversation

@xmh0511

@xmh0511 xmh0511 commented Jan 19, 2024

Copy link
Copy Markdown
Contributor

No description provided.

Comment thread Cargo.toml
tokio = { version = "1.35", features = [
"rt-multi-thread",
], default-features = false }
packet = "0.1.4"

@SajjadPourali SajjadPourali Jan 19, 2024 •

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am hesitant to use this dependency even in the examples since it is left unmaintained.

@SajjadPourali

SajjadPourali commented Jan 19, 2024 •

Copy link
Copy Markdown
Collaborator

It is better to create two types for the IpStackStream: one for UnknownTransport, which we know is IP but is neither TCP nor UDP, and another for UnknowNetwork for anything that is not IP. I believe these types allow users to implement their protocols manually.


Since ICMP is not primarily designed to transfer data, we have to create an enum that supports the most useful types of ICMP in the IpStack usage scenarios, such as Echo.

@SajjadPourali

SajjadPourali commented Jan 19, 2024 •

Copy link
Copy Markdown
Collaborator

Something like this?

670226a


pub enum IpStackStream {
Tcp(IpStackTcpStream),
Udp(IpStackUdpStream),
UnknownTransport(IpStackUnknownTransport), // todo: fix lint error
UnknownNetwork(Vec<u8>), // todo: fix lint errorP
}

@SajjadPourali SajjadPourali self-assigned this Jan 19, 2024
@xmh0511

xmh0511 commented Jan 20, 2024 •

Copy link
Copy Markdown
Contributor Author

I think providing the raw packet produced by tun for all the other cases other than tcp and udp has the maximum flexible because we may want to do the following things:

  1. process the packet by using the familiar crate.
  2. send the complete packet to the remote to be processed.

Even for Icmp packet, if we pre-process it to produce IpStackUnknownTransport, we can only get the payload, or we must re-produce the original packet from the result, which is not necessary.

@SajjadPourali

SajjadPourali commented Jan 21, 2024 •

Copy link
Copy Markdown
Collaborator

@xmh0511: could you please check examples/tun.rs in the main branch?

https://github.com/narrowlink/ipstack/blob/main/examples/tun.rs#L113-L134

Screenshot 2024-01-20 at 8 06 59 PM

@xmh0511

xmh0511 commented Jan 21, 2024

Copy link
Copy Markdown
Contributor Author

@SajjadPourali I have tried the latest version. Currently, in the branch IpStackStream::UnknownTransport(u), u.payload() will return the payload part of the IP packet, which is the ICMP message, and u.send just need the ICMP message too, right?

@SajjadPourali

Copy link
Copy Markdown
Collaborator

@SajjadPourali I have tried the latest version. Currently, in the branch IpStackStream::UnknownTransport(u), u.payload() will return the payload part of the IP packet, which is the ICMP message, and u.send just need the ICMP message too, right?

True, there also another one that called UnknownNetwork that is similar to the raw that you mentioned.

@xmh0511 xmh0511 closed this Jan 22, 2024
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 this pull request may close these issues.

2 participants