Prev: Simple Hack To Get $2500 To Your PayPal Account.
Next: Dropping root permissions
From: pk on 24 Jul 2010 13:43
On Sat, 24 Jul 2010 18:39:45 +0200
Andrea Crotti <andrea.crotti.0(a)gmail.com> wrote:

>
> > You're mixing two different things. A raw socket is on the kernel side
> > (ie, data written to it is sent out the interface, data arriving at the
> > interface is available from the raw socket), the file descriptor is on
> > the "wire" side (data written to it appears "from the wire" to the
> > kernel, and when the kernel sends data to the interface it is available
> > for reading on the file descriptor).
> >
> > IF you use a raw socket, as far as I know iptables rules are NOT
> > traversed.
>
> Ah great now it's more clear, and how does the kernel "listens" on those
> interfaces, some kind of big select?

I don't know how it is implemented, but probably there is some code that
bypasses the netfilter logic when a raw socket is used. (maybe the truth is
different, but I don't know enough of the internals to give a better
answer; it might even be not 100% correct).

> > Read blocks presumably because there's nothing to read. For the read to
> > read something, the kernel would have to route one packet out the tun
> > interface (on "the wire"), and if that happened your read would catch
> > it.
>
> Yes that's probably why, but that leads to another question, how am I
> then supposed to tell the kernel to write something on that tun
> interface?

The same way you tell the kernel to send packets out any interface.
How do you "tell" the kernel to send packets out eth0?

> Only sending packets to the ip address associated with that device would
> work??

That will not send any packet *out* the interface, because the destination
IP address is local, so you've mentioned the only case where the tun
descriptor will not get traffic.
From: Andrea Crotti on 24 Jul 2010 19:00

>
> I don't know how it is implemented, but probably there is some code that
> bypasses the netfilter logic when a raw socket is used. (maybe the truth is
> different, but I don't know enough of the internals to give a better
> answer; it might even be not 100% correct).

Mm but still I don't get then how should I write my own code for
networking then...
>
> That will not send any packet *out* the interface, because the destination
> IP address is local, so you've mentioned the only case where the tun
> descriptor will not get traffic.

What I want to do is simply send data *into* the interface and read data
out of it.

If you say that socket is not the way and also "write" isn't how then am
I supposed to accomplish this then??

Thanks a lot!
Andrea
From: pk on 25 Jul 2010 06:45
On Sun, 25 Jul 2010 01:00:29 +0200 Andrea Crotti
<andrea.crotti.0(a)gmail.com> wrote:

>
> >
> > I don't know how it is implemented, but probably there is some code that
> > bypasses the netfilter logic when a raw socket is used. (maybe the
> > truth is different, but I don't know enough of the internals to give a
> > better answer; it might even be not 100% correct).
>
> Mm but still I don't get then how should I write my own code for
> networking then...

To be honest, I still don't get what you are *really* trying to do.

> > That will not send any packet *out* the interface, because the
> > destination IP address is local, so you've mentioned the only case
> > where the tun descriptor will not get traffic.
>
> What I want to do is simply send data *into* the interface and read data
> out of it.
>
> If you say that socket is not the way and also "write" isn't how then am
> I supposed to accomplish this then??

That is not how tun interfaces are supposed to work. Probably you have a
misunderstanding. When you use a tun interface, if you want it to be
useful, you have to have a program that uses the associated descriptor.
What it does with that data can vary; it may use it to communicate with a
virtual machine, or it may establish a tunnel to another machine where a
similar arrangement is in place, to create a virtual network link, or
whatever.
But if you don't have such a program, then the tun interface is
like a black hole and is not useful; it might be compared to having a
physical interface (eg eth0) that is disconnected.
From: Andrea Crotti on 25 Jul 2010 07:56
>
> To be honest, I still don't get what you are *really* trying to do.

So we're working with motes (telosb) which are very small devices with a
few resources that talk via radio and usb when they're connected.

We need to be able to have
- 1 gateaway with a mote attached connected to the internet
- 1 client with a mote attached not connected

