Jonathan De Graeve wrote:
> 
> This 'inconsistency' is there for a good reason:
> It is because I currently only uploaded a changed radius authentication
> in the published images, not yet the radius accounting stuff (that
> coding is already 'done' but needs testing) (Note that I did changed the
> accounting behaviour to work with changing NAS-Port's). I wanted to be
> sure that no one has problems with the first part of the code. If this
> is true, I will publish the images with both authentication and
> accounting as soon as I get good response from the images, considering
> the first part of the code as stable. 

Johathan,

First, let me thank you for your efforts. The NAS-Port functionality 
works very well, as does your new stack style (for lack of a better 
term) auth code as a whole.

I noticed that the accounting functions were by-in-large (if not 
exactly) the same as 1.2 stable. And the calling-station-id 
inconsistency now makes perfect sense.


> 
> Question: it's normally not a problem to have missing attributes in the
> Accounting Request start packages. They may be in the Accounting Request
> Updates/Stop. Does your radius server gives problems if they aren't in
> the Accounting Start? (its for further coding that I want to know this)
> 
> 

The short answer is that Vircom's RADIUS server does not normally give 
me problems with your current image (build 20051107_09-38) now that 
nas-port is functional.

Access Request, Accounting Start and Stop all work with their current 
presence or absence of RADIUS attributes.

The problem arises when I enable the "Calling-station-id concurrency" 
feature. With this feature enabled, RADIUS treats calling-station-id 
much the same as nas-port -- a field that is unique to each user on the NAS.

Brief description of what happens:

In general, with calling-station-id concurrency enabled RADIUS has 3 
fields used to identify users: user-name, nas-port, and 
calling-station-id. Nas-port and calling-station-id are non-shareable, 
and user-name is governed by port-limit. In order for an accounting 
packet to be associated with an authenticated user, the nas-port, 
user-name, and calling-station-id attributes must all match.

- With calling-station-id concurrency enabled, RADIUS receives the 
access request and returns the access accept (assuming I didn't 
fat-finger the pwd).

- RADIUS receives the Accounting start request and attempts to match it 
to a user.

- Finding no matching users, it assumes the access-request packet died 
in transit (yay UDP). It adds a user (if port-limit allows) and sends 
the accounting-response back to the NAS. There are now two users logged 
in according to RADIUS, one still in ACK, one in Accounting Start. They 
both have the same user-name, and nas-port, but different 
calling-station-id (one the client's MAC, the other NULL).

- The first user created is still in the ACK state. When the ACK state 
timeout is reached, that user is quietly removed.


With calling-station-id concurrency disabled, RADIUS reacts in the same 
way save that it only uses user-name and nas-port to distinguish users. 
It still records calling-station-id, but it is not a vital part of 
RADIUS operation.


> 
>>Jonathan -- is this something you could easily remedy?
> 
> Yes it is, it's waiting in the new accounting code :)
> 
> Old code, so normal behaviour :)
> 
>  

Wonderful. Thank you so much.


On a side note: I looked at some of the RADIUS packets for our dial-up 
users. We have Cisco access servers located in areas with and without 
callerid. In the callerid enabled areas, calling-station-id is present 
in every RADIUS packet: Auth, accounting start/stop, watchdog, 
everything. In the callerid incapable areas, calling-station-id is never 
sent.


Again, thank you for the work you've done. I look forward to checking 
out your accounting functions.

Andrew