possible radtest parameter issue

[Laker Netman]

I am trying to use radtest to check some changes I'm
making in my FR "users" file. My goal is to be able to
let visitors use our wifi network for Internet access
by authorizing them against a generic user/password
combo in "users" like "guest" & "wireless", while
everyone in the company, who is actually connecting to
resources on our LAN, authorize/authenticate against
our Active Directory (which is already working).

I read the radtest man file and Googled for some
examples, so I think my syntax is accurate. Am I
correct that radtest, by use of the optional
"nasname", can make FR behave as if the
Access-Requests are coming from a different NAS than
the host upon which it is being run? Either way the
results are not what I anticipated.

When I run the following from a terminal on my FR box:
radtest test test radserver.my.domain 10 secret
ap.my.domain

I get this reply:
Sending Access-Request of id 191 to
192.168.12.210:1812
        User-Name = "test"
        User-Password = "test"
        NAS-IP-Address = RADSERVER
        NAS-Port = 10
        Framed-Protocol = PPP

I didn't think the Framed-Protocol attribute should
appear unless the optional value following "secret"
was an integer > 0. This looks to me like the
"ap.my.domain" is being taken as [ppphint] rather than
[nasname].  This seems incorrect to me since ppphint
and nasname are both listed as optional, which I
concluded means exclusive of one another. Is that
right?

I expanded my tests. Adding a zero after "secret"
(radtest test test radserver.my.domain 10 secret 0
ap.my.domain) produced the following:
Sending Access-Request of id 105 to
192.168.12.210:1812
        User-Name = "test"
        User-Password = "test"
        NAS-IP-Address = ap.my.domain
        NAS-Port = 10
        Framed-Protocol = PPP

So now the NAS-IP-Address attribute is populated, but
the Framed-Protocol attribute is still appearing, even
though I explicitly placed a zero at the ppphint
parameter position. And it's a hostname in
NAS-IP-Address, rather than an IP address :) Neither
seems right. Is there a common misconfiguration I
could look for elsewhere?

Here is the last thing that happened I'm not sure
about:
Sending Access-Request of id 105 to
192.168.12.210:1812
        User-Name = "test"
        User-Password = "test"
        NAS-IP-Address = ap.my.domain
        NAS-Port = 10
        Framed-Protocol = PPP
Re-sending Access-Request of id 105 to
192.168.12.210:1812
        User-Name = "test"
        User-Password =
")\346\216Axj\002\322\264\361\330-12Q\242"
        NAS-IP-Address = ap.my.domain
        NAS-Port = 10
        Framed-Protocol = PPP
Re-sending Access-Request of id 105 to
192.168.12.210:1812
        User-Name = "test"
        User-Password =
")\346\216Axj\002\322\264\361\330-12Q\242"
        NAS-IP-Address = ap.my.domain
        NAS-Port = 10
        Framed-Protocol = PPP
Re-sending Access-Request of id 105 to
192.168.12.210:1812
        User-Name = "test"
        User-Password =
")\346\216Axj\002\322\264\361\330-12Q\242"
        NAS-IP-Address = ap.my.domain
        NAS-Port = 10
        Framed-Protocol = PPP

The output from radiusd -X is always:
Ignoring request from unknown client
192.168.12.210:32773
--- Walking the entire request list ---
Nothing to do.  Sleeping until we see a request.
rad_recv: Access-Request packet from host
192.168.12.210:32773, id=105, length=62
Ignoring request from unknown client
192.168.12.210:32773
--- Walking the entire request list ---
Nothing to do.  Sleeping until we see a request.
rad_recv: Access-Request packet from host
192.168.12.210:32773, id=105, length=62
Ignoring request from unknown client
192.168.12.210:32773
--- Walking the entire request list ---
Nothing to do.  Sleeping until we see a request.
rad_recv: Access-Request packet from host
192.168.12.210:32773, id=105, length=62
Ignoring request from unknown client
192.168.12.210:32773

What caused the User-Password field to change? Each
time I rerun the command, the User-Password is munged
differently, but stays munged the same way on
subsequent resends until I break out of radtest, if
that makes sense. Based on the debug output it doesn't
look like FR acted on the request at all.

I have NTRadPing and the test works as expected from
my desktop (which is configured in clients.conf), but
it's not ideal as it doesn't match what I'm really
trying to test (access through a wifi AP) and I do not
have the resources available to configure a standalone
test machine outside of our AD/domain.

Anyway, I'm curious what the purpose of nasname is. 
And now, I'm hoping someone can explain why I'm seeing
the above results from radtest.

BTW, I am running FR 1.0.5 (compiled from source) on
Fedora Core 4.

TIA,
Laker


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com