[Click] minor bug report with NetBSD
Eddie Kohler
kohler at cs.ucla.edu
Thu Aug 24 12:19:18 EDT 2006
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)
>>
>>
>>
>
>
More information about the click
mailing list