[Wifidog] Looking at problems ahead

[Philippe April]

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