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

Reply via email to