Re: VKernel progress update - 10 Jan 2006

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:I think following patch does these:
:http://leaf.dragonflybsd.org/~sephe/vke_multi_syntax.diff
:
:NOTE:
:1) bridge will not be brought up automaticly
:2) non-existent bridge will not be created

    It looks pretty good.  I would put the TAP init code from
    platform/init.c into its own file, maybe platform/init_tap.c, because
    the code is getting fairly sophisticated.

:Except above syntax, I have extended it a little bit:
:-I tap0:x.x.x.x:y
:  will only set real kernel tap0's address and netmask

    The netmask should use a CIDR notation, that is a '/' instead of 
    a ':'.  e.g. tap0:10.0.0.1/24

:If you have assigned vkeX's address/netmask on vkernel command line,
:then in vkernel you only need 'ifconfig vkeX up', vkeX will have the
:address/netmask supplied on command line.
:
:Two sysctls are added for vkeX:
:hw.vkeX.intr_rate (rw), #intr/second, default is 20, valid range is [1, hz]
:hw.vkeX.tap_unit (ro), backend tap(4) interface unit in real kernel
:And now 'ifconfig vkeX' will print backend tap(4) interface in real kernel
:
:Make sure you have pulled in two tap(4) bug fixing in HAED, before
:trying this patch.
:
:Please test/review it.  Hope I can drive it into repo before 1.8 branching.
:
:Best Regards,
:sephe

    I tried '-I auto:bridge0' and specified DHCP in my rc.conf and it
    almost worked.  For some reason the bridge does not appear to be
    transmitting the DHCP response to the TAP interface.  Either that
    or it is but the tap interface is throwing the packet away before
    sending it to the vkernel.  After a bunch of messing around dhclient
    suddenly started working, but I don't know why.  I did have the bridge
    interface 'up' and it was associated with both tap0 and nfe0.

    Either way I don't think it is a bug in the vkernel code.  I think it
    is a bug in the bridge/tap link somewhere.

    Once you fix that CIDR block specification ( :  -> / ), just commit it.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>