[Chilli] Development

[David Bird]

>From the sounds of it, I need to take full credit; for the bug! :) 

I have no issue giving you write access, though I already made the
change to my copy. I actually have some major changes to commit in my
working copy... Send me a htpasswd entry for yourself (privately) and
I'll configure you in subversion. 

Some highlights of things in development (or at least areas of
research);

- Went (back) to a globally static _options struct to get rid of many
functions calls

- A helper server called 'chilli_proxy' (already in svn; compile with
--enable-chilliproxy) that does a RADIUS<->HTTP conversion
(http://www.coova.org/CoovaChilli/Proxy)

- Breaking out a server called 'chilli_redir' (enabled with configure
--enable-chilliredir) that will do the UAM server functions broken out
from the main chilli program. This opens the door for additional
processing of the hijacked URL - like for doing a URL based walled
garden (to allow www.google.com, but not www.google.com/mail for
instance). 

- Reworked the chilli_main() heavily making it like a "plug-in" style
registration of listeners/handlers.

- Adding support for poll() and epoll() as alternatives to select()

- Testing the "packet mmap" features of Linux 2.6.31 (mmap "ring"
buffers for both RX and TX for "zero-copy" in/out to/from kernel/user
space; though still the issue/bottleneck of the tun/tap)

- A haserl "miniportal" taken from CoovaAP now part of coova-chilli
standard distro (build with --enable-miniportal)

- Some fixups in the "routeidx/routeif" features of chilli whereby
chilli can directly (through a raw socket) tap into multiple WAN
interfaces and can route user session data between them. Used with RX/TX
rings, this can be used to bypass the tun/tap completely for
authenticated traffic and doubles the throughput on my fonera ;)

- Experimenting on a Linux kernel module that can do the above
(bypassing chilli for authenticated traffic) directly in the kernel
instead of user space. 

Lots to come... ;) Developers and testers wanted! 

David



On Fri, 2009-11-13 at 12:40 +0200, Gunther Mayer wrote:
> David Bird wrote:
> > Hmm.. 
> >
> > I think I see how this can happen. I likely added that ability to
> > allocate a static IP out of tun_ind() so that truly static IPs would
> > work (though, looking at it now, I don't think the code helps that
> > situation since as you noted, it's not a fully configured dhcp lease at
> > that point, just an entry in the ippool). I'm thinking it'll be wise to
> > remove the call to ippool_newip() at this point in the code. Instead,
> > perhaps it just goes ahead and accepts the packet if within the statip
> > range -- then, presumably, the computer with the statip will reply to
> > the packets, which will create the dhcpconn/appconn/etc properly (from
> > the packet originating from the dhcpif).
> >   
> 
> I concur, it should be removed. I tested my patched code with "truly 
> static IP's" and it still works fine without it (full connection 
> allocated, times out after default 600 seconds "lease" time etc.). I've 
> done hundreds of static IP mixed with dynamic IP setups in the past with 
> 1.0.11 (where that code wasn't in) and never had an issue. That piece of 
> code is not required and it looks as though it never was (I thought you 
> introduced it in a later version to make a particular new feature work).
> 
> Not sure if I still have commit access but I'm happy to commit this 
> change and take credit ;-)
> 
> Gunther