Re: Response-Packet-Type == Access-Challenge
On 08/06/2013 05:29 PM, Alan DeKok wrote:
Dominique Frise wrote:
Is there any other flag/function that would indicate that an
Access-Challenge packet was received from the NAS?
A NAS will NEVER send an Access-Challenge to the server.
A proxy will receive an Access-Challenge from a home server. As was
said, you need the latest code from the GIT to use that feature.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Did a fresh install from
http://github.com/FreeRADIUS/freeradius-server/tree/v2.x.x
./radiusd -v
radiusd: FreeRADIUS Version 2.2.1 (git #12be9f6), for host
x86_64-unknown-linux-gnu, built on Aug 6 2013 at 21:51:33
Copyright (C) 1999-2013 The FreeRADIUS server project and contributors.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
You may redistribute copies of FreeRADIUS under the terms of the
GNU General Public License.
For more information about these matters, see the file named COPYRIGHT.
But still no luck :-(
-
rad_recv: Access-Challenge packet from host X.X.X.X port 1812, id=101,
length=49
Reply-Message = Enter OTP:
State = 0x38373131
Prompt = No-Echo
Proxy-State = 0x313039
# Executing section post-proxy from file
/usr/local/etc/raddb/sites-enabled/default
+- entering group post-proxy {...}
[eap] No pre-existing handler found
++[eap] returns noop
++? if (Response-Packet-Type == Access-Challenge)
? Evaluating (Response-Packet-Type == Access-Challenge) - FALSE
--
Any other idea?
Dominique
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Response-Packet-Type == Access-Challenge
On 7 Aug 2013, at 07:51, Dominique Frise dominique.fr...@unil.ch wrote:
On 08/06/2013 05:29 PM, Alan DeKok wrote:
Dominique Frise wrote:
Is there any other flag/function that would indicate that an
Access-Challenge packet was received from the NAS?
A NAS will NEVER send an Access-Challenge to the server.
A proxy will receive an Access-Challenge from a home server. As was
said, you need the latest code from the GIT to use that feature.
Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
Did a fresh install from
http://github.com/FreeRADIUS/freeradius-server/tree/v2.x.x
./radiusd -v
radiusd: FreeRADIUS Version 2.2.1 (git #12be9f6), for host
x86_64-unknown-linux-gnu, built on Aug 6 2013 at 21:51:33
Copyright (C) 1999-2013 The FreeRADIUS server project and contributors.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
You may redistribute copies of FreeRADIUS under the terms of the
GNU General Public License.
For more information about these matters, see the file named COPYRIGHT.
But still no luck :-(
-
rad_recv: Access-Challenge packet from host X.X.X.X port 1812, id=101,
length=49
Reply-Message = Enter OTP:
State = 0x38373131
Prompt = No-Echo
Proxy-State = 0x313039
# Executing section post-proxy from file
/usr/local/etc/raddb/sites-enabled/default
+- entering group post-proxy {...}
[eap] No pre-existing handler found
++[eap] returns noop
++? if (Response-Packet-Type == Access-Challenge)
? Evaluating (Response-Packet-Type == Access-Challenge) - FALSE
--
Hmm ok. I thought this was fixed at the same time we allowed modification of
Response-Packet-Type. I'll have a look at it.
Arran Cudbard-Bell a.cudba...@freeradius.org
FreeRADIUS Development Team
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Response-Packet-Type == Access-Challenge
On 07.08.2013 08:51, Dominique Frise wrote:
Did a fresh install from
http://github.com/FreeRADIUS/freeradius-server/tree/v2.x.x
./radiusd -v
radiusd: FreeRADIUS Version 2.2.1 (git #12be9f6), for host
x86_64-unknown-linux-gnu, built on Aug 6 2013 at 21:51:33
Copyright (C) 1999-2013 The FreeRADIUS server project and contributors.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
You may redistribute copies of FreeRADIUS under the terms of the
GNU General Public License.
For more information about these matters, see the file named COPYRIGHT.
But still no luck :-(
-
rad_recv: Access-Challenge packet from host X.X.X.X port 1812, id=101,
length=49
Reply-Message = Enter OTP:
State = 0x38373131
Prompt = No-Echo
Proxy-State = 0x313039
# Executing section post-proxy from file
/usr/local/etc/raddb/sites-enabled/default
+- entering group post-proxy {...}
[eap] No pre-existing handler found
++[eap] returns noop
++? if (Response-Packet-Type == Access-Challenge)
? Evaluating (Response-Packet-Type == Access-Challenge) - FALSE
--
I made myself a test with the latest git HEAD (3.0) and indeed, this
also doesn't work. I'll have a look at it and see why it doesn't call
the paircmp callback.
Olivier
--
Olivier Beytrison
Network Security Engineer, HES-SO Fribourg
Mail: oliv...@heliosnet.org
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Response-Packet-Type == Access-Challenge
On 7 Aug 2013, at 09:35, Olivier Beytrison oliv...@heliosnet.org wrote:
On 07.08.2013 08:51, Dominique Frise wrote:
Did a fresh install from
http://github.com/FreeRADIUS/freeradius-server/tree/v2.x.x
./radiusd -v
radiusd: FreeRADIUS Version 2.2.1 (git #12be9f6), for host
x86_64-unknown-linux-gnu, built on Aug 6 2013 at 21:51:33
Copyright (C) 1999-2013 The FreeRADIUS server project and contributors.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
You may redistribute copies of FreeRADIUS under the terms of the
GNU General Public License.
For more information about these matters, see the file named COPYRIGHT.
But still no luck :-(
-
rad_recv: Access-Challenge packet from host X.X.X.X port 1812, id=101,
length=49
Reply-Message = Enter OTP:
State = 0x38373131
Prompt = No-Echo
Proxy-State = 0x313039
# Executing section post-proxy from file
/usr/local/etc/raddb/sites-enabled/default
+- entering group post-proxy {...}
[eap] No pre-existing handler found
++[eap] returns noop
++? if (Response-Packet-Type == Access-Challenge)
? Evaluating (Response-Packet-Type == Access-Challenge) - FALSE
--
I made myself a test with the latest git HEAD (3.0) and indeed, this
also doesn't work. I'll have a look at it and see why it doesn't call
the paircmp callback.
Because pair comparisons don't work in evaluated conditions currently.
Arran Cudbard-Bell a.cudba...@freeradius.org
FreeRADIUS Development Team
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: returning a HEX String as a HEX String (bit string) instead of the decimal equivalent - FreeRADIUS 2.1.10
Works here just fine. Once you've created the correctly formatted value for the radius attribute FR displays it as an integer but whatever happens in the background the HP switch just does its stuff Rgds A Sent from my iPhone On 6 Aug 2013, at 00:39, Andy a...@brandwatch.com wrote: Hello, This is my first post here so please excuse any missed etiquette. I have read through the wiki's and googled a lot and not found anything. I have been trying configure our switch ports (HP 2910al) with Tagged VLANs via Egress-VLANID and Egress-VLAN-Name. The Radius backend is OpenLDAP, and I have tried setting the data type in OpenLDAP to binary, UTF-8 and IA5, but no matter what I do, the value returned by RADIUS is the decimal equivalent of the HEX bit string I enter :( For example I'm trying to store and send 0x3112 to indicate a tagged VLAN (0x31) on VLAN 12. But looking at freeradius -X output I can see it sending the decimal number, when the switch wants the bit string as it was stored, and hence throws an error! Is this a FreeRADIUS thing or an OpenLDAP data type thing? Any help and advice would be greatly appreciated as I'm stuck. Thanks in advance, Andy. - 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: returning a HEX String as a HEX String (bit string) instead of the decimal equivalent - FreeRADIUS 2.1.10
On 7 Aug 2013, at 10:56, Alex Sharaz alex.sha...@york.ac.uk wrote: Works here just fine. Once you've created the correctly formatted value for the radius attribute FR displays it as an integer but whatever happens in the background the HP switch just does its stuff Yes the HP switch correctly parses the 4byte octet string sent by the RADIUS server. There's no magic here, the RADIUS server does not communicate to the NAS that the value was once treated as an integer. I've already sent you a screenshot of the raw value off list, I'm not sure what else I can do to convince you that this is expected and non-magical behaviour. I'm honestly not entirely sure why the freeradius dictionary has the attribute as an unsigned int. Possibly for efficiency or for use with systems that already deal with VLAN IDs as native width integers (almost all interpreted languages use integers of a width = 32bits by default). Rgds A Sent from my iPhone On 6 Aug 2013, at 00:39, Andy a...@brandwatch.com wrote: Hello, This is my first post here so please excuse any missed etiquette. I have read through the wiki's and googled a lot and not found anything. I have been trying configure our switch ports (HP 2910al) with Tagged VLANs via Egress-VLANID and Egress-VLAN-Name. The Radius backend is OpenLDAP, and I have tried setting the data type in OpenLDAP to binary, UTF-8 and IA5, but no matter what I do, the value returned by RADIUS is the decimal equivalent of the HEX bit string I enter :( For example I'm trying to store and send 0x3112 to indicate a tagged VLAN (0x31) on VLAN 12. But looking at freeradius -X output I can see it sending the decimal number, when the switch wants the bit string as it was stored, and hence throws an error! Is this a FreeRADIUS thing or an OpenLDAP data type thing? Any help and advice would be greatly appreciated as I'm stuck. Thanks in advance, Andy. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - 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: returning a HEX String as a HEX String (bit string) instead of the decimal equivalent - FreeRADIUS 2.1.10
Arran Cudbard-Bell wrote: I'm honestly not entirely sure why the freeradius dictionary has the attribute as an unsigned int That's what the RFCs say. And the server doesn't really have a way of packing arbitrary structures from attributes. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: returning a HEX String as a HEX String (bit string) instead of the decimal equivalent - FreeRADIUS 2.1.10
On 7 Aug 2013, at 13:46, Alan DeKok al...@deployingradius.com wrote:
Arran Cudbard-Bell wrote:
I'm honestly not entirely sure why the freeradius dictionary has the
attribute as an unsigned int
That's what the RFCs say. And the server doesn't really have a way of
packing arbitrary structures from attributes.
It says the value is 4 octets. That's not quite saying it's an integer, was
there a later one?
I think it's arguably more useful as an integer though, for the reasons listed
previously, and because
you can use expr to build the bit string easily.
For example:
update reply {
Egress-VLANID += %{expr:822083584 + %{Tagged-VID}}
}
With hex you need to manually pad the VID out to 12 bits.
Arran Cudbard-Bell a.cudba...@freeradius.org
FreeRADIUS Development Team
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: returning a HEX String as a HEX String (bit string) instead ofthe decimal equivalent - FreeRADIUS 2.1.10
Hi,
Just agreeing with Arran really, we've got 5406 procurve switches,
which I believe are similar in software terms to the 2910s and we do the
unlang string Arran has presented here :
update reply {
Egress-VLANID += %{expr:822083584 + %{Tagged-VID}}
}
It works fine, although that may not help you too much. I had some 2910s
around here somewhere, maybe I'll test one..
Thanks
Andy
-Original Message-
From:
freeradius-users-bounces+andy.franks=sath.nhs...@lists.freeradius.org
[mailto:freeradius-users-bounces+andy.franks=sath.nhs.uk@lists.freeradiu
s.org] On Behalf Of Arran Cudbard-Bell
Sent: 07 August 2013 14:06
To: FreeRadius users mailing list
Subject: Re: returning a HEX String as a HEX String (bit string) instead
ofthe decimal equivalent - FreeRADIUS 2.1.10
On 7 Aug 2013, at 13:46, Alan DeKok al...@deployingradius.com wrote:
Arran Cudbard-Bell wrote:
I'm honestly not entirely sure why the freeradius dictionary has the
attribute as an unsigned int
That's what the RFCs say. And the server doesn't really have a way
of packing arbitrary structures from attributes.
It says the value is 4 octets. That's not quite saying it's an integer,
was there a later one?
I think it's arguably more useful as an integer though, for the reasons
listed previously, and because you can use expr to build the bit string
easily.
For example:
update reply {
Egress-VLANID += %{expr:822083584 + %{Tagged-VID}}
}
With hex you need to manually pad the VID out to 12 bits.
Arran Cudbard-Bell a.cudba...@freeradius.org FreeRADIUS Development
Team
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Talloc sanity error (3.0 release branch, reproxying from PEAP inner tunnel)
I finally got around to trying some RC code (the release_branch_3.0.0 on
github) on our
production configurations, after a bit of massaging got them looking like they
were working,
but not so much the one that re-proxies the inner tunnel contents to an internal
server after unwrapping EAP-PEAP:
peap {
default_eap_type = mschapv2
proxy_tunneled_request_as_eap = yes
copy_request_to_tunnel = no
use_tunneled_reply = yes
tls = eduroam-eap-tls
}
Any request that tries to go to the proxy causes this to happen:
Wed Aug 7 11:57:35 2013 : Debug: (5) - entering if
(%{FreeRADIUS-Proxied-To} == 127.0.0.1) {...}
Wed Aug 7 11:57:35 2013 : Debug: (5)update control {
Wed Aug 7 11:57:35 2013 : Debug: (5) Proxy-To-Realm := idpi
...
Wed Aug 7 11:57:35 2013 : Debug: (5)} # update control = ok
Wed Aug 7 11:57:35 2013 : Debug: (5) - if (%{FreeRADIUS-Proxied-To} ==
127.0.0.1) returns ok
Wed Aug 7 11:57:35 2013 : Debug: (5)... skipping else for request 5:
Preceding if was taken
} # server eduroam_idp
Wed Aug 7 11:57:35 2013 : Debug: (5) eap_peap : Got tunneled reply code 0
Wed Aug 7 11:57:35 2013 : Debug: PEAP: Tunneled authentication will be
proxied to idpi
Wed Aug 7 11:57:35 2013 : Info: talloc: access after free error - first free
may be at src/main/util.c:230
Wed Aug 7 11:57:35 2013 : Info: Bad talloc magic value - access after free
... I don't know if this is of any use, being so far removed from the free():
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x75eb4700 (LWP 27579)]
0x003fe54328a5 in raise () from /lib64/libc.so.6
...
(gdb) bt
#0 0x003fe54328a5 in raise () from /lib64/libc.so.6
#1 0x003fe5434085 in abort () from /lib64/libc.so.6
#2 0x77782c3c in ?? () from /usr/lib64/libtalloc.so.2
#3 0x77782dd8 in talloc_get_name () from /usr/lib64/libtalloc.so.2
#4 0x777857eb in _talloc_get_type_abort ()
from /usr/lib64/libtalloc.so.2
#5 0x77bb4d95 in pairnext (cursor=0x75eb2950)
at src/lib/valuepair.c:290
#6 0x77bb4b42 in pairfind (vp=0x7fffe8007d80, attr=80, vendor=0,
tag=-128 '\200') at src/lib/valuepair.c:209
#7 0x76f58d45 in mod_authenticate (instance=0x7f8b30,
request=0x844e40) at src/modules/rlm_eap/rlm_eap.c:360
#8 0x00421812 in call_modsingle (component=0, sp=0x81ce30,
request=0x844e40) at src/main/modcall.c:311
#9 0x00422f93 in modcall (component=0, c=0x81cf30, request=0x844e40)
at src/main/modcall.c:782
#10 0x0041f4c6 in indexed_modcall (comp=0, idx=6, request=0x844e40)
at src/main/modules.c:758
#11 0x00421127 in process_authenticate (auth_type=6, request=0x844e40)
at src/main/modules.c:1648
#12 0x0040c910 in rad_check_password (request=0x844e40)
at src/main/auth.c:252
#13 0x0040cee4 in rad_authenticate (request=0x844e40)
---Type return to continue, or q return to quit---
at src/main/auth.c:490
#14 0x00430b79 in request_running (request=0x844e40, action=1)
at src/main/process.c:1185
#15 0x0042d02e in request_handler_thread (arg=0x8397c0)
at src/main/threads.c:685
#16 0x003fe5c07851 in start_thread () from /lib64/libpthread.so.0
#17 0x003fe54e811d in clone () from /lib64/libc.so.6
(gdb)
(gdb) up
#1 0x003fe5434085 in abort () from /lib64/libc.so.6
(gdb) up
#2 0x77782c3c in ?? () from /usr/lib64/libtalloc.so.2
(gdb) up
#3 0x77782dd8 in talloc_get_name () from /usr/lib64/libtalloc.so.2
(gdb) up
#4 0x777857eb in _talloc_get_type_abort ()
from /usr/lib64/libtalloc.so.2
(gdb) up
#5 0x77bb4d95 in pairnext (cursor=0x75eb2950)
at src/lib/valuepair.c:290
290 VERIFY_VP(cursor-current);
(gdb) list
285*/
286VALUE_PAIR *pairnext(vp_cursor_t *cursor)
287{
288 cursor-current = cursor-next;
289 if (cursor-current) {
290 VERIFY_VP(cursor-current);
291
292 /*
293 * Set this now in case 'current' gets freed before
294 * pairnext is called again.
(gdb) print cursor-current
$1 = (VALUE_PAIR *) 0x7fffe8007820
(gdb) print cursor-current-da
$2 = (const DICT_ATTR *) 0x6c6c617420646142
(gdb) print *cursor-current-da
Cannot access memory at address 0x6c6c617420646142
(gdb) up
#6 0x77bb4b42 in pairfind (vp=0x7fffe8007d80, attr=80, vendor=0,
tag=-128 '\200') at src/lib/valuepair.c:209
209 i = pairnext(cursor)) {
(gdb) list
204 vp_cursor_t cursor;
205 VALUE_PAIR *i;
206
207 for (i = paircursor(cursor, vp);
208 i;
209 i = pairnext(cursor)) {
210 VERIFY_VP(i);
211 if ((i-da-attr == attr) (i-da-vendor == vendor)
212 ((tag == TAG_ANY) || (i-da-flags.has_tag
213 (i-tag == tag {
(gdb) print attr
$3 = 80
(gdb) print vendor
$4 = 0
(gdb) print tag
$5 = -128 '\200'
(gdb)
Re: returning a HEX String as a HEX String (bit string) instead of the decimal equivalent - FreeRADIUS 2.1.10
Thank you everyone so much :)
Wow, what a great list :D
OK. First, you're not doing PPP, remove the default entries in the
users file for Framed-Protocol and Framed-Compression.
I have commented this out now.
And again thank you for your wireshark capture, and perfect
explanations of the expected data type. I never doubted your
credentials or the value of your suggestions ;)
I just got myself into a mess with it, BUT, its working now :)
NB; your extremely well written website says RFC 4765 isn't in the W
branch. I'm running the W branch and its working;
brdswitch02(config)# 0050:11:24:55.01 MAC mWebAuth:Port: 29 MAC:
080027-e4b2cd new client detected
on vid: 1.
0050:11:24:55.01 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd RADIUS CHAP
authentication started, session: 3055.
0050:11:24:55.02 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd RADIUS
Attributes,
priority: , tagged vid: 12.
0050:11:24:55.02 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd client
accepted,
session: 3055.
0050:11:24:55.02 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd client
successfully
placed into vid: 0.
The last message about being placed into vid: 0 is strange, but after
running 'show vlans 12', I now see;
Port Information Mode Unknown VLAN Status
--
1No LearnUp
2No LearnUp
5No LearnUp
6No LearnUp
7No LearnUp
8No LearnUp
20 No LearnUp
22 No LearnUp
29 MACAUTH LearnUp
41 No LearnUp
43 No LearnUp
A1 Tagged LearnUp
NB; the mac was on port 29.
Just need to now test that the MAC on tagged 12 can communicate, AND,
the untagged MAC on the same port can also communicate still on VLAN 1.
Thank you again for your help :)
PS; And sorry again for my initial fast reply. It annoys me when people
*sigh* and point you to a page you've already read every word of very
closely.. We're not all lazy ;)
Andy
On Wed 07 Aug 2013 11:21:21 BST, Arran Cudbard-Bell wrote:
On 7 Aug 2013, at 10:56, Alex Sharaz alex.sha...@york.ac.uk wrote:
Works here just fine. Once you've created the correctly formatted value for the radius
attribute FR displays it as an integer but whatever happens in the background the HP
switch just does its stuff
Yes the HP switch correctly parses the 4byte octet string sent by the RADIUS
server. There's no magic here, the RADIUS server does not communicate to the
NAS that the value was once treated as an integer.
I've already sent you a screenshot of the raw value off list, I'm not sure what
else I can do to convince you that this is expected and non-magical behaviour.
I'm honestly not entirely sure why the freeradius dictionary has the attribute as
an unsigned int. Possibly for efficiency or for use with systems that already deal
with VLAN IDs as native width integers (almost all interpreted languages use
integers of a width = 32bits by default).
Rgds
A
Sent from my iPhone
On 6 Aug 2013, at 00:39, Andy a...@brandwatch.com wrote:
Hello,
This is my first post here so please excuse any missed etiquette.
I have read through the wiki's and googled a lot and not found anything.
I have been trying configure our switch ports (HP 2910al) with Tagged VLANs via
Egress-VLANID and Egress-VLAN-Name.
The Radius backend is OpenLDAP, and I have tried setting the data type in
OpenLDAP to binary, UTF-8 and IA5, but no matter what I do, the value returned
by RADIUS is the decimal equivalent of the HEX bit string I enter :(
For example I'm trying to store and send 0x3112 to indicate a tagged VLAN
(0x31) on VLAN 12. But looking at freeradius -X output I can see it sending the
decimal number, when the switch wants the bit string as it was stored, and
hence throws an error!
Is this a FreeRADIUS thing or an OpenLDAP data type thing?
Any help and advice would be greatly appreciated as I'm stuck.
Thanks in advance, Andy.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
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: Talloc sanity error (3.0 release branch, reproxying from PEAP inner tunnel)
Hi,
peap {
default_eap_type = mschapv2
proxy_tunneled_request_as_eap = yes
copy_request_to_tunnel = no
use_tunneled_reply = yes
tls = eduroam-eap-tls
}
okay
Any request that tries to go to the proxy causes this to happen:
Wed Aug 7 11:57:35 2013 : Debug: (5) - entering if
(%{FreeRADIUS-Proxied-To} == 127.0.0.1) {...}
Wed Aug 7 11:57:35 2013 : Debug: (5)update control {
Wed Aug 7 11:57:35 2013 : Debug: (5) Proxy-To-Realm := idpi
Wed Aug 7 11:57:35 2013 : Debug: (5)} # update control = ok
Wed Aug 7 11:57:35 2013 : Debug: (5) - if (%{FreeRADIUS-Proxied-To} ==
127.0.0.1) returns ok
Wed Aug 7 11:57:35 2013 : Debug: (5)... skipping else for request 5:
Preceding if was taken
} # server eduroam_idp
Wed Aug 7 11:57:35 2013 : Debug: (5) eap_peap : Got tunneled reply code 0
Wed Aug 7 11:57:35 2013 : Debug: PEAP: Tunneled authentication will be
proxied to idpi
Wed Aug 7 11:57:35 2013 : Info: talloc: access after free error - first
free may be at src/main/util.c:230
Wed Aug 7 11:57:35 2013 : Info: Bad talloc magic value - access after free
this sample doesnt show enough of the process..
how did you configure the server...from scratch or copy pasting bits over from
a 2.x ?
does this 'eap' module use its own virtual_server or does it inherit the
virtual_server that
instigated it (you have no 'virtual_server = blah' line in your peap{}
section...so i assume
its using eduroam_idp VS for the unwrapping?)
alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Talloc sanity error (3.0 release branch, reproxying from PEAP inner tunnel)
a.l.m.bu...@lboro.ac.uk [a.l.m.bu...@lboro.ac.uk] wrote:
how did you configure the server...from scratch or copy pasting bits over
from a 2.x ?
It's a mongrel, not an alteration of fresh 3.0. It was working on a pre-talloc
3.0 development branch.
does this 'eap' module use its own virtual_server or does it inherit the
virtual_server that
instigated it (you have no 'virtual_server = blah' line in your peap{}
section...so i assume
its using eduroam_idp VS for the unwrapping?)
There's only one incestuous server clause, and only one EAP configuration
block, yes.
I tried to replicate on a test server with lightly modified 3.0 stock configs.
The error only
happens when everything is running through the same server/eap instances, so
good
instincts there. Replicating it is easy: just uncomment the peap
virtual-server directive
and add at the top of authorize:
if (Freeradius-Proxied-To == 127.0.0.1) {
update control {
Proxy-To-Realm = example.com
}
}
...and it doesn't matter that example.com defaults to home_server localhost, it
does not get that far.
I believe it is the way it is because at some point we were having trouble
using outer.request
and such between virtual servers. I'll have to test those and see if that
limitation is still
in effect.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
