[Click] minor bug report with NetBSD
Vivek raghunathan
vivek.raghunathan at gmail.com
Fri Aug 4 17:55:04 EDT 2006
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_hh_patch
Type: application/octet-stream
Size: 404 bytes
Desc: not available
Url : https://amsterdam.lcs.mit.edu/pipermail/click/attachments/20060804/16c4e733/kerneltun_hh_patch.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kerneltun_cc_patch
Type: application/octet-stream
Size: 4917 bytes
Desc: not available
Url : https://amsterdam.lcs.mit.edu/pipermail/click/attachments/20060804/16c4e733/kerneltun_cc_patch.obj
More information about the click
mailing list