<div dir="ltr">Hi Heikki,<div><br></div><div>Thank you for your suggestion. A PostAuth Hook sounds like a good solution, and also an opportunity to clear to reject users with just a few seconds left.</div><div><br></div><div>
It happens as you describe, the Max-Daily-Session is not strictly exceeded, it's just exactly reached.</div><div><br></div><div>
                
        
        
                <div class="" title="Page 358">
                        <div class="">
                                <div class="">
                                        <div class="">
                                                <ol start="0" style="list-style-type:none">
                                                        <li>
                                                                <pre><span style="font-size:9pt;font-family:Courier">if( ${$_[0]}->get_attr(‘Session-Time’) < 120) {
</span></pre><pre><span style="font-size:9pt;font-family:Courier"> ${$_[0]}->set_attr(‘Session-Time’, -1)</span></pre><pre><span style="font-size:9pt;font-family:Courier">}</span></pre>
                                                        </li>
                                                
                                        </ol></div>
                                </div>
                        </div>
                </div></div><div><br></div><div>Is the syntax for a setter set_attr() ? or is it add_attr() ? I haven't found any example of the former in the manual</div><div><br></div><div>Thanks</div></div><div class="gmail_extra">
<br clear="all"><div><div dir="ltr"><div dir="ltr"><table style="border:none;border-collapse:collapse"><tbody><tr style="height:0px"><td style="border:1px solid #ffffff;vertical-align:top;padding:7px 7px 7px 7px"><img src="https://lh6.googleusercontent.com/HIk9JhUeCf0E7ZDzVYyhPJeOPQBYKlQobRgGYn979Xdwt7QgHTev5X4ZEmuwi3KKSGSvM2giiOQ0LXmIw04jWTGXNYoHOX58zIluYdtwxdCxIIbzqu7oXf88ZA" height="80px;" width="156px;"><span style="font-size:15px;font-family:Arial;color:#000000;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span></td>
<td style="border:1px solid #ffffff;vertical-align:top;padding:7px 7px 7px 7px"><br><span style="font-size:15px;font-family:Arial;color:#000000;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span><p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt">
<span style="font-size:15px;font-family:Arial;color:#000000;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Francesc Romà i Frigolé</span></p>
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:#000000;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">CTO Social & Beyond</span></p>
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:#000000;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">+34 93.1234.962</span></p>
</td></tr><tr style="height:0px"><td style="border:1px solid rgb(255,255,255);vertical-align:top;padding:7px;text-align:right"><img src="https://lh5.googleusercontent.com/zk5_dKdIarT-DZeR03PGzsa3FijUdx_GFfM9-ZSKeTniik3-KB-OCsBsC0qsFqulhsPUDJEpkuSlTlXhhccUWpBDkV9Erm2uX2cFc1sAs46xy3ZCF7RgkbBqhQ" height="53px;" width="90px;"></td>
<td style="border:1px solid #ffffff;vertical-align:top;padding:7px 7px 7px 7px"><p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:#000000;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Torre Telefónica Diagonal 00, planta 11, Wayra </span></p>
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:#000000;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Plaça Ernest Lluch i Martín, 5</span></p>
<p dir="ltr" style="line-height:1;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:#000000;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">08019 Barcelona</span></p>
</td></tr></tbody></table></div></div></div>
<br><br><div class="gmail_quote">On Wed, Oct 16, 2013 at 10:53 PM, Heikki Vatiainen <span dir="ltr"><<a href="mailto:hvn@open.com.au" target="_blank">hvn@open.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 10/15/2013 05:47 PM, Francesc Romà i Frigolé wrote:<br>
<br>
> When the total session time used for the day as given by the<br>
> AcctTotalSinceQuery is exactly the same as Max-Daily-Session in the<br>
> authentication request Radiator allows the user to log in.<br>
><br>
> Only if the session time exceed the max daily session, even by just one<br>
> second, will Radiator complain about max session exceeded.<br>
<br>
</div>I would need to see your configuration to say what happens exactly, but<br>
most likely this can happen. If the amount of used seconds is 86400,<br>
this does not *exceed* one day, yet.<br>
<div class="im"><br>
> Is this the correct behaviour? I'd expect also to get a session exceeded<br>
> error when AcctTotalSinceQuery == Max-Daily-Session.<br>
<br>
</div>I think it currently does work as documented ' ... If it is exceeded,<br>
the user is rejected. ...' says the reference manual for Max-Daily-Session.<br>
<div class="im"><br>
> This behaviour is causing issues for us because Radiator is returning<br>
> an authentication "accept" with a zero session time, which Mikrotik<br>
> RouterOS hotspotl interprets as infinite session length, rather than a<br>
> session exceeded error.<br>
<br>
</div>I can see that returning Session-Timeout of 0 with Access-Accept will<br>
cause problems in your case. The RADIUS RFC is silent about 0 being a<br>
special value, but it appears there are other implementations too which<br>
consider 0 to mean inifinity.<br>
<div class="im"><br>
> Is this a bug or there is something wrong with my settings?<br>
<br>
</div>Maybe this is a gray area? You could consider e.g., a PostAuthHook to<br>
see if Session-Timeout is going to be 0 and then switch the result to<br>
reject. Might even be a good time to reject sessions that have only a<br>
few seconds left?<br>
<br>
Thanks,<br>
Heikki<br>
<br>
--<br>
Heikki Vatiainen <<a href="mailto:hvn@open.com.au">hvn@open.com.au</a>><br>
<br>
Radiator: the most portable, flexible and configurable RADIUS server<br>
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,<br>
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,<br>
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,<br>
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,<br>
NetWare etc.<br>
_______________________________________________<br>
radiator mailing list<br>
<a href="mailto:radiator@open.com.au">radiator@open.com.au</a><br>
<a href="http://www.open.com.au/mailman/listinfo/radiator" target="_blank">http://www.open.com.au/mailman/listinfo/radiator</a><br>
</blockquote></div><br></div>