[radvd-devel-l] radvd testing on tuntap

[Reuben Hawkins]

On Sun, Nov 17, 2013 at 5:43 PM, Steven Newbury <steve at snewbury.org.uk>wrote:

>  On Sun, 17 Nov 2013, 21:12:45 GMT, Reuben Hawkins <reubenhwk at gmail.com>
> wrote:
>
> > Does anybody know how to create a tun/tap interface on which RADVD can
> be
> > tested?
> >
> > I'd like to create some tests and I'm thinking that creating a virtual
> > network interface on which RADVD will advertise and listen would be the
> > best way to test, but I don't have any experience creating virtual
> > interfaces.  Any pointer to get me started would be very helpful.
> >
> > My setup will be as follows...
> >
> > 1) Create virtual interface(s)
> > 2) point RADVD to this interface(s) in radvd.conf
> > 3) write some tests to connect to the other end of the interface and
> send
> > solicitations to radvd to test out as many radvd configurations,
> features
> > and behaviors as possible.
> >
> Best bet would probably be to create a bridge interface, then run 1 or
> more VMs under QEMU with virtio/tap interfaces. That way everything is kept
> isolated on each side of the tap.
>
>  Running VM's is overkill.  I can't commit filesystems, etc to radvd for
testing.  I need something with which I can make simple tests.  I'm finding
this to be working so far...

ip link add $IFACE_NAME type dummy
ifconfig $IFACE_NAME up

I'd like to be able to do that in a c program.  When I do that on the
command line, I can run radvd on that interface in one terminal, and run
radvdump in another..and it seems to work.  I'd like to be able to create
the interface in a c program, then redirect stdout/stderr and fork an
instance of radvd and radvdump, then compare the outputs to make sure it's
all working.

I have a c program which creates tuntap interfaces (I found the code here
http://backreference.org/2010/03/26/tuntap-interface-tutorial/)

...so I guess what I need to do is expand on my tuntap.c to create an
interface of type "dummy".

As a side note, I found that RADVD is unable to get the MTU and the
hardware address from a dummy interface in one call to ioctl, but it can
get both if queried individually.  Seems like maybe a kernel bug...not sure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litech.org/pipermail/radvd-devel-l/attachments/20131119/d3e45696/attachment.html>