[Wifidog] Version 1.0

Sun Apr 25 12:45:33 EDT 2004

BTW the cleanup_POST version is still running on my WRT54G.

More updates (Benoit I'll need your advice).

If we try to add rules to the firewall, we'll need to do a bunch of things
for every match and target, like loading the dynamic modules by ourselves,
etc. Basically, we'd be recoding iptables into wifidog, unless we want to
do that, well... here are the other results:

Results:

  1. we can use the do_command() function from iptables.c
  Pros: we don't fork
  Cons: we need to link with libdl.so
        when we compile iptables.c, we need to specify where the dynamic
        iptables libraries (matches and targets) are (ugly).

  2. we can fork() and call the iptables binary directly
  Pros: good flexibility
  Cons: fork()

  3. use shell scripts
  Pros: probably the most compatible
  Cons: fork() fork() fork() fork()
        hard to package

I think we should go for #2. By doing so, there's no shell scripts, and
we're still pretty efficient.

I'd like Benoit's advice on this:

I replaced the way we look at counters by direct calls to libiptc, which
is much more efficient. Now, if we go with calls to iptables binary,
should we do everything that way (ie. redo the counters function to call
iptables to get the counters, but parse the results in C?) or should we
still link to (and depend on) libiptc?

If we want to link to libiptc, I suggest we change WiFiDog's autoconf to
ask "where is your static libiptc.a and headers" and link with it. It'll
be possible on the WRT54G, and pretty much anywhere as long as you
installed the iptables-dev package or similar. Now, is that doable? That
way we wouldn't have to include iptables sources (ugly).

For the fw_destroy functions, we could still use libiptc calls if we
decide to keep that dependency. I just loop through everything, remove all
rules relevant to us, then re-loop, flush all chains relevant, then
re-loop and delete all chains leftover from us.

Whew! I worked a lot on this these past few days, I could not find a
perfect solution but at least our options are much clearer.

And it's not because we're too dumb to manipulate the chains by ourselves
and add things to them, everybody on the net (I did quite extensive
researches) do calls to iptables directly. The only thing I found that
does calls directly to add rules, is the perl wrapper for iptables (they
basically rewrote the iptables functions and integrated them into perl).

Philippe

> Just to send an update on the progress..
>
> WiFiDog version cleanup_post has been running for two days on my router
> succesfully, and myself and my significant other are using it, it works
> great, didn't crash once yet.
>
> For the firewalls:
>
> I have rewrote some firewall functions, I will need some advice on how to
> architect that properly so we can be as modular as possible.
>
> None of my progress is in CVS yet.
>
> I have added an iptables.c, and have redone the fw_destroy function with a
> lot of helpers. I basically loop into the tables and check for my rules
> that have wifidog* as targets, then loop into the chains and do the same
> (check for chains that start with wifidog*) flush them then delete them.
>
> It works pretty well, and it's fast!
>
> I've also redone the fw_counter functions, it works very well too.
>
> Btw, I have used a lot of help from the Perl IPTables wrapper, they do
> pretty much everything we want to do.
>
> The tricky part is regarding ADDING data. So I'll spend some time
> converting the fw_allow and fw_deny scripts, + the fw_init.
>
> I'll keep you posted, as always.
>
> Philippe
>
>> :)
>>
>> I'll definitely change the procedure that checks the counters first
>> because it's the easiest (I believe) to change, then I'll see what we
>> can
>> do for the rest...
>>
>> Philippe
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>> 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).
>>>
>>> Ok, sounds easy enough to do.
>>>
>>>> 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)?
>>>
>>> I certainly like it better than calling shell scripts.
>>>
>>> - --
>>> Benoit Grégoire, http://step.polymtl.ca/~bock/
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.2.4 (GNU/Linux)
>>>
>>> iD8DBQFAiZmumZ6zzPlLuwMRAvAMAJsEXOBQ3Q3P0WuqKa5EYk7wAJjOOACfSn3U
>>> CGtm7nStpr/81i+ximWIdsA=
>>> =XKnl
>>> -----END PGP SIGNATURE-----
>>>
>>> _______________________________________________
>>> 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