[Click] Mac OS X assert failed when trying to use KernelTun

[Pekka Nikander]

I figured out a way to configure the device so that the user visible semantics are almost the same on OSX as on Linux:

On OSX, convert a "Linux" KernelTun(192.168.15.1/24) into a combination of
1. "KernelTun(192.168.15.1/24)" and
2. route add 192.168.15.0/24 192.168.15.1

That results in all packets to 192.168.15.0/24 to be sent over the tun to click (including 192.168.15.1).

Hence, if the code always used a /32 internally and used the given netmask for adding a net route, the semantics would almost match with the Linux one, with the exception that the host stack doesn't answer even to the local address.

I'm looking at the source code now to see if that can be reasonably implemented and documented.

--Pekka

On 2009-11 -26, at 20:36 , Eddie Kohler wrote:

> Thanks much for the patch!  I've checked it in.
> 
> Too bad about the high variability in tun semantics.  I'd love to accept a documentation patch :)
> 
> Eddie
> 
> 
> Pekka Nikander wrote:
>> Eddie,
>> Thanks, it works!  I needed to do two other small things to get it working:
>> 1. It didn't compile out of last night's git; the following patch made it to compile:
>> --- a/lib/timestamp.cc
>> +++ b/lib/timestamp.cc
>> @@ -67,7 +67,7 @@ Timestamp::warp(bool from_now)
>>     if (_warp_class == warp_simulation) {
>>        *this = _warp_flat_offset;
>>        if (from_now) {
>> -# if TIMESTAMP_MATH_FLAT64
>> +# if TIMESTAMP_REP_FLAT64 || TIMESTAMP_MATH_FLAT64
>>            ++_warp_flat_offset._t.x;
>> # else
>>            ++_warp_flat_offset._t.subsec;
>> I'm not sure if that is the right patch, though...
>> 2. Mac OS X tun devices are point-to-point links, requiring both a local and remote IP address.
>> Right now click configures only the local one, resulting in an interface like the following:
>> $ ifconfig tun0
>> tun0: flags=8951<UP,POINTOPOINT,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
>> 	inet 192.168.15.1 --> 0.0.0.0 netmask 0xffffff00 	open (pid 63049)
>> Once I added a remote address there with ifconfig, it started to work:
>> # ifconfig tun0 192.168.15.1 192.168.16.1
>> # click -e "tun :: KernelTun(192.168.15.1/24); tun -> IPPrint -> Discard" &
>> # ping 192.168.16.1 > /dev/null 2>&1
>> 1259231868.596160: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 0)
>> 1259231869.596198: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 256)
>> 1259231870.596240: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 512)
>> 1259231871.596328: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 768)
>> 1259231872.596394: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 1024)
>> 1259231873.596553: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 1280)
>> Alternatively, I was also able to do the same by manipulating the routing table:
>> # route add -net 192.168.16.0 192.168.15.1
>> However, pinging anything on the local subnet 192.168.15.0/24 doesn't go to the click process.
>> I guess the documentation should be updated...
>> Anyway, this should be enough slay some GMPLS Dragons locally on Mac OS X. :-)
>> --Pekka
>> On 2009-11 -25, at 12:21 , Eddie Kohler wrote:
>>> Pekka,
>>> 
>>> Thans very much for this note!  There was indeed a bug in the select handling -- we essentially assumed that every file descriptor was present in some array for both reading and writing.  This should be fixed now.  Let us know if you have any further issues.
>>> 
>>> Eddie
>>> 
>>> 
>>> Pekka Nikander wrote:
>>>> I'm a relative newbie to Click, and trying to use KernelTun on Mac OS X, with the latest GIT version.  Unfortunately it looks like that there is a bug, apparently related to the interactions between kevents and select/poll.  The OS X tun/tap devices don't currently support kevents, and therefore click tries to back off to use select/poll.  However, once it gets to the actual poll in master.cc, something has gone wrong and I get a an assertion failure on line 850 in master.cc:
>>>> 	Element *read_elt = (p->revents & ~POLLOUT ? _read_elements[fd] : 0);
>>>> This results in an assertion failure, with this trivial script:
>>>> click -e "KernelTun(192.168.15.1/24) -> Discard"
>>>> Assertion failed: (i>=0 && i<_n), function operator[], file ../include/click/vector.hh, line 184.
>>>> Abort trap
>>>> My gut feeling is that the bug may line somewhere in master.cc Master:add_select, in the code that tries to make sure that one can fall back to select/poll in the case of kqueue error.  But I may be wrong.
>>>> In any case, when tracing the execution in opening the tun/tap device, the kevent system call at line 602 of master.cc fails, causing the _kqueue socket to be closed and made unused.   However, much before that I can see with ifconfig that the tun/tap interface is indeed open and correctly ifconfig'ed.
>>>> Anyone an idea where to continue debugging?  Or would it be easier to add KEVENT support to the Mac tun/tap kexts?
>>>> --Pekka Nikander
>>>> _______________________________________________
>>>> click mailing list
>>>> click at amsterdam.lcs.mit.edu
>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click