[Wifidog] Looking at problems ahead
Tony Bussieres
tonyicemanz at yahoo.ca
Wed Apr 21 07:40:17 EDT 2004
Can't we use the inittab functionnality to take care of that?
if we start wifidog in /etc/inittab, it will start wifidog at the device
boot up. And it will respawn the process automatically if the process
dies.
What do you think about it?
Tony
Btw, congratulations guys! You did a lot of work during the last week,
it's very exciting to see the project move that fast!
On Tue, 2004-04-20 at 22:43, Philippe April wrote:
> Hi,
>
> While looking at the code and playing with WiFiDog on the WRT54G, I have
> found some issues I'd like to flag:
>
> 1. If WiFiDog segfaults, it will leave firewall rules behind (and of
> course, making the internet totally unaccessible).
>
> To fix that, we can have a process that monitors our process (I'm not a
> fan, but hey). I think that will be a definite requirement.
>
> Also, when we start WiFiDog, I'll need to write some iptables cleanup
> code to make sure there's no WiFiDog lying around.
>
> Right now, WiFiDog inserts itself at line 1 of some chains (mouhahah)
> to make sure its rules are called before any other DENY. I will have to
> check and remove any rule left there.
>
> So I need to make sure to clean any traces of WiFiDog, even if it's
> been started 60 times in a row and crashed all the times. I wish I
> could just scrap the firewall that's there, but I'd rather integrate.
>
> 2. The counters....
>
> It's not super clean nor clear.
>
> We call a shell script to get the counters. I found out the counters
> we're taking from the 'mangle' table is the upstream counter (which
> makes sense). To find out the "downstream", we'd have to insert a new
> chain in the FILTER table's chain FORWARD that gets called first and
> say "ACCEPT" to this destination IP.. And we all know we also want the
> downstream traffic.
>
> That way, we get what traffic was destined for that host and we can
> count it.
>
> Of course, to monitor all that, we could ask WiFiDog to call
> fw_counters and get the two counters for one particular IP address. If
> WiFiDog has to fork 20 times each time to get the values of the
> counters (iptables | grep | sed | awk, etc.... times 2), when we have
> 20 clients on a hotspot, the wrt54g won't keep up. Well, it probably
> will, but I'd rather make something more efficient than that.
>
> Right now for counters, we go through one table (mangle, or the table
> that tags traffic per MAC address if you prefer).
>
> We could just do as we do right now, but go through 2 places to find
> informations:
> 1. The mangle table - find which customers are still in the firewall,
> those not in that table definitely don't have access, so do a cleanup
> from linked list and other firewall tables.
> 2. The FORWARD chain - to get a nice table of the outgoing and incoming
> traffic for each individual.
>
> I suggest we update all clients in the linked list, THEN make a
> decision on what to do with each client by going through the linked
> list (kill connection based on inactivity, based on "not in the
> firewall anymore", etc.) I think this would be the most efficient way
> to keep things clean. That way we can go through the list and find out
> which clients are not in the firewall (ie. their counters values were
> not found in the last check).
>
> This is to make sure the linked list is in-sync with the firewall.
>
> Whee! Long email. Tell me what you think and if you have better ideas.
>
> Philippe
>
> _______________________________________________
> Wifidog mailing list
> Wifidog at isf.waglo.com
> http://isf.waglo.com/mailman/listinfo/wifidog_isf.waglo.com
--
May Linux be with you!
-------------- next part --------------
_______________________________________________
Wifidog mailing list
Wifidog at isf.waglo.com
http://isf.waglo.com/mailman/listinfo/wifidog_isf.waglo.com
More information about the Wifidog
mailing list