[Click] minor bug report with NetBSD

[Eddie Kohler]

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)
>> >>
>> >
>> >
>>
> 
>