<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><BR class="khtml-block-placeholder"></DIV>Take a look at the ip_conntrack (IP connection tracker) subframework in Netfilter.  I have a hunch it may be the cause of the problem.<DIV><BR class="khtml-block-placeholder"></DIV><DIV>Most modern firewalls are "stateful", which means they keep track, in memory, of on-going IP conversations.  This is considered more advanced and more secure than simple stateless packet inspection.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>What I think you'll need to do is tell the connection tracker to "forget" ongoing conversations when a user is logged out.  I looked into this a long time ago when I was experimenting with captive DNS and found no easy way to do it.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>It would be also interesting to follow up on your suggestion of moving the firewall rule below (state inspector = check the connection memory) within one of WiFiDog's chains, but I feel that it's too intrusive and may break things, especially if within an existing firewall ruleset.</DIV><DIV><BR><DIV><DIV>On 26-Jul-06, at 4:03 PM, Tarken Winn wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite">Hi Chris,<BR> <BR> Thanks for the email. I am using cron for cleanup and it works fine. Timeout is set to 30 seconds (I think it was - default).<BR> <BR> However, I expect the problem I am experiencing is universal. For 'normal' use the system is working great in every respect. User is forced to login before they can access any web services and after logout is forced to login again for any NEW requests (opening another webpage, reloading etc). However, if while logged in a user has started a streaming service - such as <A href="http://www.pandora.com">www.pandora.com</A> (the specific example I was using when I discovered the bug) - the stream will continue AFTER they have successfully logged out. If you have a node accessible, have a go yourself. I am using a Linksys WRT54GL router, but expect it will happen on other routers also? <BR> <BR> Samuel pointed me to the line in the default /etc/init.d/S45firewall file that I mentioned and after some naive testing I am somewhat convinced that it is at least related. The firewall allows RELATED,ESTABLISHED packets through before ever hitting the wifidog gateway. At least that is my understanding of it. So a packet comes in from <A href="http://www.mystreamingbandwidthgobbler.com">www.mystreamingbandwidthgobbler.com</A> and is judged to be part of an already established connection and is therefore accepted by the firewall and forwarded to the user - whose wifidog status does not matter.<BR> <BR> I wonder whether we need to get rid of the line <BR> iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT<BR> from S45firewall and re-implement this in the wifidog iptables chains?<BR> <BR> I'd be interested to know whether you and others experience the same? Is it router specific (different firewall/iptables setups on different router types)?<BR> <BR> Thanks again,<BR> <BR> Tarken<BR><DIV><SPAN class="gmail_quote">On 7/26/06, <B class="gmail_sendername">Chris Rowson</B> &lt;<A href="mailto:christopherrowson@gmail.com">christopherrowson@gmail.com</A>&gt; wrote:</SPAN><BLOCKQUOTE class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi Tarken,<BR><BR>Am I right in thinking that your users are able to continue using the<BR>connection after they have logged out?<BR><BR>If so, have you changed CONF_USE_CRON_FOR_DB_CLEANUP to false in your<BR>config.php. That should clean up your database everytime a user query <BR>comes in (which solved a similar problem that I was having).<BR><BR>Also, have you checked the timeout variables in the wifidog<BR>configuration file itself?<BR><BR>Chris<BR><BR>On 26/07/06, Tarken Winn &lt;<A href="mailto:tarkenwinn@gmail.com"> tarkenwinn@gmail.com</A>&gt; wrote:<BR>&gt;<BR>&gt; Hello again everyone,<BR>&gt;<BR>&gt;  I have spent a fair amount of time investigating the issue I previously described, namely that when a user logs out any established streaming connections will continue as accepted, and have not found a solution.<BR>&gt;<BR>&gt;  It appears that /etc/init.d/S45firewall allows RELATED,ESTABLISHED packets to be forwarded at the line:<BR>&gt;<BR>&gt;  iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT <BR>&gt;<BR>&gt;  I tried commenting out this line in the hope that it would be covered by the rules in the WiFiDog_WIFI2Internet chain which is checked in the FORWARD chain, but to no avail.<BR>&gt;<BR>&gt;  I have tried allowing any packets with the auth server as source or destination to be forwarded, which allows a user to login (in the hope that subsequent packets will then be marked in the WiFiDog_WIFI2Internet chain and correctly forwarded) but then does not allow access to any websites other than the auth server even after successful login.<BR>&gt;<BR>&gt;  I now wonder whether the only way to solve this issue is to modify the wifidog gateway client code? I guess fw_iptables.c is where things would need to happen.<BR>&gt;<BR>&gt;  Has anyone come up with a solution for this issue? Does anyone knowledgeable on the internal workings of the gateway and its interactions with iptables have any suggestions?<BR>&gt;<BR>&gt;  Without resolving this issue, limiting and recording the amount of data a node/user can transfer per month seems a little futile. A user could (and no doubt will) just login, start a streaming video feed (or whatever), logout, then kick back and watch the show without being 'counted'.<BR>&gt;<BR>&gt;  Thanks,<BR>&gt;<BR>&gt;<BR>&gt;  Tarken<BR>&gt;<BR>&gt; _______________________________________________<BR>&gt; WiFiDog mailing list<BR>&gt; <A href="mailto:WiFiDog@listes.ilesansfil.org"> WiFiDog@listes.ilesansfil.org</A><BR>&gt; <A href="http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog">http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog</A><BR>&gt;<BR>&gt;<BR>_______________________________________________ <BR>WiFiDog mailing list<BR><A href="mailto:WiFiDog@listes.ilesansfil.org">WiFiDog@listes.ilesansfil.org</A><BR><A href="http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog">http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog </A><BR></BLOCKQUOTE></DIV><BR><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">_______________________________________________</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">WiFiDog mailing list</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A href="mailto:WiFiDog@listes.ilesansfil.org">WiFiDog@listes.ilesansfil.org</A></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A href="http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog">http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog</A></DIV> </BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>