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.
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
>>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
Again, thank you for the work you've done. I look forward to checking
out your accounting functions.