[isf-wifidog] token that wasn't TOKEN_UNUSED

[Genevieve Bastien]

Hi Steven,

What are exactly the steps to reproduce this bug?  We used to have
something similar when a user clicked twice on the login button, and
corrected it with the check around line 105 (although you're right it
does seem like gw_id is not in the $info array, I wonder why I missed
this...)

-- 
Geneviève Bastien


Steven Kurylo wrote:
> Steven Kurylo wrote, On 4/23/10 11:52 AM:
>> Steven Kurylo wrote, On 4/22/10 4:21 PM:
>>> I've just upgraded to the lastest SVN and I can reproduce 100%
>>> "Tried to
>>> login with a token that wasn't TOKEN_UNUSED" when a user logs in, which
>>> then sends them to the denied message:
>>> http://192.168.0.1:80/wifidog/gw_message.php?message=denied
>>
>> Ok, after further debuging, I see its wifidog/auth/index.php line 105
>> where the check is happening.
>>
>> Its checking gw_id, user_mac, user_ip.  However my $info array
>> doesn't have gw_id set, which explains Undefined index:  gw_id in
>> /var/www/wifidog/auth/index.php on line 106
>>
>> I've included my $info below.  Any ideas?  For now I'm going to
>> remove the gw_id check.
>
> I've removed the gw_id check around line 105, so my clients are no
> longer denied:
> http://dev.wifidog.org/browser/trunk/wifidog-auth/wifidog/auth/index.php#L105
>
>
> The auth server returns ACCOUNT_STATUS_ALLOWED.  This is causing the
> gateway to update the iptable rules a second time, which then looks
> similar to this bug:
> https://www.ilesansfil.org/ticket/501
>
> I'm not sure why firewall.c is entering the rules a second time
> (FW_MARK_KNOWN isn't set the second time through I assume...), but
> when the client times out I see "Preventively deleting firewall rules
> for...".
>
> So its not perfect, but its working well enough for me for now.
> _______________________________________________
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog