Greetings,

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).
...

and

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.

Cheers,
Andrew Hull

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)
> 
> J.
> 
> 
> --
> Jonathan De Graeve
> Network/System Administrator
> Imelda vzw
> Informatica Dienst
> 015/50.52.98
> Jonathan dot de dot graeve at imelda dot be
>