On Thu, 21 Mar 2002, Jeff Dike wrote:
> havanna_moon@... said:
> > Just remove the "#define TUNTAP" around line 20, this way you lose
> > tuntap and monitor functionality and can test the learning bridge
> > part.
> That doesn't help.
> I want the patch you sent to be send again in smaller, functionally separate
Hmm? Your cpp is at the mechanic? ;-) (yeah, yeah, I should have thought
of that, it makes your life easier (or less overloaded at least))
Ok, tuntap functionality depends on the learning bridge changes. So I
attach 2 patches. The first one will just add the learning bridge
functionality. This means:
* Hash table with MAC -> Port mappings (port can be a unix socket or later
a tun fd), Ports are identified by a MAC Adress, atm. Send USR1 to print
this table. Some helper functions are defined for the management of this
hash table. The hashing function is not based on any theory, anyone with
a little more clues should check HASH_SIZE (128 entries) and HASH_MOD
(11, some random prime).
* Function update_src() to update the Hash Table depending on received MAC
*Source* address. Avoids overwriting static mac address (the addresses
of the interfaces in the guests and later the tun mac address) entries.
* Function send_dst() to send the incoming packet to the corresponding
port(s) and if needed to the monitor port/connection (which is always
NULL in this first patch, so just ignore that 2 lines at the end for
* Garbage collection on the hash table every GC_INTERVAL (2) seconds.
Entries older than GC_EXPIRE (100) seconds are removed. Uses SIGALRM.
* Extension of struct connection (should be named struct switch_port) with
a function pointer to a send function. This is really only needed for
the tun function, but it makes the code cleaner and I saw no point in
removing it only for the interim patch.
The second patch adds a tuntap port to the switch. This adds:
* Some random functions for setting up the tun interface (module loading,
nod making, etc) Most functions are just stolen from some (older)
version of uml_net (iirc).
* function handle_tap() to handle input on the tuntap fd.
* changes to main() to:
1) init the tuntap 'connection' and set it up as the monitor
'connection' if we are not running as a hub.
2) Register (add_fd) this tuntap channel and handling of it in the poll
You'll need the first patch to apply the second one. It should be easy to
add cli switches to enable/disable tun and monitor functionality.
I think it could be possible to add a function pointer to struct
connection to a handle_input(), this would generalize the code and make it
more readable and extensible, and would support more than one tun port
(which i think makes sense when you only want to monitor now and then and
dont want add another context switch for packets you are not really
interested atm. so it could be possible to add a uml_switch_control
program that dynamically loads and unloads tun/monitor ports, but I'm not
going to write it (atm) so I doubt anyone cares about this ;-)
The patches are not functionally separate, as you asked. Sorry, but I
dont think it makes sense to make just an interim tuntap-only patch when
the code to support tuntap is already there.
As I said before, I think hogwash + learning bridge is a nice way to put
your UMLs online without firewalling on the host, in fact, you could run
the an ipv4-less host (as suggested in the hogwash docu, iirc).