[Click] minor bug report with NetBSD

[Vivek raghunathan]

Eddie,

KernelTap works on NetBSD with the following patch to your code ...

Vivek



On 8/24/06, Eddie Kohler <kohler at cs.ucla.edu> wrote:
> Hi Vivek!
>
> Thanks very much for these patches.  I've applied versions of them, plus your
> todevice patch, to the source.  I'd appreciate it if you tried out KernelTap
> on NetBSD, including MAC address setting, as I changed your patch somewhat --
> just to rearrange the logic and in one point to call sysctl() directly, rather
> than fork off an /sbin/sysctl.
>
> Eddie
>
>
> Vivek raghunathan wrote:
> > Eddie,
> >
> > I had sent you an earlier patch for NetBSD for the KernelTun and
> > KernelTap against the 1.5 release. It seems like you have now
> > integrated both of those elements into the KernelTun. I just merged
> > the NetBSD changes with your new code, and am attaching patches
> > against your KernelTun code.
> >
> > Vivek
> >
> >
> >
> > On 6/30/06, Vivek raghunathan <vivek.raghunathan at gmail.com> wrote:
> >> Eddie,
> >>
> >> My apologies - I have been kind of distracted the last week or so and
> >> had not been checking the Click mailing list regularly. Did so today,
> >> and saw your post. I am attaching patches against the 1.5.0 release,
> >> which (at BBN where I am interning) we are using as a vendor branch.
> >> In a lot of places, it's just a matter of adding a
> >> defined(__NetBSD__) to the Linux or FreeBSD or OSX or OpenBSD case.
> >>
> >> Vivek
> >>
> >> ps. If you want, I can reimport against your -current and do a merge.
> >>
> >> pps. I am going to be w/o email in the Colorado Rockies for the next 4
> >> dayy, so hopefully things will compile and run fine :).
> >>
> >>
> >>
> >> On 6/21/06, Eddie Kohler <kohler at cs.ucla.edu> wrote:
> >> > Hi Vivek,
> >> >
> >> > I never got a patch from you for NetBSD KernelTun.  Any news?
> >> >
> >> > Eddie
> >> >
> >> >
> >> > Vivek raghunathan wrote:
> >> > > Eddie,
> >> > >
> >> > > Thanks for the help with the kerneltun/tap code. Your re-write will
> >> > > probably fix the ARP issues with the kerneltap driver in the Linux
> >> > > code.
> >> > >
> >> > > I'll take care of the NetBSD porting and send in a patch by tomorrow:
> >> > >
> >> > > 1. I had already patched the kerneltap.cc code to accept all kinds of
> >> > > Ethernet packets (instead of just IP) by re-writing KernelTap::push()
> >> > > to use ethertype = ((const click_ether *) p->data())->ether_type.
> >> > > Those are similar to your changes to kerneltun.cc, and work in NetBSD
> >> > > just fine.
> >> > >
> >> > > 2. The NetBSD tap driver is different from the NetBSD tun driver in
> >> > > subtle ways: (From the man page) an open() call on /dev/tunN, will
> >> > > also create a network interface with the same unit number of that
> >> > > device if it doesn't exists yet. On the other hand, with the NetBSD
> >> > > tap, you need to use the cloning device /dev/tap to create an
> >> > > interface, and then use the TAPGIFNAME ioctl to fetch the name of the
> >> > > device that's been created. Thus, the code in KernelTap::alloc_tun()
> >> > > needs to be hacked a bit.
> >> > >
> >> > > 3. Also, AFAIK, the ifconfig/ioctl interface in NetBSD doesn't
> >> > > (always) allow Ethernet addresses to be set. Fortunately, the tap
> >> > > device has a sysctl interface to set the hardware address.
> >> > >
> >> > > 4. Finally, as we discussed earlier, the Ethernet frames spit out by
> >> > > the NetBSD tap driver don't have a 4 byte af_family field.
> >> > >
> >> > > I've patched the kerneltap.cc code to handle all these cases. It
> >> works
> >> > > on my NetBSD setup -  let me do a little more testing before I
> >> send in
> >> > > the patch.
> >> > >
> >> > > Vivek
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > Vivek
> >> > >
> >> > >
> >> > >
> >> > > On 5/24/06, Eddie Kohler <kohler at cs.ucla.edu> wrote:
> >> > >> Hi Vivek,
> >> > >>
> >> > >> I've updated the KernelTap and KernelTun code to actually work
> >> > >> (verified on
> >> > >> Linux and FreeBSD), and unified the KernelTap and KernelTun code
> >> > >> paths.  Have
> >> > >> a look at elements/userlevel/kerneltun.cc.  Hopefully it will be
> >> > >> easier to
> >> > >> make this work on NetBSD.  (Or maybe, gosh, it'll work out of the
> >> box.)
> >> > >>
> >> > >> Eddie
> >> > >>
> >> > >>
> >> > >> Vivek raghunathan wrote:
> >> > >> > Eddie and all,
> >> > >> >
> >> > >> > Another question regarding the KernelTap. It seems like you cannot
> >> > >> > push ARP packets to it, because the code in push(int, Packet *)
> >> infers
> >> > >> > the Ethernet protocol field from the version information in the IP
> >> > >> > header of the packet (IPv4/IPv6) and prepends it to the packet
> >> before
> >> > >> > writing it to the tap device. It seems like the reason you do
> >> this is
> >> > >> > that the universal tun/tap driver in Linux expects this field
> >> > >> > prepended to the Ethernet frames written from userspace.
> >> > >> >
> >> > >> > Since this information is also in the Ethernet header, why
> >> can't we
> >> > >> > extract it from there? That would make the tap virtual Ethernet
> >> device
> >> > >> > agnostic to which higher layer protocol it is transporting. Or
> >> am I
> >> > >> > missing something fundamental here?
> >> > >> >
> >> > >> > Vivek
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> > On 5/20/06, Vivek raghunathan <vivek.raghunathan at gmail.com> wrote:
> >> > >> >> Eddie,
> >> > >> >>
> >> > >> >> I am currently interning at BBN with the Internetworking Research
> >> > >> >> group there. It seems like the KernelTap and KernelTun devices
> >> need to
> >> > >> >> be patched for NetBSD support ... I'll send you the patch as
> >> soon as
> >> > >> >> we are done.
> >> > >> >>
> >> > >> >> Vivek
> >> > >> >>
> >> > >> >>
> >> > >> >> On 5/19/06, Eddie Kohler <kohler at cs.ucla.edu> wrote:
> >> > >> >> > Hi Vivek,
> >> > >> >> >
> >> > >> >> > It looks like KernelTun needs to be altered to work on
> >> NetBSD.  If
> >> > >> >> you look at
> >> > >> >> > the source, in elements/userlevel/kerneltun.{cc,hh}, you'll
> >> see that
> >> > >> >> there are
> >> > >> >> > several cases built in to the code, for Apple, FreeBSD, Linux
> >> > >> >> (ethertap and
> >> > >> >> > universal tun), OpenBSD.  Would you like to provide us with
> >> a patch
> >> > >> >> for NetBSD
> >> > >> >> > support??  We'd love it...
> >> > >> >> >
> >> > >> >> > E
> >> > >> >> >
> >> > >> >> >
> >> > >> >> > Vivek raghunathan wrote:
> >> > >> >> > > Eddie,
> >> > >> >> > >
> >> > >> >> > > SIOCSIFMTU is supported. NetBSD's tun device has a max mtu of
> >> > >> >> TUNMTU =
> >> > >> >> > > 1500.
> >> > >> >> > >
> >> > >> >> > > Another minor bug in the userlevel/kerneltun.cc file: it
> >> seems
> >> > >> like
> >> > >> >> > > NetBSD does not preprend a 4 byte address family field in
> >> front of
> >> > >> >> the
> >> > >> >> > > IP header. Thus, in elements/kerneltun.cc:348 or so, the af
> >> > >> field is
> >> > >> >> > > in fact the first 4 bytes of the IP header, resulting in
> >> (af !=
> >> > >> >> > > AF_INET && af != AF_INET6) codepath being entered and
> >> userspace
> >> > >> does
> >> > >> >> > > not receive the packets.
> >> > >> >> > >
> >> > >> >> > > Vivek
> >> > >> >> > >
> >> > >> >> > >
> >> > >> >> > > On 5/17/06, Eddie Kohler <kohler at cs.ucla.edu> wrote:
> >> > >> >> > >> Hi Vivek,
> >> > >> >> > >>
> >> > >> >> > >> So the point of SIOCSIFMTU is to set the MTU.  Are you
> >> saying the
> >> > >> >> > >> NetBSD's tun
> >> > >> >> > >> device CANNOT have an MTU larger than 1500?  Or that the
> >> > >> SIOCSIFMTU
> >> > >> >> > >> ioctl is
> >> > >> >> > >> not supported?
> >> > >> >> > >>
> >> > >> >> > >> Eddie
> >> > >> >> > >>
> >> > >> >> > >>
> >> > >> >> > >> Vivek raghunathan wrote:
> >> > >> >> > >> > The mail was partially sent.
> >> > >> >> > >> >
> >> > >> >> > >> > With NetBSD, the conf/test-tun.click script doesn't work.
> >> > >> >> > >> >
> >> > >> >> > >> > bash-3.1$ sudo userlevel/click conf/test-tun.click
> >> > >> >> > >> > conf/test-tun.click:19: While initializing 'tun ::
> >> KernelTun':
> >> > >> >> > >> >   SIOCSIFMTU failed: Invalid argument
> >> > >> >> > >> > Router could not be initialized!
> >> > >> >> > >> >
> >> > >> >> > >> > Reason:
> >> > >> >> > >> > minor bug in userlevel/kerneltun.cc:
> >> > >> >> > >> >>     268 ifr.ifr_mtu = _mtu_out;
> >> > >> >> > >> >>     269     if (ioctl(s, SIOCSIFMTU, &ifr) != 0)
> >> > >> >> > >> >>     270         return errh->error("SIOCSIFMTU failed:
> >> %s",
> >> > >> >> > >> strerror(errno));
> >> > >> >> > >> >
> >> > >> >> > >> > NetBSD's tun device has a default MTU of 1500. _mtu_out
> >> is set
> >> > >> >> to 2048
> >> > >> >> > >> > by default, and NetBSD returns EINVAL on the ioctl.
> >> > >> >> > >> >
> >> > >> >> > >> > Fix:
> >> > >> >> > >> > set DEFAULT_MTU to <= 1500
> >> > >> >> > >> >
> >> > >> >> > >> > -Vivek
> >> > >> >> > >> >
> >> > >> >> > >> >
> >> > >> >> > >> > On 5/17/06, Vivek raghunathan
> >> <vivek.raghunathan at gmail.com>
> >> > >> wrote:
> >> > >> >> > >> >> bug in userlevel/kerneltun.cc:
> >> > >> >> > >> >> 268 ifr.ifr_mtu = _mtu_out;
> >> > >> >> > >> >>     269     if (ioctl(s, SIOCSIFMTU, &ifr) != 0)
> >> > >> >> > >> >>     270         return errh->error("SIOCSIFMTU failed:
> >> %s",
> >> > >> >> > >> strerror(errno));
> >> > >> >> > >> >>
> >> > >> >> > >> >>
> >> > >> >> > >> >>
> >> > >> >> > >> >>
> >> > >> >> > >> >> --
> >> > >> >> > >> >>
> >> > >> >> > >> >> *************************************
> >> > >> >> > >> >> Vivek Raghunathan,
> >> > >> >> > >> >> PhD student,
> >> > >> >> > >> >> University of Illinois, Urbana-Champaign
> >> > >> >> > >> >>
> >> > >> >> > >> >> Contact Details:
> >> > >> >> > >> >> 1012 W. Clark St #31,
> >> > >> >> > >> >> Urbana IL 61801
> >> > >> >> > >> >>
> >> > >> >> > >> >> ph: 217-766-1868 (cell)
> >> > >> >> > >> >>     217-333-7541 (off)
> >> > >> >> > >> >>
> >> > >> >> > >> >
> >> > >> >> > >> >
> >> > >> >> > >>
> >> > >> >> > >
> >> > >> >> > >
> >> > >> >> >
> >> > >> >>
> >> > >> >>
> >> > >> >> --
> >> > >> >>
> >> > >> >> *************************************
> >> > >> >> Vivek Raghunathan,
> >> > >> >> PhD student,
> >> > >> >> University of Illinois, Urbana-Champaign
> >> > >> >>
> >> > >> >> Contact Details:
> >> > >> >> 1012 W. Clark St #31,
> >> > >> >> Urbana IL 61801
> >> > >> >>
> >> > >> >> ph: 217-766-1868 (cell)
> >> > >> >>     217-333-7541 (off)
> >> > >> >>
> >> > >> >
> >> > >> >
> >> > >>
> >> > >
> >> > >
> >> >
> >>
> >>
> >> --
> >>
> >> ---
> >>
> >> *************************************
> >> Vivek Raghunathan,
> >> PhD student,
> >> University of Illinois, Urbana-Champaign
> >>
> >> Contact Details:
> >> 1012 W. Clark St #31,
> >> Urbana IL 61801
> >>
> >> ph: 217-766-1868 (cell)
> >>     217-333-7541 (off)
> >>
> >>
> >>
> >
> >
>


-- 

---

*************************************
Vivek Raghunathan,
PhD student,
University of Illinois, Urbana-Champaign

Contact Details:
1012 W. Clark St #31,
Urbana IL 61801

ph: 217-766-1868 (cell)
    217-333-7541 (off)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kerneltun_cc_patch
Type: application/octet-stream
Size: 640 bytes
Desc: not available
Url : https://amsterdam.lcs.mit.edu/pipermail/click/attachments/20060826/97a3300c/kerneltun_cc_patch.obj