[Click] minor bug report with NetBSD

[Eddie Kohler]

Thanks, applied!
E


Vivek raghunathan wrote:
> 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)
>> >>
>> >>
>> >>
>> >
>> >
>>
> 
>