[Wifidog] Version 1.0

[Philippe April]

Okay... I have a better idea of how it works now..

It's easy to create chains, but hard to add rules to them. The calls are
pretty complicated, and it feels like we'd be implementing everything
that's in iptables.c into WiFiDog, and it's pretty complex.

So I think we basically have two solutions if we want to do such a thing:

Sol 1: We take the relevant functions from iptables.c and put it in
WiFiDog (lotso code, we don't want to do this).

Sol 2: We include iptables into src_topdir/iptables/, link to libiptc.a
AND link with iptables.o to use all the code (we also have to include
-ldl) because iptables will load libraries dynamically for matches like
MAC (you know, the one we use? :P).

Then, we could make calls to functions in iptables.c that are a bit easier
to work with.

In fact, it'd be easier to use the function "do_command()" for pretty much
everything and pass it the arguments like we were doing it on the command
line.

That way, we wouldn't be forking all the time to run iptables commands.

ALSO, the good news is that we can use easi-er calls to libiptc to query
(querying is much easier) for the counters and all (that will help a lot).

Is this something we want to do?

What do you all think about linking that way to iptables.o to use
functions like "do_command()" (or other functions if they're easy enough
to work with)?

Philippe

> Well, I'll code a proof of concept for using libiptc calls directly
> instead of shell scripts...
>
> I have included iptables with wifidog (I don't know if this is something
> we want to do in the future, it'll just be for the proof of concept), and
> it incorporates easily with it.
>
> I'll let you know when I've done something useful, like Alex says we could
> have something like fwctl() to control the firewall.
>
> Philippe
>
>> I saw that howto, I thought it was very good and it would actually be
>> the
>> best to manage the firewall with kernel calls.
>>
>> However, I found it was pretty hard to integrate with WiFiDog because
>> one
>> would need libiptc as a pre-requisite to compile WiFiDog (and usually,
>> you
>> don't have those iptables sources with your OS).
>>
>> We discarded the idea a couple of weeks ago but maybe I'll look into it
>> again and see if there's something feasible with it (maybe we could
>> include the libiptc sources with WiFiDog! :) )
>>
>> I'll run some tests today and keep you posted.
>>
>> Maybe Alex can do the same with ipf, see if it's easy to control with C
>> calls directly.
>>
>> Philippe
>>
>>> Maybe we can use libiptc to control our firewall...
>>> check the howto here :
>>> http://www.opalsoft.net/qos/libiptc/qlibiptc.html
>>>
>>> there's an intresting example how to calculate bandwidth usage in C.
>>>
>>> That might worth a look
>>>
>>> Tony
>>>
>>>
>>> On Thu, 2004-04-22 at 22:54, Alexandre Carmel-Veilleux wrote:
>>>> On Thu, Apr 22, 2004 at 07:24:37PM -0400, Philippe April wrote:
>>>> >
>>>> > If you can afford to say "probably not", maybe you could look at how
>>>> it
>>>> > should get done and suggest :) Since you have exposure to ipf and
>>>> all
>>>> of
>>>> > those, maybe you can find a way that'll be easily portable.
>>>>
>>>> 	Heh ;-). I have a few ideas, including generating the firewall
>>>> scripts on the fly (or at start-up...) We could have a generation
>>>> module
>>>> per firewall type. Simpler then using APIs and more versatile on a
>>>> platform where we don't have an advanced scripting language available.
>>>>
>>>> 	The generators would be mostly fprintf's.
>>>>
>>>> 	Added to this, we shift as much work to the firewall script,
>>>> maybe even one script.
>>>>
>>>> 	API side I'm not sure. Maybe we should only have one funtion,
>>>> fw_ctl() whose first argument is a flag that says something like
>>>> "FW_CLEANUP", "FW_ADD", "FW_DELETE", "FW_STAT"... Kind of like
>>>> ioctl().
>>>>
>>>> 	This would work especially well with a single firewall script.
>>>>
>>>> > Ok let's focus on 1.0 with almost no custom stuff, then we'll debate
>>>> on
>>>> > this. I thought a mix would be good and I think we all agree about
>>>> this
>>>> > (local policies AND remote).
>>>>
>>>> 	That is something I can agree with. Let's get something into
>>>> early production.
>>>>
>>>> > Someone has to come up with a diagram explaining the classes, the
>>>> groups,
>>>> > etc.
>>>>
>>>> 	Definately. I'll try and see if I can squeeze it in.
>>>>
>>>> Alex
>>>>
>>>>
>>>> ______________________________________________________________________
>>>> _______________________________________________
>>>> Wifidog mailing list
>>>> Wifidog at isf.waglo.com
>>>> http://isf.waglo.com/mailman/listinfo/wifidog_isf.waglo.com
>>> --
>>> May Linux be with you!
>>>
>>>
>>> _______________________________________________
>>> Wifidog mailing list
>>> Wifidog at isf.waglo.com
>>> http://isf.waglo.com/mailman/listinfo/wifidog_isf.waglo.com
>>>
>>
>>
>> _______________________________________________
>> Wifidog mailing list
>> Wifidog at isf.waglo.com
>> http://isf.waglo.com/mailman/listinfo/wifidog_isf.waglo.com
>>
>>
>
>
> _______________________________________________
> Wifidog mailing list
> Wifidog at isf.waglo.com
> http://isf.waglo.com/mailman/listinfo/wifidog_isf.waglo.com
>
>


_______________________________________________
Wifidog mailing list
Wifidog at isf.waglo.com
http://isf.waglo.com/mailman/listinfo/wifidog_isf.waglo.com