Re: 1.1.7 to 2.X Upgrade ?
manIP wrote: > Is there an automatic command such *freeradius -upgrade *? No. If there was, I would have told you to use such a command. > Could you tell me how to upgrade without starting everything from scratch? No. As I said, *much* of the configuration is identical. It should take you less than a day to do the migration. Many people do it in an hour. > Is there any patch I can install without re-installing everything? No. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 1.1.7 to 2.X Upgrade ?
Thanks Alan for your reply, Is there an automatic command such *freeradius -upgrade *? Could you tell me how to upgrade without starting everything from scratch? Is there any patch I can install without re-installing everything? Many Thanks * *On Sun, Dec 21, 2008 at 7:47 AM, Alan DeKok wrote: > manIP wrote: > > I have installed freeradius last year (October 2007) on a debian and > > after reading the post on freeradius.org, I am > > wondering if it is really necessary to upgrade to the last version > > (because of some security bugs). Any advice? > > It's not necessary. But if you ask questions, the usual response will > be "it will be easier if you upgrade". > > > Also, anyone could give me a hint on how to upgrade easily without > > getting complications? > > Much of the configuration remains the same, or similar. I woudl > suggest going through your existing configuration, and gradually copying > it (with edits) to the default configuration for 2.x. > > Alan DeKok. > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: [Wimax with Alcatel Base Station]
Thomas Fagart wrote: > 1. Using radmin and the debug and even after reading man unlang, i'm > still not able to filter requests based on client IP (this is easier > then I'll be able to get only requests coming from the BS) What have you tried? Why hasn't it worked? > 2. Having read the lasts posts on Wimax saying we should use the last > stable release, it seems that the stable release is not available from > http, then I use the git, but I'm only able to get the development > release (2.2.0) using the following command > > portable-bsd# git clone git://git.freeradius.org/freeradius-server.git > radiusd Then: $ git checkout origin/stable I'll update the web site to add this information. > 3. Using 2.1.3 I got the following output between BS and radius > > http://www.brozs.net/log/radius.log > > It seems EAP never says it's ok (might be Base Station Related but I've > got no access to check) This is in the FAQ and in the comments in eap.conf. The server sends a challenge, and the client never continues the EAP conversation. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 1.1.7 to 2.X Upgrade ?
manIP wrote: > I have installed freeradius last year (October 2007) on a debian and > after reading the post on freeradius.org, I am > wondering if it is really necessary to upgrade to the last version > (because of some security bugs). Any advice? It's not necessary. But if you ask questions, the usual response will be "it will be easier if you upgrade". > Also, anyone could give me a hint on how to upgrade easily without > getting complications? Much of the configuration remains the same, or similar. I woudl suggest going through your existing configuration, and gradually copying it (with edits) to the default configuration for 2.x. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Status counters
Anders Holm wrote: > Heh. I sure did. Though, I'm thinking slightly differently I suppose.. > "How can something be accepted which has not been requested?". That is the definition of how Status-Server works. This definition goes back to 1996 in a number of RADIUS servers. It is now being standardized: http://tools.ietf.org/html/draft-ietf-radext-status-server-03 Which was written by... me. > And I > understand why the Accepts increment. I just don't understand why the > Requests aren't, as that how I'd look at a query to get the Status, a > Request which specifically is an Access-Request to get Status-Server > data returned. At least, that is my view. Are you being deliberately obtuse? Or just deliberately difficult? a) There is a counter for Access-Requests b) There is a counter for Access-Accepts c) The response to Status-Server is Access-Accept That's how it works. 3 simple rules that anyone should be able to understand. There is no counter for Status-Server, and the "Access-Request" counter is not incremented when a "Status-Server" packet is received. Why? Because Status-Server packets aren't Access-Request packets! They're spelled differently! And *pronounced* differently! > Considering I'm using exactly what the example from the Wiki tells me, > there is an Authentication, so logically, I'm asking for Access. > > "# echo "Message-Authenticator = 0x00, FreeRADIUS-Statistics-Type = 1" | \" Now you are being *deliberately* misleading. The next line that you *conveniently* didn't quote is: radclient localhost:18120 status adminsecret See the "status" word? The "radclient" documentation says that this means "send Status-Server". And nothing is being authenticated. No user, no machine, nothing. Nothing is asking for access. > So, Access-Accepts I got no problem with. That stacks up. Requests and > Rejects is what I'm curious about. If my shared secret is wrong for > example, doesn't that get counted as an Access-Reject, or doesn't it get > counted at all? This is a fascinating discusion in how a simple example can be twisted into something unrecognizable. The RADIUS *packet* is being signed. No RADIUS *users* are being authenticated. And the response to a Status-Server is *never* Access-Reject. Go read my draft. If you don't understand it, read it again. If you still don't understand it, ask someone *else* about it. >> There is only one Status-Server packet. I don't know what you mean by >> "Status-*" > > If one separates the Requests versus Accepts and Rejects, I'd see 3 .. > If one follows the set examples for other counters anyway. Nonsense. This confusion happens only because you fail to comprehend the 3 simple rules I posted above. Instead, you are working valiently to come up with a tortured explanation based on a near-total misunderstanding. > Sure. In your own scenario you're considering several clients. On disk > isn't good enough either. Losing a disk also means losing data. You only have one disk? You must be terribly poor. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
1.1.7 to 2.X Upgrade ?
Hi all, I have installed freeradius last year (October 2007) on a debian and after reading the post on freeradius.org, I am wondering if it is really necessary to upgrade to the last version (because of some security bugs). Any advice? Also, anyone could give me a hint on how to upgrade easily without getting complications? (FYI, I've made a debian package from the source code) Thanks again Khalid - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
[Wimax with Alcatel Base Station]
Hello, After being able to produce great statistics with the new status server feature, being able to do nice debug on production server with radmin, (thanks again for this great features !), i'm also trying to do wimax authentication with freeradius 2.1.3. Here are some questions : 1. Using radmin and the debug and even after reading man unlang, i'm still not able to filter requests based on client IP (this is easier then I'll be able to get only requests coming from the BS) 2. Having read the lasts posts on Wimax saying we should use the last stable release, it seems that the stable release is not available from http, then I use the git, but I'm only able to get the development release (2.2.0) using the following command portable-bsd# git clone git://git.freeradius.org/freeradius-server.git radiusd Initialized empty Git repository in /usr/home/tom/radiusd/.git/ remote: Counting objects: 60339, done. remote: Compressing objects: 100% (15102/15102), done. remote: Total 60339 (delta 46934), reused 57865 (delta 45104) Receiving objects: 100% (60339/60339), 11.50 MiB | 2655 KiB/s, done. Resolving deltas: 100% (46934/46934), done. I guess I'm not using the correct URL for stable, but I was not able to find the good one on docs ? 3. Using 2.1.3 I got the following output between BS and radius http://www.brozs.net/log/radius.log It seems EAP never says it's ok (might be Base Station Related but I've got no access to check) www1# more /usr/home/tom/radius.log | grep eaptls Sun Dec 21 00:36:18 2008 : Debug: [tls] eaptls_verify returned 7 Sun Dec 21 00:36:18 2008 : Debug: [tls] eaptls_process returned 13 Sun Dec 21 00:36:19 2008 : Debug: [tls] eaptls_verify returned 1 Sun Dec 21 00:36:19 2008 : Debug: [tls] eaptls_process returned 13 Sun Dec 21 00:36:19 2008 : Debug: [tls] eaptls_verify returned 1 Sun Dec 21 00:36:19 2008 : Debug: [tls] eaptls_process returned 13 Sun Dec 21 00:36:19 2008 : Debug: [tls] eaptls_verify returned 1 Sun Dec 21 00:36:19 2008 : Debug: [tls] eaptls_process returned 13 Sun Dec 21 00:36:19 2008 : Debug: [tls] eaptls_verify returned 1 Sun Dec 21 00:36:19 2008 : Debug: [tls] eaptls_process returned 13 Sun Dec 21 00:36:21 2008 : Debug: [tls] eaptls_verify returned 7 Sun Dec 21 00:36:21 2008 : Debug: [tls] eaptls_process returned 13 Sun Dec 21 00:36:21 2008 : Debug: [tls] eaptls_verify returned 1 Sun Dec 21 00:36:21 2008 : Debug: [tls] eaptls_process returned 13 Sun Dec 21 00:36:21 2008 : Debug: [tls] eaptls_verify returned 1 Sun Dec 21 00:36:21 2008 : Debug: [tls] eaptls_process returned 13 Sun Dec 21 00:36:21 2008 : Debug: [tls] eaptls_verify returned 1 Sun Dec 21 00:36:21 2008 : Debug: [tls] eaptls_process returned 13 Sun Dec 21 00:36:21 2008 : Debug: [tls] eaptls_verify returned 1 Sun Dec 21 00:36:21 2008 : Debug: [tls] eaptls_process returned 13 Thanks Thomas - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Status counters
Alan DeKok wrote: Anders Holm wrote: So, for Access-Requests we ignore Status-Server packets, but Status-Server packets do increment Access-Accept? Perhaps you didn't see my message or read the names of the counters. One counter counts Access-Requests, and another one counts Access-Accepts. There is no "ignore" of Status-Server packets. The reason for incrementing Access-Accepts has been explained. Heh. I sure did. Though, I'm thinking slightly differently I suppose.. "How can something be accepted which has not been requested?". And I understand why the Accepts increment. I just don't understand why the Requests aren't, as that how I'd look at a query to get the Status, a Request which specifically is an Access-Request to get Status-Server data returned. At least, that is my view. Considering I'm using exactly what the example from the Wiki tells me, there is an Authentication, so logically, I'm asking for Access. "# echo "Message-Authenticator = 0x00, FreeRADIUS-Statistics-Type = 1" | \" So, Access-Accepts I got no problem with. That stacks up. Requests and Rejects is what I'm curious about. If my shared secret is wrong for example, doesn't that get counted as an Access-Reject, or doesn't it get counted at all? Would there be a counter for Status-Requests, so I could correlate the figures so I can figure out what is what? Sure. Send a patch. Sure. Would there be an idea to have separate counters just for the Status-* type counters? Might be one handy way to handle that, as that'd separate those type of stats from each other as well as giving higher resolution. There is only one Status-Server packet. I don't know what you mean by "Status-*". If one separates the Requests versus Accepts and Rejects, I'd see 3 .. If one follows the set examples for other counters anyway. If you need deltas, track them yourself in the client app. It's the only way to get them right. Mmm.. Even then there'd be potential race conditions, data loss etc. Huh? You have one client app querying the server and keeping track of deltas. Other client apps query it. And data loss can be prevented by keeping track of counters on disk, too Sure. In your own scenario you're considering several clients. On disk isn't good enough either. Losing a disk also means losing data. There's a lot of different variables to consider, as I'm building a highly available and not to mention reliable platform. Can be achieved with either multiple clients checking Status, or a hot-cold setup, or.. or.. or.. There's multiple choices, with varying degrees of reliability and completely different sets of failure scenarios. I'd be using this data to gather metrics, and then in turn have alarms based on those metrics (levelling and thresholds). Ensuring the base data is correct then is of importance. OR at least understanding what the base data is telling us is of importance I should say .. ;) Sure. Track it, store it, no problem. I have a feeling that's the better approach of them all .. Store the Status values in a replicated database, and have the monitoring clients have some decent smarts. Needs some pondering I think. //anders - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Status counters
Anders Holm wrote: > So, for Access-Requests we ignore Status-Server packets, but > Status-Server packets do increment Access-Accept? Perhaps you didn't see my message or read the names of the counters. One counter counts Access-Requests, and another one counts Access-Accepts. There is no "ignore" of Status-Server packets. The reason for incrementing Access-Accepts has been explained. > Would there be a > counter for Status-Requests, so I could correlate the figures so I can > figure out what is what? Sure. Send a patch. > Would there be an idea to have separate counters just for the Status-* > type counters? Might be one handy way to handle that, as that'd separate > those type of stats from each other as well as giving higher resolution. There is only one Status-Server packet. I don't know what you mean by "Status-*". >> If you need deltas, track them yourself in the client app. It's the >> only way to get them right. >> > Mmm.. Even then there'd be potential race conditions, data loss etc. Huh? You have one client app querying the server and keeping track of deltas. Other client apps query it. And data loss can be prevented by keeping track of counters on disk, too. > I'd > be using this data to gather metrics, and then in turn have alarms based > on those metrics (levelling and thresholds). Ensuring the base data is > correct then is of importance. OR at least understanding what the base > data is telling us is of importance I should say .. ;) Sure. Track it, store it, no problem. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Help Regarding SQL Counter
>but one thing i wanted to ask you why NAS-IP-Addres is always shown as >0.0.0.0 in my case nas ip address is 192.168.2.5. do i need to make >any other configuration. >- Is that in the request packet? If it is - that's what your NAS is sending. Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Status counters
Alan DeKok wrote: Anders Holm wrote: Looking a tad at the counters and how they get incremented I see the following: Sending Access-Accept of id 20 to 127.0.0.1 port 32772 FreeRADIUS-Total-Access-Requests = 0 FreeRADIUS-Total-Access-Accepts = 36 FreeRADIUS-Total-Access-Rejects = 0 FreeRADIUS-Total-Access-Challenges = 0 FreeRADIUS-Total-Auth-Responses = 36 This is on a test server, which currently is only getting requests for status. Shouldn't the Access-Requests also be incremented? No. The counter tracks Access-Requests, not Status-Server packets. I mean, if the Access-Accept is incremented, we must have had a request to being with. No. The response to a Status-Server is an Access-Accept. So, for Access-Requests we ignore Status-Server packets, but Status-Server packets do increment Access-Accept? Would there be a counter for Status-Requests, so I could correlate the figures so I can figure out what is what? Would there be an idea to have separate counters just for the Status-* type counters? Might be one handy way to handle that, as that'd separate those type of stats from each other as well as giving higher resolution. Also, using these counters for monitoring, it would be nice to see deltas from the previous Status request. Though, if I would go ahead and clear the counters (haven't even checked if it is possible tbh) I might have requests arriving between my last Status request packet and my clearing the counter, meaning my metrics would be incorrect. Would it be trivial to add some form of delta-since-last-status-request, or is it preferred to keep that in an external script? It would be extremely difficult. *Who* asked for those statistics last? Is the "last statistics" item tracked by client IP? Client port? Anything else...? Indeed. Conundrum to say the least. I'll look at various alternatives, but "marshalling" through a central location and letting the "marshal" keeping track of previous and current numbers and returning the delta is probably the safest way to handle that. Just trying to figure out which would be the best route, and what others think of the idea. Might be useful for others here, so ... If you need deltas, track them yourself in the client app. It's the only way to get them right. Mmm.. Even then there'd be potential race conditions, data loss etc. I'd be using this data to gather metrics, and then in turn have alarms based on those metrics (levelling and thresholds). Ensuring the base data is correct then is of importance. OR at least understanding what the base data is telling us is of importance I should say .. ;) //anders - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: external script reply
t...@kalik.net írta:
now I have just one output, this:
Exec-Program output: Tunnel-Private-Group-Id = vlan20
no need "/n"
That is OK.
and the users file contains:
DEFAULT auth-type = Accept
Tunnel-Type = VLAN,#both are fix, send everytime, when accepted
Tunnel-Medium-Type = IEEE-802
That is fine as well.
What have to change, cos the Group-Id is not sent.
Can you post the configuration of exec module that calls you script.
There should be output = reply in it.
Ivan Kalik
Kalik Informatika ISP
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
okay let's see:
here is the first settings which is not works: (Group-Id is not sent)
debug log:
+- entering group post-auth {...}
[get-vlan] expand: %{mschap:User-Name} -> Hege
Exec-Program output: Tunnel-Private-Group-Id = 999
Exec-Program-Wait: value-pairs: Tunnel-Private-Group-Id = 999
Exec-Program: returned: 0
++[get-vlan] returns ok
} # server inner-tunnel
[peap] Got tunneled reply code 2
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
EAP-Message = 0x03090004
Message-Authenticator = 0x
User-Name = "TEST\\Hege"
[peap] Got tunneled reply RADIUS code 2
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
EAP-Message = 0x03090004
Message-Authenticator = 0x
User-Name = "TEST\\Hege"
[peap] Tunneled authentication was successful.
[peap] SUCCESS
[peap] Saving tunneled attributes for later
++[eap] returns handled
Sending Access-Challenge of id 33 to 192.168.2.2 port 1812
EAP-Message =
0x010a00261900170301001bb32c77d09f7f70675ba4f6ef975008f2807a19c9950a8bee9ea770
Message-Authenticator = 0x
State = 0xfa60c880f36ad1ad83e4969de6c343b6
Finished request 9.
Going to the next request
Waking up in 4.6 seconds.
rad_recv: Access-Request packet from host 192.168.2.2 port 1812, id=34,
length=175
NAS-IP-Address = 192.168.2.2
NAS-Port = 50019
NAS-Port-Type = Ethernet
User-Name = "TEST\\Hege"
Called-Station-Id = "00-0A-F4-2E-DF-13"
Calling-Station-Id = "00-80-C8-CD-4F-31"
Service-Type = Framed-User
Framed-MTU = 1500
State = 0xfa60c880f36ad1ad83e4969de6c343b6
EAP-Message =
0x020a00261900170301001b21c0560fc73a5ff63ec05c899069439c4e57f7de1252f65f1ce21b
Message-Authenticator = 0x90917ce085fc882aa837e4d65415423f
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
[suffix] No '@' in User-Name = "TEST\Hege", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] EAP packet type response id 10 length 38
[eap] Continuing tunnel setup.
++[eap] returns ok
Found Auth-Type = EAP
+- entering group authenticate {...}
[eap] Request found, released from the list
[eap] EAP/peap
[eap] processing type peap
[peap] processing EAP-TLS
[peap] eaptls_verify returned 7
[peap] Done initial handshake
[peap] eaptls_process returned 7
[peap] EAPTLS_OK
[peap] Session established. Decoding tunneled attributes.
[peap] Received EAP-TLV response.
[peap] Success
[peap] Using saved attributes from the original Access-Accept
[eap] Freeing handler
++[eap] returns ok
Sending Access-Accept of id 34 to 192.168.2.2 port 1812
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
User-Name = "TEST\\Hege"
MS-MPPE-Recv-Key =
0x525851a76af3aa5f59c6553b06a540b05d248b43865ec9da0e1a0a94191ced5b
MS-MPPE-Send-Key =
0x62a6b9ec702b2819c7d80448239213ea432ee86d9d2ad084cc775bcc3724fe42
EAP-Message = 0x030a0004
Message-Authenticator = 0x
Finished request 10.
Going to the next request
Waking up in 4.6 seconds.
users file:
DEFAULT Auth-Type = Accept
Tunnel-type = VLAN,
Tunnel-Medium-Type = IEEE-802
exec file:
exec {
wait = yes
input-pairs = request
shell-escape = yes
output = reply
}
exec get-vlan{
wait = yes
program = "/usr/local/etc/raddb/scripts/getvlan.php %{mschap:User-Name}"
input-pairs = request
output = reply
}
@inner-tunnel file:
post-auth{
#exec# if remove comment nothing change
get-vlan
}
Why not send the Tunnel-Private-Group-Id in tunneled, accept packet?
here is the another settings which is works: (get-vlan is not used)
debug log:
[files] users: Matched entry DEFAULT at line 90
[files] expand: /usr/local/etc/raddb/scripts/getvlan.php %{mschap:User-Name}
-> /usr/local/etc/raddb/scripts/getvlan.php Hege
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
++[pap] returns noop
Found Auth-Type = EAP
+- entering group authenticate {...}
[eap] Request found, released from the list
[eap] EAP/mschapv2
[eap] processing type mschapv2
[eap] Freeing handler
++[eap] returns ok
+- entering group p
Re: Restricting dialup users to certain client definitions only
>Can't post now but, yes I do see the groups table being queried Is there something else in the group entry that doesn't match? Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Status counters
Anders Holm wrote: > Looking a tad at the counters and how they get incremented I see the > following: > > Sending Access-Accept of id 20 to 127.0.0.1 port 32772 > FreeRADIUS-Total-Access-Requests = 0 > FreeRADIUS-Total-Access-Accepts = 36 > FreeRADIUS-Total-Access-Rejects = 0 > FreeRADIUS-Total-Access-Challenges = 0 > FreeRADIUS-Total-Auth-Responses = 36 > > This is on a test server, which currently is only getting requests for > status. Shouldn't the Access-Requests also be incremented? No. The counter tracks Access-Requests, not Status-Server packets. > I mean, if > the Access-Accept is incremented, we must have had a request to being with. No. The response to a Status-Server is an Access-Accept. > Also, using these counters for monitoring, it would be nice to see > deltas from the previous Status request. Though, if I would go ahead and > clear the counters (haven't even checked if it is possible tbh) I might > have requests arriving between my last Status request packet and my > clearing the counter, meaning my metrics would be incorrect. Would it be > trivial to add some form of delta-since-last-status-request, or is it > preferred to keep that in an external script? It would be extremely difficult. *Who* asked for those statistics last? Is the "last statistics" item tracked by client IP? Client port? Anything else...? > Just trying to figure out which would be the best route, and what others > think of the idea. Might be useful for others here, so ... If you need deltas, track them yourself in the client app. It's the only way to get them right. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: libradiusclient 64-bit
J Santos wrote: > does anybody know where can I find the libradiusclient 64-bit ? The freeradius-client code is 64-bit clean. If you are looking for a binary package, there is none. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Why the DEFAULT everywhere?
Todd R. wrote: > Can someone explain to me why it always seems that the word DEFAULT is > before many lines or rules etc. within all the FR configs? Look for the word "DEFAULT" in the "users" file and in the "proxy.conf" file. This is explained. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: external script reply
t...@kalik.net írta:
What have to change, cos the Group-Id is not sent.
Can you post the configuration of exec module that calls you script.
There should be output = reply in it.
Ivan Kalik
Kalik Informatika ISP
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi here is the config and debug:
php script:(this is the only output)
echo "Tunnel-Private-Group-Id = ".$tunelPrivGrId."\n";
exec file:
exec {
wait = yes
input-pairs = request
shell-escape = yes
output = reply
}
exec get-vlan{
wait = yes
program = "/usr/local/etc/raddb/scripts/getvlan.php %{mschap:User-Name}"
input-pairs = request
output = reply
packet-type = Access-Accept
shell-escape = yes
}
debug:
+- entering group post-auth {...}
[get-vlan] expand: %{mschap:User-Name} -> Hege
Exec-Program output: Tunnel-Private-Group-Id = vlan20
Exec-Program-Wait: value-pairs: Tunnel-Private-Group-Id = vlan20
Exec-Program: returned: 0
++[get-vlan] returns ok
} # server inner-tunnel
[peap] Got tunneled reply code 2
EAP-Message = 0x03090004
Message-Authenticator = 0x
User-Name = "TEST\\Hege"
[peap] Got tunneled reply RADIUS code 2
EAP-Message = 0x03090004
Message-Authenticator = 0x
User-Name = "TEST\\Hege"
[peap] Tunneled authentication was successful.
[peap] SUCCESS
thank you, Gabor
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
