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

How to use it ? #11

Open
tchereau opened this issue Aug 1, 2022 · 11 comments
Open

How to use it ? #11

tchereau opened this issue Aug 1, 2022 · 11 comments
Labels
documentation Improvements or additions to documentation enhancement New feature or request help wanted Extra attention is needed StreamsAPI make it support StreamsAPI of node

Comments

@tchereau
Copy link

tchereau commented Aug 1, 2022

I created the tap
now how can I push input and read output ?
in example, if I have a serveur and a client, I've create a server, and both script can connect, now I can read data from one tap, and send it to the other ?

@tchereau
Copy link
Author

tchereau commented Aug 1, 2022

I readed the StreamAPI test unit, but there's no docs, I guess I have to use tap.pipe()/unpipe() and push/unshift, but how ?

@PupilTong
Copy link
Owner

PupilTong commented Aug 1, 2022 via email

@PupilTong
Copy link
Owner

if you have another Stream, use pipe()
If not, use
tun.write
tun.once('data', ()=>{})
tun.on('data',()=>{})

Docs will be improved, Thanks!

@PupilTong PupilTong added documentation Improvements or additions to documentation help wanted Extra attention is needed StreamsAPI make it support StreamsAPI of node enhancement New feature or request labels Aug 2, 2022
@PupilTong
Copy link
Owner

More specified examples will be posted soon.

@tchereau
Copy link
Author

tchereau commented Aug 4, 2022

if you have another Stream, use pipe() If not, use tun.write tun.once('data', ()=>{}) tun.on('data',()=>{})

Docs will be improved, Thanks!

thanks I will try it :)

@tchereau
Copy link
Author

tchereau commented Aug 4, 2022

It worked, using to machin on different network, and net library, both are connecting, and I can ping each other with the specified ipv4

client (under net.connect):

        client.on('data', (buf) => {
            console.log(`received: ${buf}`);
            tap.write(buf);
        });
        tap.on('data', (buf) => {
            console.log(`sent: ${buf}`);
            client.write(buf);
        });
    }

server (same, using net.connect):

        c.on('data', (buf) => {
            console.log(`received: ${buf}`);
            tap.write(buf);
        });
        tap.on('data', (buf) => {
            console.log(`sent: ${buf}`);
            c.write(buf);
        });
    }

image
image

@sosoba
Copy link

sosoba commented Jun 14, 2024

Is there fixed rule: one call to tap.write(buf); are one network package?

@PupilTong
Copy link
Owner

Is there fixed rule: one call to tap.write(buf); are one network package?

I think the answer is no. This is implemented under Stream API of Node.js. So I guess it is not promised behavior.

@sosoba
Copy link

sosoba commented Jun 19, 2024

I think the answer is no. This is implemented under Stream API of Node.js. So I guess it is not promised behavior.

If so, can I send the write method twice to pass the datagram halves? How will tuntap2 know to glue it together and upload it to the network as signle frame?

I found simple Tun/Tap tutorial with simple example named "Tunells" which mappipng Tun/Tap device to TCP stream. Simple VPN. This example presents the same problem as tuntap2 - mapping sending and receiving a packet through a stream. They solved the problem by wrapping the packet or datagram with a header containing its size.

  • Since the program usese TCP, the receiver will see a single stream of data, which makes recognizing packet boundaries difficult. So when a packet or frame is written to the network, its length is prepended (2 bytes) to the actual packet.
  • When data comes in from the network, thanks to the aforementioned trick, we can know how long the next packet is going to be by reading the two-bytes length that precedes it in the stream. When we've read the packet, we write it to the tun/tap interface descriptor, where it will be received by the kernel as coming "from the wire".

I have a suspicion that tuntap2 is working because the datagram size (1500B) does not exceed the standard size of buffer in the Node stream (16kB).

@PupilTong
Copy link
Owner

I think the answer is no. This is implemented under Stream API of Node.js. So I guess it is not promised behavior.

If so, can I send the write method twice to pass the datagram halves? How will tuntap2 know to glue it together and upload it to the network as signle frame?

I found simple Tun/Tap tutorial with simple example named "Tunells" which mappipng Tun/Tap device to TCP stream. Simple VPN. This example presents the same problem as tuntap2 - mapping sending and receiving a packet through a stream. They solved the problem by wrapping the packet or datagram with a header containing its size.

  • Since the program usese TCP, the receiver will see a single stream of data, which makes recognizing packet boundaries difficult. So when a packet or frame is written to the network, its length is prepended (2 bytes) to the actual packet.
  • When data comes in from the network, thanks to the aforementioned trick, we can know how long the next packet is going to be by reading the two-bytes length that precedes it in the stream. When we've read the packet, we write it to the tun/tap interface descriptor, where it will be received by the kernel as coming "from the wire".

I have a suspicion that tuntap2 is working because the datagram size (1500B) does not exceed the standard size of buffer in the Node stream (16kB).

I think it doesn't change anything about the behavior of the Node API. The tun/tap APIs in linux could just create a file descriptor and it could be used as a normal file on disk. So we just create the tun/tap fd and tell the NodeJS to read/write it

1 similar comment
@PupilTong
Copy link
Owner

I think the answer is no. This is implemented under Stream API of Node.js. So I guess it is not promised behavior.

If so, can I send the write method twice to pass the datagram halves? How will tuntap2 know to glue it together and upload it to the network as signle frame?

I found simple Tun/Tap tutorial with simple example named "Tunells" which mappipng Tun/Tap device to TCP stream. Simple VPN. This example presents the same problem as tuntap2 - mapping sending and receiving a packet through a stream. They solved the problem by wrapping the packet or datagram with a header containing its size.

  • Since the program usese TCP, the receiver will see a single stream of data, which makes recognizing packet boundaries difficult. So when a packet or frame is written to the network, its length is prepended (2 bytes) to the actual packet.
  • When data comes in from the network, thanks to the aforementioned trick, we can know how long the next packet is going to be by reading the two-bytes length that precedes it in the stream. When we've read the packet, we write it to the tun/tap interface descriptor, where it will be received by the kernel as coming "from the wire".

I have a suspicion that tuntap2 is working because the datagram size (1500B) does not exceed the standard size of buffer in the Node stream (16kB).

I think it doesn't change anything about the behavior of the Node API. The tun/tap APIs in linux could just create a file descriptor and it could be used as a normal file on disk. So we just create the tun/tap fd and tell the NodeJS to read/write it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request help wanted Extra attention is needed StreamsAPI make it support StreamsAPI of node
Projects
None yet
Development

No branches or pull requests

3 participants