From: Andrea Crotti on 24 Jul 2010 10:40 Hallo everyone, I'm working on linux at the moment but I think the problem is more general. In short we need to use a tun device to communicate we - take data from the usb port - assemble it somehow - write it to the tun device Now I'm really not understanding how it should work, I've seen for example that someone uses a socket while others directly the device, is there any difference and if yes which? For example if I setup an iptables rule that work on tun0, will that work automatically EVEN if I write on the device (with "write") ? I wanted to try it out myself but I stumbled even before, I can't read what I'm writing at all: Here is the code http://gist.github.com/488724 Thanks a lot, Andrea
From: pk on 24 Jul 2010 10:58 On Sat, 24 Jul 2010 16:40:14 +0200 Andrea Crotti <andrea.crotti.0(a)gmail.com> wrote: > Hallo everyone, > I'm working on linux at the moment but I think the problem is more > general. > > In short we need to use a tun device to communicate we > - take data from the usb port > - assemble it somehow > - write it to the tun device > > Now I'm really not understanding how it should work, I've seen for > example that someone uses a socket while others directly the device, is > there any difference and if yes which? > > For example if I setup an iptables rule that work on tun0, will that > work automatically EVEN if I write on the device (with "write") ? You don't write on a tun device. What you do is write to the associated file descriptor (the one you get when the tun interface is opened). When you write something to that file descriptor, the kernel sees it as incoming "from the wire" to the tun interface, and will then apply the normal iptables rules (INPUT or FORWARD). > I wanted to try it out myself but I stumbled even before, I can't read > what I'm writing at all: > > Here is the code > http://gist.github.com/488724 Depending on what is connected to the USB port, you can use ethernet over USB (supported by Linux) and control all traffic to/from the tun interface using the usual tools.
From: Andrea Crotti on 24 Jul 2010 12:02 > > You don't write on a tun device. What you do is write to the associated > file descriptor (the one you get when the tun interface is opened). When > you write something to that file descriptor, the kernel sees it as incoming > "from the wire" to the tun interface, and will then apply the normal > iptables rules (INPUT or FORWARD). Yes sure I meant writing on the file descriptor. So my idea was wrong, I thought that in a certain way when I use the file descriptor instead of a raw socket the data was going in a different path. I thought that iptables could only see something if it was passing through the "network part" of the kernel. > > Depending on what is connected to the USB port, you can use ethernet over > USB (supported by Linux) and control all traffic to/from the tun interface > using the usual tools. That's a really cool idea, but actually we have to something in between, we can't simply pass from one to the other. But the main question is why this doesn't terminate?? --8<---------------cut here---------------start------------->8--- int main() { char name[IFNAMSIZ]; name[0] = 0; int fd = create_tun(name); int wrote = write_tun_write(fd); printf("wrote %d bytes on the tun device, now check iptables log\n", wrote); char buf[strlen(msg) + 1]; // read is blocking here read_from(fd, buf, strlen(msg)); printf("reading from the device string\n"); return 0; } --8<---------------cut here---------------end---------------> (complete code in previous post link) I write something on a device open in RDRW but I'm not able to read it. Maybe they must be two different protocols reading and writing on it? Thanks again
From: pk on 24 Jul 2010 12:01 On Sat, 24 Jul 2010 18:02:58 +0200 Andrea Crotti <andrea.crotti.0(a)gmail.com> wrote: > > You don't write on a tun device. What you do is write to the associated > > file descriptor (the one you get when the tun interface is opened). When > > you write something to that file descriptor, the kernel sees it as > > incoming "from the wire" to the tun interface, and will then apply the > > normal iptables rules (INPUT or FORWARD). > > Yes sure I meant writing on the file descriptor. > So my idea was wrong, I thought that in a certain way when I use the > file descriptor instead of a raw socket the data was going in a > different path. 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. > I thought that iptables could only see something if it was passing > through the "network part" of the kernel. > > > > Depending on what is connected to the USB port, you can use ethernet > > over USB (supported by Linux) and control all traffic to/from the tun > > interface using the usual tools. > > That's a really cool idea, but actually we have to something in between, > we can't simply pass from one to the other. > > But the main question is why this doesn't terminate?? > > --8<---------------cut here---------------start------------->8--- > > int main() { > char name[IFNAMSIZ]; > name[0] = 0; > int fd = create_tun(name); > > int wrote = write_tun_write(fd); > printf("wrote %d bytes on the tun device, now check iptables log\n", > wrote); > char buf[strlen(msg) + 1]; > // read is blocking here > read_from(fd, buf, strlen(msg)); > printf("reading from the device string\n"); > return 0; > } > --8<---------------cut here---------------end---------------> > (complete code in previous post link) > I write something on a device open in RDRW but I'm not able to read it. > Maybe they must be two different protocols reading and writing on it? 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.
From: Andrea Crotti on 24 Jul 2010 12:39 > 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? >> >> But the main question is why this doesn't terminate?? >> >> --8<---------------cut here---------------start------------->8--- >> >> int main() { >> char name[IFNAMSIZ]; >> name[0] = 0; >> int fd = create_tun(name); >> >> int wrote = write_tun_write(fd); >> printf("wrote %d bytes on the tun device, now check iptables log\n", >> wrote); >> char buf[strlen(msg) + 1]; >> // read is blocking here >> read_from(fd, buf, strlen(msg)); >> printf("reading from the device string\n"); >> return 0; >> } >> --8<---------------cut here---------------end---------------> >> (complete code in previous post link) >> I write something on a device open in RDRW but I'm not able to read it. >> Maybe they must be two different protocols reading and writing on it? > > 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? Only sending packets to the ip address associated with that device would work??
|
Next
|
Last
Pages: 1 2 3 Prev: Simple Hack To Get $2500 To Your PayPal Account. Next: Dropping root permissions |