<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 28 Aug 2012, at 23:05, Matthias Nagel <<a href="mailto:matthias.h.nagel@gmail.com">matthias.h.nagel@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hello,<br><br>Am Dienstag 28 August 2012, 23:11:57 schrieb Alan DeKok:<br><blockquote type="cite">Matthias Nagel wrote:<br><blockquote type="cite">if two accounting messages for the same session are sent by the authenticator very quickly, the messages may be processed by the radius server in the wrong order. This results into two sessions being accounted instead of one. The second "phantom" session stays open for ever, because it never receives any update and/or stop message.<br></blockquote><br> This is a well-known issue with RADIUS. Packets may appear in any order.<br><br><blockquote type="cite">Example:<br><br>If a supplicant authenticates and immediately disconnects again, the following steps are executed:<br><br>1) The authenticator sends an accounting start message<br>2) The authenticator sends an accounting stop message immediately<br>3) The RADIUS server receives the start message and assigns it to thread #1<br>4) The RADIUS server receives the stop message and assigns it to thread #2<br>5) Thread #2 terminates first and the accounting stop message is written to the PostgreSQL database. The SQL UPDATE statement fails, because there is no entry for this session that could be updated, as the start message has not been processed yet. Hence, an INSERT INTO statement is executed as a fail-over measure.<br>6) Thread #1 terminates and an SQL INSERT statement is performed in order to log the start message.<br></blockquote><br> That doesn't make sense. If the table indexes are set up correctly,<br>the SQL insert will fail at step (6). The module will then try the<br>update query, which should succeed.<br><br></blockquote><br>This is correct, if one has some kind of key to identify a session that could be used as a database index. But unfortunately there are a lot of authenticators out there, that do not correctly generate radius accounting session ids. Basicly I see three different types (despite the correct one):<br><br>1) Authenticators that do no send a session id at all (Acct-Session-Id is empty)<br></blockquote><div><br></div><div>Then they're breaking RFC 2866 and cannot claim to support RADIUS Accounting. Users should log a defect case, demand a refund, or sue them.</div><div><br></div><div><pre class="newpage" style="font-size: 1em; margin-top: 0px; margin-bottom: 0px; page-break-before: always; "><span class="h3" style="line-height: 0pt; display: inline; font-size: 1em; font-weight: bold; "><h3 style="line-height: 0pt; display: inline; font-size: 1em; "><a class="selflink" name="section-5.13" href="http://tools.ietf.org/html/rfc2866#section-5.13" style="color: black; text-decoration: none; ">5.13</a>. Table of Attributes</h3></span>
The following table provides a guide to which attributes may be found
in Accounting-Request packets. No attributes should be found in
Accounting-Response packets except Proxy-State and possibly Vendor-
Specific.
</pre><div><br></div><div><pre class="newpage" style="font-size: 1em; margin-top: 0px; margin-bottom: 0px; page-break-before: always; "> # Attribute</pre><div><span class="Apple-tab-span" style="white-space:pre"> </span>.</div></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>.</div><div><pre class="newpage" style="font-size: 1em; margin-top: 0px; margin-bottom: 0px; page-break-before: always; "> 1 Acct-Session-Id</pre><div><br></div></div></div><br><blockquote type="cite">2) Those that always return the same session id (even if the user name differs)<br></blockquote><div><br></div><div>Then they're breaking RFC 2866 and cannot claim to support RADIUS Accounting. Users should log a defect case, demand a refund or sue them.</div><div><div><br></div><div>(see below)</div></div><br><blockquote type="cite">3) Those that always return a new session id even if the requests (start/update/stop) belong to the same session<br></blockquote><div><br></div><div>Then they're breaking RFC 2866 and cannot claim to support RADIUS Accounting. Users should log a defect case, demand a refund or sue them.</div><div><br></div><div><div><pre class="newpage" style="font-size: 1em; margin-top: 0px; margin-bottom: 0px; page-break-before: always; "><span class="h3" style="line-height: 0pt; display: inline; font-size: 1em; font-weight: bold; "><br></span></pre><pre class="newpage" style="font-size: 1em; margin-top: 0px; margin-bottom: 0px; page-break-before: always; "><span class="h3" style="line-height: 0pt; display: inline; font-size: 1em; font-weight: bold; "><h3 style="line-height: 0pt; display: inline; font-size: 1em; "><a class="selflink" name="section-1.2" href="http://tools.ietf.org/html/rfc2866#section-1.2" style="color: black; text-decoration: none; ">1.2</a>. Terminology</h3></span></pre><div><br></div></div><div><pre class="newpage" style="font-size: 1em; margin-top: 0px; margin-bottom: 0px; page-break-before: always; "> session Each service provided by the NAS to a dial-in user
constitutes a session, with the beginning of the session
defined as the point where service is first provided and
the end of the session defined as the point where service
is ended. A user may have multiple sessions in parallel or
series if the NAS supports that, with each session
generating a separate start and stop accounting record with
its own Acct-Session-Id.</pre></div><div><br></div><div>If instead or returning:</div><div><br></div><div>HTTP/1.1 200 OK</div><div><br></div><div>as the status line a HTTP server started returning</div><div><br></div><div>HTTP/6.9 RAINBOWS</div><div><br></div><div>It could not claim to implement RFC2616.</div><div><br></div><div>By working around compliance issues, you're encouraging your equipment vendors to be lazy, you have to work with them to get them to fix their issues, else it'll be just as crappy for the next person who comes along.</div><div><br></div><div>-Arran</div><div><br></div></div></div></body></html>