netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: hadi@cyberus.ca
Cc: "'netdev@oss.sgi.com'" <netdev@oss.sgi.com>
Subject: Re: Interconnect virtual device?
Date: Mon, 28 Feb 2005 09:24:25 -0800	[thread overview]
Message-ID: <422353C9.6050001@candelatech.com> (raw)
In-Reply-To: <1109592365.2188.914.camel@jzny.localdomain>

jamal wrote:
> On Mon, 2005-02-28 at 00:15, Ben Greear wrote:
> 
>>Hello!
>>
>>I am considering writing a kernel module to provide a very
>>simple virtual interface.  This interface would be attached
>>to another interface, and would not be directly associated with
>>hardware.  It can have IP addresses & routing tables, and in
>>almost every way appear to be a regular ethernet interface.
>>
>>The idea is that when you tx on this virtual interface, it
>>will cause a packet to be received on another interface.  And,
>>when a packet is received on the interface, it will tx on the
>>other interface.
>>
> 
> 
> In other words, it redirects to another device - I take it based on some
> rules. Sounds to me like the mirred action already does this (and in
> addition can mirror).

Actually, I was thinking that either user-space or perhaps a kernel
module could use the standard methods of receiving all pkts in promisc
mode to do the bridging portion.  If I force the real ethernet
interface to have no IP address, and put it into promisc mode, then
I can effectively bridge in user-space.

When I re-insert the pkts into the stack by writing to the virtual
device, the (potentially modified) packet can be
routed and firewalled, etc just like a normal packet received from the
network.  I may need to have two virtual inter-connects, one w/out
an IP that does the bridging portion, and one with an IP that actually
communicates with the rest of the kernel.  In this case, the two virtuals
would be connected to each other.

I think this could provide a way to do very customized actions on
raw packets without having to hack the kernel on an ongoing basis.


Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

  reply	other threads:[~2005-02-28 17:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-28  5:15 Interconnect virtual device? Ben Greear
2005-02-28 12:06 ` jamal
2005-02-28 17:24   ` Ben Greear [this message]
2005-03-02 21:55     ` jamal
2005-03-02 22:34       ` Ben Greear
2005-03-03  0:27         ` jamal
2005-03-02 22:55       ` Thomas Graf
2005-03-03  0:35         ` jamal
2005-03-14 22:53           ` Max Krasnyansky

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=422353C9.6050001@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=hadi@cyberus.ca \
    --cc=netdev@oss.sgi.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).