[Top] [All Lists]

Re: RFC: Redirect-Device

To: hadi@xxxxxxxxxx
Subject: Re: RFC: Redirect-Device
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Thu, 31 Mar 2005 14:22:11 -0800
Cc: "'netdev@xxxxxxxxxxx'" <netdev@xxxxxxxxxxx>
In-reply-to: <1112306031.1073.109.camel@xxxxxxxxxxxxxxxx>
Organization: Candela Technologies
References: <424C6089.1080507@xxxxxxxxxxxxxxx> <1112303627.1073.71.camel@xxxxxxxxxxxxxxxx> <424C6B10.6030200@xxxxxxxxxxxxxxx> <1112306031.1073.109.camel@xxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020
jamal wrote:
On Thu, 2005-03-31 at 16:26, Ben Greear wrote:

You can configure actions using sockets (netlink sockets).
Thats what tc does for example. As a matter of fact you already have a
"language" - its what tc is, sample BNF grammar of the language:

[root@jzny root]# tc
Usage: tc [ OPTIONS ] OBJECT { COMMAND | help }
where  OBJECT := { qdisc | class | filter }
       OPTIONS := { -s[tatistics] | -d[etails] | -r[aw] | -b[atch] file

My personal opinion is that netlink sockets are a pain in the ass to deal
with, and there is no way I want to try to programatically parse the tc
input or output.

And probably not so easy to manipulate from a kernel module.

And BNF cannot be more powerful than a c/c++ program with a byte-buffer
representing the entire ethernet frame.

I can also create a nice little set of virtual interfaces
and connections  rdd0 <-> rdd1  |bridge|  rdd2 <-> rdd3.  I can then send 
from rdd0 to rdd3 across the bridge, etc.  Now, this last bit is fairly
contrived, but it happens to help me with some testing on my laptop which
lacks a lot of external ethernet interfaces :)

So your goal is to define a path that the packet takes inside the kernel
across multiple devices? i.e some form of loose source routing?

Well, I have already hacked the kernel to allow sending traffic from eth0 to
eth3 across a loopback cable.  In my example above, you can think of
rdd0 - rdd3 as eth0 - eth3:  eth0 has an IP, connected to
eth1 with a loopback cable.  eth1 has NO ip and is bridged to eth2 in
software.  eth2 has NO ip and is connected via loopback cable to eth3.
eth3 has an IP  As far as the networking protocol stacks are
concerned, eth0 is connected via loopback cable to eth3.

My primary goal is to enable this bridge to not require so many physical
ethernet ports.  This 'bridge' is actually my network emulator that I sell
for a living, so if I can cram twice as much functionality into the same number 
physical interfaces, I stand to gain.  Since I remove the IP addresses from the 
bridged interfaces,
I can do the bridging without hacking another hook into the dev.c pkt receive
routines, and since my redirect devices are net_devices sending & receiving
ethernet packets, they just work with my existing code, ethereal, and every
other tool I've tried.  Heck, I could probably run 802.1Q VLANs across them
as well if I wanted :)

To be honest, I didn't dig into the actions.  It would be much harder for
me to manage things in that manner, whereas virtual interfaces just work
for me.

Understood - just not empathized ;->

Fair enough :)


Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc

<Prev in Thread] Current Thread [Next in Thread>