(RADIATOR) NAS-Port and NAS-Port-Type

[Andrea Brancatelli]

Recently I talked with Mike (or maybe with Hugh) in Private Mail (that 
was one of the cases I was talking about) about an Access Point I have 
that is currently reporting all the connection as coming from "NAS-Port: 
9". That is giving problems to the SESSION table because when a second 
user logs in radiator blindly deletes any user that was on the same 
NAS-Port on the same AP.

Talking with Mike he pointed me that this was a wrong behaviour and that 
I had to point this out to the manifactour of the AP.

I did.

Their answer is that the AP works well and has no problem of any kind 
with the RadiusNT package they use for testing (and this is a pretty 
lame answer) but also pointed me that that behaviour is not wrong 
according to RFC 2138 and 2865... see http://www.ietf.org/rfc/rfc2865.txt
Basically they said that since NAS-Port-Type is correctly reported as 
Wireless - IEEE 802.11 (19) the Radius server should be smart enough not 
to assume that the NAS is able to discriminate among Ports. Wireless 
Ports surely are not "phisical ports" (as NAS-Port description refers 
to) and the RFC clearly says that "Either NAS-Port (5) or NAS-Port-Type 
or both SHOULD be present in an Access-Request packet, if the NAS 
differentiates among its ports."... _IF_ the Nas differentiates among 
its port, don't expect the NAS to be able to do that.

(actually I have disassembled their firmware and I must say they have 
concrete reasons not to implement the "real" NAS-Port concept... the AP 
is Linux Embedded and the 9 it is returning refers to the tty assigned 
to the Wireless Lan Card. They use Radclient to do the Radius Login and 
it assume the tty number as the NAS-Port - something that would be 
correct if the NAS was a "rack-modem")

So, trying to make a long story short what I did was replacing the 
NAS-Port definition in the SESSION database from Integer to Char 22 and 
replace the Session Add and Session Delete SQL query to use the remote 
peer MAC Address to fake out an univoque NAS-Port. It works.

My suggestion for you guys is that maybe you can be prepared to work 
around similar situation and get somewhat deeper in the SESSION table 
handling, for example including the MAC address of the remote peer (if 
it is available, of course) as an addedd UNIQUEness field for deleting 
stuff in the session database....

Delete Session query... Delete from session where NAS = something, 
NAS-Port = something and MAC = something.

Just an idea... any comment?

Hope this is somewhat useful.

Andrea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20031003/fa02cdf6/attachment.html>