Jonathan De Graeve's build 20051110_15-37 is working very well. I agree
with the dev freeze decision. It time to pound the hell out of this
build and see if it holds up.
Also, regarding Lee Sharp's concern: RFC2865 is very clear on this.
4.1 -- Access request
An Access-Request SHOULD contain a User-Name attribute. It MUST
contain either a NAS-IP-Address attribute or a NAS-Identifier
attribute (or both).
5.4 -- NAS-IP-Address
Either NAS-IP-Address or NAS-Identifier MUST be present in
an Access-Request packet.
If passing only NAS-Identifier (32) is causing some RADIUS servers to
not authenticate, then that software is not standards compliant at all.
Passing NAS-Identifer (32) is correct
Passing NAS-IP-Address (4) is correct
Passing 32 and 4 is correct
In my opinion, passing NAS-Identifier makes the most sense. One example
of my opinion is running a m0n0 box behind a NAT. This would create an
inconsistency between the value of NAS-IP-Address and the source address
in the packet header. As such, I recommend not passing NAS-IP-Address.
If NAS-IP-Address is not passed, then NAS-Identifier must, and it is.
Jonathan De Graeve wrote:
> I pretty sure they just saw NAS-IP-Address from the radius server as a
> server assigned attribute (not from the m0n0wall, because he doesn't
> sent that)
> When in access-requests / accounting-requests NAS-IP-Address is missing
> (then NAS-Identifier must be set, which is) the RADIUS will assign the
> NAS-IP-Address with value of the source-ip of the packet. No matter
> which interface the packet goes out on the m0n0wall, the NAS-IP will
> always be correct in this matter ;)
> It's only a problem when you have dynamic ip, and still want to lock on
> NAS-IP-Address (which can be static)
> Jonathan De Graeve
> Network/System Administrator
> Imelda vzw
> Informatica Dienst
> Jonathan dot de dot graeve at imelda dot be