From: Darryl Miles <lartc-list@the-morg.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] How to bypass the local routing table, to simulate a
Date: Fri, 12 Dec 2003 15:09:21 +0000 [thread overview]
Message-ID: <marc-lartc-107124187226740@msgid-missing> (raw)
In-Reply-To: <marc-lartc-107123232812967@msgid-missing>
Antony,
I have not completely read / understood your situation, so forgive me
for jumping in.
I don't know much about tap0 device so maybe you can eligthen me. But
from what I can see you can setup a NETWORK on a tapX interface and the
kernel will route all traffic to the interface as-if its a hardware
device, except its not, its a software device that passes packets
between userspace and the kernel interface through the use of a file
descriptor / socket, created by opening a device like file.
I use the word NETWORK since it behaves like a normal interface, that is
you give it an IP address that represents the kernels interface facing
the userspace software/virtual network. Therefore you should have setup
the interface with a netmask to allow other IPs to exist on that
network, it is those IPs that your application program should assume and
use.
To do this means the tap0 interface is configured along the lines of
192.168.1.8/30, using a netmask of 255.255.255.252, using 192.168.1.9 as
the kernel interface IP, 192.168.1.10 as your applications IP. Then
run your "ping -I tap0" again.
Now if on the other hand you are wanting to sniff all traffic to a
particular IP address from your ethernet segment, but not have the
kernel stack treat the packets as local, then down all the tapX
interfaces, then checkout AF_RAW, NETLINK, whatever the current scheme
is for injecting / sniffing packets and setup a proxy ARP addresses of
the IPs you want to assume on the LAN. However if the box this is all
hosted on has a lot of other traffic destined for the kernel stack you
will have to receive, filter, discard all those packets through into
userspace. Maybe socket filters can help in the kernel, but the point
is the tapX interfaces when used as a NETWORK would be a better solution.
Darryl
Antony Lesuisse wrote:
>Imagine, on a linux box, having 3 different network interfaces on the
>same switch. It is for simulating a network, using virtual tun/tap
>interface:
>
>
>----------------+-----+------------------------
>Hub simulator|Linux| Userspaces apps
> | |
> ?--|-----|--- tap0 192.168.1.1
> ? | |
>/dev/net/tun ?--|-----|--- tap1 192.168.1.2
> ? | |
> ?--|-----|--- tap2 192.168.1.3
> | |
>----------------+-----+-----------------------
>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
prev parent reply other threads:[~2003-12-12 15:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-12 2:15 [LARTC] How to bypass the local routing table, to simulate a hub Antony Lesuisse
2003-12-12 15:09 ` Darryl Miles [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-107124187226740@msgid-missing \
--to=lartc-list@the-morg.org \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.