And be able to let the client connect through the mote.
So in theory we setup some routing/iptables rules, then
read data from usb - write on the tun device *and* viceversa.

>
> That is not how tun interfaces are supposed to work. Probably you have a
> misunderstanding. When you use a tun interface, if you want it to be
> useful, you have to have a program that uses the associated descriptor.
> What it does with that data can vary; it may use it to communicate with a
> virtual machine, or it may establish a tunnel to another machine where a
> similar arrangement is in place, to create a virtual network link, or
> whatever.
> But if you don't have such a program, then the tun interface is
> like a black hole and is not useful; it might be compared to having a
> physical interface (eg eth0) that is disconnected.

It's not a problem to keep the file descriptor, but you said that
writing on the file descriptor doesn't work for later reading, so how
should I do this?
From: pk on 25 Jul 2010 08:33
On Sun, 25 Jul 2010 13:56:00 +0200 Andrea Crotti
<andrea.crotti.0(a)gmail.com> wrote:

> >
> > To be honest, I still don't get what you are *really* trying to do.
>
> So we're working with motes (telosb) which are very small devices with a
> few resources that talk via radio and usb when they're connected.
>
> We need to be able to have
> - 1 gateaway with a mote attached connected to the internet
> - 1 client with a mote attached not connected
>
> And be able to let the client connect through the mote.
> So in theory we setup some routing/iptables rules, then
> read data from usb - write on the tun device *and* viceversa.
>
> > That is not how tun interfaces are supposed to work. Probably you have a
> > misunderstanding. When you use a tun interface, if you want it to be
> > useful, you have to have a program that uses the associated descriptor.
> > What it does with that data can vary; it may use it to communicate with
> > a virtual machine, or it may establish a tunnel to another machine
> > where a similar arrangement is in place, to create a virtual network
> > link, or whatever.
> > But if you don't have such a program, then the tun interface is
> > like a black hole and is not useful; it might be compared to having a
> > physical interface (eg eth0) that is disconnected.
>
> It's not a problem to keep the file descriptor, but you said that
> writing on the file descriptor doesn't work for later reading, so how
> should I do this?

You're still not getting it - the tun device is not some magical device.
It's a normal interface. You can't just throw data at it and expect it to
magically give you back something.

As I repeatedly say, think how eth0 works - if you write something into it,
does it automatically mean you also get something back? Or, in the other
direction, if you read something from it, does that mean that something
must subsequently be written to it?

As I hope you know, the answer to those questions is "it depends". In any
case, nothing happens magically; if you receive data, that data must have
been generated somewhere. If you write data, you need an application that
generates that data.

The descriptor associated to the tun interface implements a virtual
"physical layer" which, to the kernel, looks like a "wire" where data
from/to the tun device is written/read.

One way it can be used is by implementing something like a select()
loop on the tun descriptor, to be woken up when there is something to read
or write. When will that be? Again, it depends. You will have data
available for reading on the tun descriptor when the kernel decides that
some packet has to be sent out the tun interface. When will that be? It
depends. For example, when the kernel has to route a packet and sees
that the route for the destination IP points out the tun interface.

For writing: when will you write to the tun descriptor? It depends. For
example, when you have an IP packet available (including headers). Where do
you get it? It depends. You may build it yourself, you may get it from a
virtual machine you're communicating with, or you may receive it over a TCP
or UDP connection to another computer (this is what some tunneling
applications do - the remote computer must be doing the same things in
reverse). Once you've written the packet to the tun descriptor, the kernel
will see an incoming packet and process it as usual.

Basically, you have to fool the kernel so that it thinks it's really
reading/writing packets from/to the wire. Write to the tun descriptor, and
the kernel will think a packet has arrived from the wire; read from the tun
descriptor, and you will receive the packets that the kernel thinks have to
be sent out the tun interface onto the wire, *if and when* the kernel does
so (except "the wire" is your code, of course).

Sorry, I'm not able to make it clearer than this.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Simple Hack To Get $2500 To Your PayPal Account.
Next: Dropping root permissions