Hi, I know that this post may not contain all of the required information, this is just to get things going while I investigate further. I have had a problem with FreeRADIUS segfaulting intermittently for a number of months which makes it hard to gather the required information. The only thing that I found in all cases was the numerous, empty Cisco-AVPair's in the packet. With it being a segfault I suspect accessing a null pointer somewhere. I have captured a packet that is causing this to occur and sure enough it contains the numerous, empty Cisco-AVPair's. I have started it in gdb now, the output of bt is below. rad_recv: Accounting-Request packet from host w.x.y.z port 2903, id=213, length=362 Service-Type = Framed-User Cisco-AVPair = "" Cisco-AVPair = "" Cisco-AVPair = "" Cisco-AVPair = "" Cisco-AVPair = "" Cisco-AVPair = "" Cisco-AVPair = "" Cisco-AVPair = "" Cisco-AVPair = "" Cisco-AVPair = "" Cisco-AVPair = "" Cisco-AVPair = "" Cisco-AVPair = "" Cisco-AVPair = "" Cisco-AVPair = "" Cisco-AVPair = "" Cisco-AVPair = "" Cisco-AVPair = "" NAS-Port-Type = Async Connect-Info = "3120" Calling-Station-Id = "NPANXXxxxx" X-Ascend-PreSession-Time = 41 X-Ascend-Disconnect-Cause = Remote-End-Hung-Up Acct-Session-Id = "00004E39" Acct-Session-Time = 114 Framed-IP-Address = W.X.Y.Z Acct-Link-Count = 1 Acct-Authentic = RADIUS User-Name = "test@test.com" NAS-Port = 1060 Called-Station-Id = "yyyxxxx" Framed-Protocol = PPP Acct-Terminate-Cause = User-Request Acct-Input-Packets = 53 Acct-Output-Packets = 39 X-Ascend-Data-Rate = 26400 Acct-Delay-Time = 0 Acct-Input-Octets = 1431 Login-Service = PortMaster Acct-Output-Octets = 9084 X-Ascend-Modem-SlotNo = 6 X-Ascend-Xmit-Rate = 31200 Acct-Status-Type = Stop Segmentation fault 0x40297d8f in memcpy () from /lib/libc.so.6 (gdb) bt #0 0x40297d8f in memcpy () from /lib/libc.so.6 #1 0x400289c1 in rad_attr2vp (packet=0x8177678, original=0x0, secret=0x8169168 "secret", attribute=90, length=0, data=0x817887c "\004\006\n\001\001\226x\006\001\005") at radius.c:1953 #2 0x40028df4 in rad_decode (packet=0x8177678, original=0x0, secret=0x8169168 "secret") at radius.c:2386 #3 0x080539d4 in client_socket_decode (listener=0x8174960, request=0x8178898) at listen.c:697 #4 0x0805faab in request_pre_handler (request=0x8178898) at event.c:995 #5 0x08061e2d in radius_handle_request (request=0x8178898, fun=0x804d2b0 <rad_accounting>) at event.c:2701 #6 0x0805ad21 in thread_pool_addrequest (request=0xffffffff, fun=0x8179f04) at threads.c:860 #7 0x08061510 in event_socket_handler (xel=0x8174f98, fd=13, ctx=0x8179f04) at event.c:2340 #8 0x40030c23 in fr_event_loop (el=0x8174f98) at event.c:412 #9 0x08061e03 in radius_event_process () at event.c:2696 #10 0x0805968f in main (argc=2, argv=0x2) at radiusd.c:381 #11 0x4022fd06 in __libc_start_main () from /lib/libc.so.6 I *think* that the problem might be the length=0 in the call to rad_attr2vp(). If that is the case then something like: if (length = 0) return NULL; at line 1928 or so of radius.c might resolve the problem. Before I go ahead and make that addition, am I on the right page or way off in left field on this? Michael ---------------------------------------------------------------------- Michael J. Hartwick, VE3SLQ hartwick@hartwick.com Hartwick Communications Consulting (519) 396-7719 Kincardine, ON, CA http://www.hartwick.com ----------------------------------------------------------------------
Michael J. Hartwick wrote:
I know that this post may not contain all of the required information, this is just to get things going while I investigate further.
From gdb:
#0 0x40297d8f in memcpy () from /lib/libc.so.6 #1 0x400289c1 in rad_attr2vp (packet=0x8177678, original=0x0, secret=0x8169168 "secret", attribute=90, length=0, data=0x817887c
'length' shouldn't be zero. The VP shouldn't be created if 'length' is zero.
I have had a problem with FreeRADIUS segfaulting intermittently for a number of months which makes it hard to gather the required information. The only thing that I found in all cases was the numerous, empty Cisco-AVPair's in the packet. With it being a segfault I suspect accessing a null pointer somewhere.
Can you find out what equipment is generating this nonsense, and file a bug on bugs.freeradius.org with the make/model, etc? That way other people can avoid broken equipment.
I *think* that the problem might be the length=0 in the call to rad_attr2vp(). If that is the case then something like:
if (length = 0) return NULL;
at line 1928 or so of radius.c might resolve the problem. Before I go ahead and make that addition, am I on the right page or way off in left field on this?
You're right, but that change will cause the entire packet to be discarded. If you're Ok with that, fine. Otherwise, I've committed a patch to CVS head that should fix this. Alan DeKok.
On Thu, 31 Jan 2008 at 09:49 (+0100), Alan DeKok wrote: AD> Can you find out what equipment is generating this nonsense, and file AD> a bug on bugs.freeradius.org with the make/model, etc? That way other AD> people can avoid broken equipment. I will see what I can find out for sure. I think that it might be being added by the server that is proxying the packets to us. They insisted that it works properly, however, the packets I was receiving certainly were odd. AD> > I *think* that the problem might be the length=0 in the call to AD> > rad_attr2vp(). If that is the case then something like: AD> > AD> > if (length = 0) return NULL; AD> > AD> > at line 1928 or so of radius.c might resolve the problem. Before I go AD> > ahead and make that addition, am I on the right page or way off in left AD> > field on this? AD> AD> You're right, but that change will cause the entire packet to be AD> discarded. If you're Ok with that, fine. AD> AD> Otherwise, I've committed a patch to CVS head that should fix this. Thanks for the response, it has been a while since I have had the time to poke through the source so I wasn't sure if my "patch" would have worked or not so decided to post to the list. I have taken the radius.c file from CVS and put it into 2.0.1 and so far it seems to be doing exactly what it is supposed to be. I haven't seen those empty pairs coming up while running it under gdb with -X. I haven't had the time to look through the change log to see what other changes have been made and given that we have been having problems I don't really want to run the CVS version until things have been stable for us for a bit. Thanks for the patch! Michael ---------------------------------------------------------------------- Michael J. Hartwick, VE3SLQ hartwick@hartwick.com Hartwick Communications Consulting (519) 396-7719 Kincardine, ON, CA http://www.hartwick.com ----------------------------------------------------------------------
Michael J. Hartwick wrote:
I will see what I can find out for sure. I think that it might be being added by the server that is proxying the packets to us. They insisted that it works properly,
If it's sending zero-length attributes, it's violating RFC 2865: ... text 1-253 octets containing UTF-8 encoded 10646 [7] characters. Text of length zero (0) MUST NOT be sent; omit the entire attribute instead. ... i.e. their local configuration is wrong, AND perhaps their RADIUS server is broken.
I have taken the radius.c file from CVS and put it into 2.0.1 and so far it seems to be doing exactly what it is supposed to be. I haven't seen those empty pairs coming up while running it under gdb with -X.
Yes. Those attributes are *completely* suppressed. They're useless, and shouldn't ever be created. Alan DeKok.
participants (2)
-
Alan DeKok -
Michael J. Hartwick