[isf-wifidog] Still trying to hunt down greg's problem and #269

[listserv.traffic at sloop.net]

Benoit:
I'd be glad to assist in the AM, when you're around. I'll be on IRC -
just ping or email me.

I'm curious though.
The date and time ARE correct and the correct TZ on the Auth server.
However, the TZ was NOT the same on the GW.

I'm assuming that the GW is using a combination of local (to the GW)
time and the time given from the Auth server in the calculations.

I'd assume this means that the times then must be synced between the
GW and the Auth Server.

Provided the above is true, wouldn't it remove a lot of problems to
simply ignore time from an "unreliable" device (the GW) and pass the
time TO the GW from the Auth server.

This would negate any problems from non-synced clocks. In short, it
seems unwise to "trust" the time from the GW.

(The only caveat I can think of is: perhaps one would want to limit
the times the GW is available, and want to use "local"
(geographically) time for the set hours, rather than calculating
offset from the Auth server and putting in the allowed times using the
TZ of the auth server. (This assumes that one might have the auth
server in a different time zone - and probably that the difference
would be great enough to cause confusion. While this could happen, it
doesn't seem likely.)

Anyway, perhaps this epistle is misplaced and I don't understand
anything! :)

Now I have to put the Auth server back together since I tore
everything up trying to go to and old version of Postgresql.

If I get there first, I'll let you know what I find.

-Greg

> I've been trying unsuccessfully to hunt a bug down on IRC with greg, and it's
> very likely that the cause is the same as
> http://dev.wifidog.org/ticket/269.  

> The date comparison calculations for tokens appear to be failing.  In this
> case, the offset makes wifidog to think that the token is still valid before
> it expired, and manifests as users not logging off automatically after a
> gateway crash or session expiration.  In greg's case (offset probably the
> other way around), it manifests as users successfully logging in during
> initial auth (as shown by the gateway debug output) but getting logged off
> during the next counter update.  I checked that the calculation hasn't been
> broken in recent postgres, and that we are using the proper datatype.  So
> most likely, in both cases, you have an improperly set timezone in either PHP
> or Postgres.  

> It should be possible to fix this easily in the wifidog code now that we no
> longer intend to support MySql, but I need to first confirm that a timezone
> mismatch between PHP and Postgres is indeed the cause.

> So anyone who encounteres/encountered this bug, please check this and report
> your results.