david at coova.com
Fri Nov 13 11:19:17 UTC 2009
>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
- Went (back) to a globally static _options struct to get rid of many
- A helper server called 'chilli_proxy' (already in svn; compile with
--enable-chilliproxy) that does a RADIUS<->HTTP conversion
- 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
- 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!
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 ;-)
More information about the Chilli