Error: ERROR: Tunnel-Password attribute in request: Cannot decrypt it.
Hi We are seeing a problem with RADIUS accounting from some of our Colubris AP's. We are getting the following errors in /var/log/radius/radius.log :- Tue Oct 24 14:02:59 2006 : Error: ERROR: Tunnel-Password attribute in request: Cannot decrypt it. Could someone explain a bit more about what this means and whether it is likely to be a problem with the NAS? We are running FreeRADIUS 1.0.1. Here is the tcpdump print out of the packet which caused the above message :- 14:02:59.913634 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto 17, length: 323) nasphysap0.york.ac.uk.32770 > nasaaa2.york.ac.uk.radius-acct: [udp sum ok] RADIUS, length: 295 Accounting Request (4), id: 0xa7, Authenticator: 7f79db43885d7e9745205662885af3bc Accounting Session ID Attribute (44), length: 19, Value: 94c34058-00000007 0x0000: 3934 6333 3430 3538 2d30 3030 3030 3030 0x0010: 37 NAS Port Attribute (5), length: 6, Value: 10 0x0000: 0000 000a NAS Port Type Attribute (61), length: 6, Value: Wireless - IEEE 802.11 0x0000: 0000 0013 NAS ID Attribute (32), length: 12, Value: nasphysap0 0x0000: 6e61 7370 6879 7361 7030 NAS IP Address Attribute (4), length: 6, Value: nasphysap0.york.ac.uk 0x0000: 9020 c4b8 Framed MTU Attribute (12), length: 6, Value: 1496 0x0000: 0000 05d8 Username Attribute (1), length: 18, Value: xy506@york.ac.uk 0x0000: 7879 3530 3640 796f 726b 2e61 632e 756b Calling Station Attribute (31), length: 19, Value: 00:0c:f1:1b:47:7b 0x0000: 3030 3a30 633a 6631 3a31 623a 3437 3a37 0x0010: 62 Called Station Attribute (30), length: 19, Value: 00:03:52:dc:e5:31 0x0000: 3030 3a30 333a 3532 3a64 633a 6535 3a33 0x0010: 31 Accounting Status Attribute (40), length: 6, Value: Stop 0x0000: 0000 0002 Accounting Session Time Attribute (46), length: 6, Value: 18 secs 0x0000: 0000 0012 Accounting Input Packets Attribute (47), length: 6, Value: 30 0x0000: 0000 001e Accounting Output Packets Attribute (48), length: 6, Value: 34 0x0000: 0000 0022 Accounting Input Octets Attribute (42), length: 6, Value: 2181 0x0000: 0000 0885 Accounting Output Octets Attribute (43), length: 6, Value: 7541 0x0000: 0000 1d75 Accounting Termination Cause Attribute (49), length: 6, Value: Lost Carrier 0x0000: 0000 0002 Accounting Delay Attribute (41), length: 6, Value: 289:15:29 hours 0x0000: 000f e3b1 Vendor Specific Attribute (26), length: 58, Value: Vendor: Microsoft (311) Vendor Attribute: 17, Length: 52, Value: .]......D?...D7.?}v.X.x....S.)/..7.).Z. .SiG...: 0x0000: 0000 0137 1134 945d bea2 85ee bfde 443f 0x0010: e6c6 d544 37a6 3f7d 7608 58f1 78cb cca7 0x0020: fd53 0429 2fd8 0437 c529 845a ae20 c653 0x0030: 077f 6947 e27f e8c1 Vendor Specific Attribute (26), length: 58, Value: Vendor: Microsoft (311) 0x0000: 0000 0137 1034 9f5b 63ae ecb4 7e23 af47 0x0010: 7be9 c08b 5cbd b35f 7f8d 9b11 1a08 a52f 0x0020: b52c 09c5 f5ca 5e2c 8d53 8390 0d8f 24fb 0x0030: 3e39 1668 6858 af32 0x0000: 0030 4883 9880 0003 5204 635a 0800 4500 .0H.....R.cZ..E. 0x0010: 0143 0000 4000 4011 8fb5 9020 c4b8 9020 .C..@.@......... 0x0020: c4fb 8002 0715 012f 922a 04a7 0127 7f79 ......./.*...'.y 0x0030: db43 885d 7e97 4520 5662 885a f3bc 2c13 .C.]~.E.Vb.Z..,. 0x0040: 3934 6333 3430 3538 2d30 3030 3030 3030 94c34058-0000000 0x0050: 3705 0600 0000 0a3d 0600 0000 1320 0c6e 7......=.......n 0x0060: 6173 7068 7973 6170 3004 0690 20c4 b80c asphysap0....... 0x0070: 0600 0005 d801 1278 7935 3036 4079 6f72 .......xy506@yor 0x0080: 6b2e 6163 2e75 6b1f 1330 303a 3063 3a66 k.ac.uk..00:0c:f 0x0090: 313a 3162 3a34 373a 3762 1e13 3030 3a30 1:1b:47:7b..00:0 0x00a0: 333a 3532 3a64 633a 6535 3a33 3128 0600 3:52:dc:e5:31(.. 0x00b0: 0000 022e 0600 0000 122f 0600 0000 1e30 ........./.....0 0x00c0: 0600 0000 222a 0600 0008 852b 0600 001d ...."*.....+.... 0x00d0: 7531 0600 0000 0229 0600 0fe3 b11a 3a00 u1.....)......:. 0x00e0: 0001 3711 3494 5dbe a285 eebf de44 3fe6 ..7.4.]......D?. 0x00f0: c6d5 4437 a63f 7d76 0858 f178 cbcc a7fd ..D7.?}v.X.x.... 0x0100: 5304 292f d804 37c5 2984 5aae 20c6 5307 S.)/..7.).Z...S. 0x0110: 7f69 47e2 7fe8 c11a 3a00 0001 3710 349f .iG.....:...7.4. 0x0120: 5b63 aeec b47e 23af 477b e9c0 8b5c bdb3 [c...~#.G{...\.. 0x0130: 5f7f 8d9b 111a 08a5 2fb5 2c09 c5f5 ca5e _......./.,....^ 0x0140: 2c8d 5383 900d 8f24 fb3e 3916 6868 58af ,.S....$.>9.hhX. 0x0150: 32 -- Many Thanks Ben Thompson
B Thompson <bt4@york.ac.uk> wrote:
Tue Oct 24 14:02:59 2006 : Error: ERROR: Tunnel-Password attribute in request: Cannot decrypt it.
Could someone explain a bit more about what this means and whether it is likely to be a problem with the NAS?
The NAS is sending an attribute it's not supposed to send. Yes, it would appear to be a problem.
Here is the tcpdump print out of the packet which caused the above message :-
Nope. Look at what you posted: there's no Tunnel-Password in it. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Tue, Oct 24, 2006 at 01:19:29PM -0400, Alan DeKok wrote:
B Thompson <bt4@york.ac.uk> wrote:
Tue Oct 24 14:02:59 2006 : Error: ERROR: Tunnel-Password attribute in request: Cannot decrypt it.
Could someone explain a bit more about what this means and whether it is likely to be a problem with the NAS?
The NAS is sending an attribute it's not supposed to send. Yes, it would appear to be a problem.
Here is the tcpdump print out of the packet which caused the above message :-
Nope. Look at what you posted: there's no Tunnel-Password in it.
Looking at the timestamps it would seem that this is the packet which caused the error even though tcpdump shows no Tunnel-Password attribute was present. So, something is definitely odd here. Is there any way to verify this is the offending packet other than matching timestamps? Thanks -- Ben Thompson
B Thompson <bt4@york.ac.uk> wrote:
Looking at the timestamps it would seem that this is the packet which caused the error even though tcpdump shows no Tunnel-Password attribute was present. So, something is definitely odd here. Is there any way to verify this is the offending packet other than matching timestamps?
Run the server in debugging mode? Run tcpdump for a long time, and search it's output for Tunnel-Password? The server will get many packets in the same second. Timestamps are useless... Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Tue, Oct 24, 2006 at 07:58:17PM -0400, Alan DeKok wrote:
B Thompson <bt4@york.ac.uk> wrote:
Looking at the timestamps it would seem that this is the packet which caused the error even though tcpdump shows no Tunnel-Password attribute was present. So, something is definitely odd here. Is there any way to verify this is the offending packet other than matching timestamps?
Run the server in debugging mode? Run tcpdump for a long time, and search it's output for Tunnel-Password?
The server will get many packets in the same second. Timestamps are useless...
OK. I have done all these things and I still get the same result: the packet causing the error does not contain the Tunnel-Password attribute. I have upgraded to 1.1.3 and the error message has gone away so that seems to suggest that there is a problem or at least something different going on with 1.0.1? I cannot continue to use 1.1.3 as we are regularly using HUP to re-read the configs and there appears to be a problem with this in versions > 1.0.1. -- Ben Thompson
B Thompson wrote:
I cannot continue to use 1.1.3 as we are regularly using HUP to re-read the configs and there appears to be a problem with this in versions > 1.0.1.
Yes, there does. I haven't had time to gather the relevant debugging info (we just restart instead of HUP the server as a workaround) but we have several processes running on the same box. Some crash on hup, some don't. Those that do are the ones with the eap/peap modules enabled, so I am thinking it might be SSL related. What platform are you running on? We're on RHEL4, OpenSSL 0.9.7a, FreeRadius 1.1.3 I'll look into gathering crash info
On Wed, Oct 25, 2006 at 10:57:55AM +0100, Phil Mayers wrote:
B Thompson wrote:
I cannot continue to use 1.1.3 as we are regularly using HUP to re-read the configs and there appears to be a problem with this in versions > 1.0.1.
Yes, there does.
I haven't had time to gather the relevant debugging info (we just restart instead of HUP the server as a workaround) but we have several processes running on the same box. Some crash on hup, some don't. Those that do are the ones with the eap/peap modules enabled, so I am thinking it might be SSL related.
What platform are you running on? We're on RHEL4, OpenSSL 0.9.7a, FreeRadius 1.1.3
Yes, Same here. -- Ben Thompson
B Thompson wrote:
On Wed, Oct 25, 2006 at 10:57:55AM +0100, Phil Mayers wrote:
B Thompson wrote:
I cannot continue to use 1.1.3 as we are regularly using HUP to re-read the configs and there appears to be a problem with this in versions > 1.0.1.
Yes, there does.
I haven't had time to gather the relevant debugging info (we just restart instead of HUP the server as a workaround) but we have several processes running on the same box. Some crash on hup, some don't. Those that do are the ones with the eap/peap modules enabled, so I am thinking it might be SSL related.
What platform are you running on? We're on RHEL4, OpenSSL 0.9.7a, FreeRadius 1.1.3
Yes, Same here.
Found it. Double-free at line 460 of src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c - see the email I just sent.
On Thu, Oct 26, 2006 at 12:22:48AM +0100, Phil Mayers wrote:
B Thompson wrote:
On Wed, Oct 25, 2006 at 10:57:55AM +0100, Phil Mayers wrote:
B Thompson wrote:
I cannot continue to use 1.1.3 as we are regularly using HUP to re-read the configs and there appears to be a problem with this in versions > 1.0.1.
Yes, there does.
I haven't had time to gather the relevant debugging info (we just restart instead of HUP the server as a workaround) but we have several processes running on the same box. Some crash on hup, some don't. Those that do are the ones with the eap/peap modules enabled, so I am thinking it might be SSL related.
What platform are you running on? We're on RHEL4, OpenSSL 0.9.7a, FreeRadius 1.1.3
Yes, Same here.
Found it. Double-free at line 460 of src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c - see the email I just sent.
There must be two separate issues with HUP as this has not fixed the problems we are seeing. Here is my original email about it :- http://lists.freeradius.org/mailman/htdig/freeradius-users/2006-March/051856... -- Ben Thompson
B Thompson <bt4@york.ac.uk> wrote:
http://lists.freeradius.org/mailman/htdig/freeradius-users/2006-March/051856...
A short work-around (i.e. hack) may be to not reload everything on HUP. Why are you HUPing it so often? Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
B Thompson <bt4@york.ac.uk> wrote:
http://lists.freeradius.org/mailman/htdig/freeradius-users/2006-March/051856...
A short work-around (i.e. hack) may be to not reload everything on HUP.
Why are you HUPing it so often?
I realise this question wasn't directed to me, but the reason we HUP it so often is to reload a *large* rlm_passwd map in response to users registering and de-registering for things, and users being blocked and unblocked. I realise in theory an SQL lookup might make more sense, but frankly we've found SQL in FreeRadius to be less-than reliable in the past, and it's certainly never going to be anything like as fast as rlm_passwd. Largely these issues were to do with peak load scaling and MVCC issues in Postgres (MySQL not being an option). It's my intention to write and contribute an rlm_tdb module at some point when I have the free time (ha!) which would allow update processes to write to the binary map file whilst FR is running e.g. modules tdb mac2zone { file = %{confdir}/mac2zone.tdb key = "Calling-Station-Id" result = "~MyZone ~MyHostId" } tdb nas2vlanset { file = %{confdir}/nas2vlanset.tdb key = "NAS-IP-Address" result = "~MyVlanset ~MyNasId" } tdb zonevlan2vlan { file = %{confdir}/zonevlan2vlan key = "MyZone MyVlanset" result = "Tunnel-Private-Group-Id" } } authorize { preprocess files Autz-Type MACBASEVLANS { mac2zone nas2vlanset zonevlan2vlan } } ...and one could update the .tdb live
Phil Mayers <p.mayers@imperial.ac.uk> wrote:
I realise this question wasn't directed to me, but the reason we HUP it so often is to reload a *large* rlm_passwd map in response to users registering and de-registering for things, and users being blocked and unblocked.
Ok. I think in the CVS head, we should fix HUP so that all modules have a "reload" method. HUP will cause module config to be reloaded, but will NOT change anything else.
It's my intention to write and contribute an rlm_tdb module at some point when I have the free time (ha!) which would allow update processes to write to the binary map file whilst FR is running e.g.
Sounds good to me. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
B Thompson wrote:
On Thu, Oct 26, 2006 at 12:22:48AM +0100, Phil Mayers wrote:
B Thompson wrote:
On Wed, Oct 25, 2006 at 10:57:55AM +0100, Phil Mayers wrote:
B Thompson wrote:
I cannot continue to use 1.1.3 as we are regularly using HUP to re-read the configs and there appears to be a problem with this in versions > 1.0.1.
Yes, there does.
I haven't had time to gather the relevant debugging info (we just restart instead of HUP the server as a workaround) but we have several processes running on the same box. Some crash on hup, some don't. Those that do are the ones with the eap/peap modules enabled, so I am thinking it might be SSL related.
What platform are you running on? We're on RHEL4, OpenSSL 0.9.7a, FreeRadius 1.1.3 Yes, Same here.
Found it. Double-free at line 460 of src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c - see the email I just sent.
There must be two separate issues with HUP as this has not fixed the problems we are seeing. Here is my original email about it :-
Could you run FR like this to trace it maybe? ./configure --enable-developer make make install gdb /usr/local/sbin/radiusd set logging file radiusd.log set logging on handle SIGHUP nostop break modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c:323 run -f # wait for it to crash thread apply all bt full print conf print conf->certificate_file
participants (3)
-
Alan DeKok -
B Thompson -
Phil Mayers