Updating to git's v2.1.x to go on a post-Easter bughunt and found the following accounting packet[1] seems to segfault freeradius: ---- tcpdump: listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes 11:30:34.398885 IP6 (hlim 51, next-header UDP (17) payload length: 258) 2001:630:1:128::185.42390 > 2001:630:1b:6003:90c0:802a:d873:c284.1813: [bad udp cksum 51b1!] RADIUS, length: 250 Accounting Request (4), id: 0x1b, Authenticator: 44b81fb81af404cb48816ad0c2afc497 NAS IP Address Attribute (4), length: 6, Value: 128.86.129.105 Accounting Status Attribute (40), length: 6, Value: Stop Username Attribute (1), length: 19, Value: 223313@soas.ac.uk NAS Port Attribute (5), length: 6, Value: 0 NAS Port Type Attribute (61), length: 6, Value: Wireless - IEEE 802.11 Accounting Session ID Attribute (44), length: 27, Value: 223313@s7CC5376FE7E3-C189 Accounting Input Octets Attribute (42), length: 6, Value: 42426 Accounting Output Octets Attribute (43), length: 6, Value: 351596 Accounting Input Packets Attribute (47), length: 6, Value: 301 Accounting Output Packets Attribute (48), length: 6, Value: 379 Accounting Termination Cause Attribute (49), length: 6, Value: Idle Timeout Framed IP Address Attribute (8), length: 6, Value: 128.86.184.37 Calling Station Attribute (31), length: 14, Value: 7CC5376FE7E3 Called Station Attribute (30), length: 14, Value: 000B860E5100 Accounting Session Time Attribute (46), length: 6, Value: 06:40 min Accounting Delay Attribute (41), length: 6, Value: 00 secs Vendor Specific Attribute (26), length: 15, Value: Vendor: Unknown (14823) Vendor Attribute: 5, Length: 7, Value: eduroam Vendor Specific Attribute (26), length: 11, Value: Vendor: Unknown (14823) Vendor Attribute: 6, Length: 3, Value: N/A Vendor Specific Attribute (26), length: 20, Value: Vendor: Unknown (14823) Vendor Attribute: 1, Length: 12, Value: pre-employee Vendor Specific Attribute (26), length: 12, Value: Vendor: Unknown (14823) Vendor Attribute: 2, Length: 4, Value: .... Unknown Attribute (103), length: 6, Value: Proxy State Attribute (33), length: 20, Value: OSC-Extended-Id=27 ---- The gdb backtrace is: ---- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x42b7b470 (LWP 9963)] 0x402dc2bc in strnlen () from /lib/libc.so.6 (gdb) where #0 0x402dc2bc in strnlen () from /lib/libc.so.6 #1 0x403075d8 in fnmatch () from /lib/libc.so.6 #2 0x409da598 in do_detail (instance=0x114e50, request=0x43443240, packet=0x43446dd8, compat=<value optimized out>) at rlm_detail.c:301 #3 0x00022110 in call_modsingle (component=3, c=<value optimized out>, request=0x43443240) at modcall.c:297 #4 modcall (component=3, c=<value optimized out>, request=0x43443240) at modcall.c:670 #5 0x0001ec94 in indexed_modcall (comp=3, idx=0, request=0x43443240) at modules.c:737 #6 0x0000eefc in rad_accounting (request=0x43443240) at acct.c:93 #7 0x0002f16c in radius_handle_request (request=0x43443240, fun=0xee60 <rad_accounting>) at event.c:3780 #8 0x00026a4c in request_handler_thread (arg=<value optimized out>) at threads.c:525 #9 0x400818cc in start_thread () from /lib/libpthread.so.0 #10 0x40330bdc in clone () from /lib/libc.so.6 #11 0x40330bdc in clone () from /lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) ---- If you need the FreeRADIUS -X malarkey, then do ask, it is just tricker to get on a production box... :) Cheers [1] http://stuff.digriz.org.uk/freeradius-acct-segfault.pcap -- Alexander Clouter .sigmonster says: Preserve the old, but know the new.
Hi,
NAS Port Attribute (5), length: 6, Value: 0
NAS-Port 0 are you serious? ;-)
Vendor Specific Attribute (26), length: 12, Value: Vendor: Unknown (14823) Vendor Attribute: 2, Length: 4, Value: ....
..thats an interesting one.
Unknown Attribute (103), length: 6, Value:
as is that. unpopulated/corrupt attributes. what are you doing with this accounting packet when it arrives? 'detail' module? SQL ? alan
Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
NAS Port Attribute (5), length: 6, Value: 0
NAS-Port 0
are you serious? ;-)
Hey, *you* are the proxying it ;P
Vendor Specific Attribute (26), length: 12, Value: Vendor: Unknown (14823) Vendor Attribute: 2, Length: 4, Value: ....
..thats an interesting one.
Unknown Attribute (103), length: 6, Value:
as is that. unpopulated/corrupt attributes.
Just unprintable, check the pcap file linked to in the original email for <ahem> and giggles.
what are you doing with this accounting packet when it arrives? 'detail' module? SQL ?
Journalled accounting, it's picked up by decoupled account virtual server. Cheers -- Alexander Clouter .sigmonster says: Generic Fortune.
Alexander Clouter wrote:
Updating to git's v2.1.x to go on a post-Easter bughunt and found the following accounting packet[1] seems to segfault freeradius: ... #1 0x403075d8 in fnmatch () from /lib/libc.so.6 #2 0x409da598 in do_detail (instance=0x114e50, request=0x43443240, packet=0x43446dd8, compat=<value optimized out>) at rlm_detail.c:301
Hmm... calling fnmatch() when the packet was *not* read from the detail file is a bad idea. Oops. On closer inspection, much of the logic in rlm_detail is broken.
If you need the FreeRADIUS -X malarkey, then do ask, it is just tricker to get on a production box... :)
Nah. I think the Feynman method is fine. 1) look at problem 2) think hard 3) write down solution Give me a bit and I'll push a change to "git". Alan DeKok.
On 09/05/2011 12:22, Alan DeKok wrote:
Alexander Clouter wrote:
Updating to git's v2.1.x to go on a post-Easter bughunt and found the following accounting packet[1] seems to segfault freeradius: ... #1 0x403075d8 in fnmatch () from /lib/libc.so.6 #2 0x409da598 in do_detail (instance=0x114e50, request=0x43443240, packet=0x43446dd8, compat=<value optimized out>) at rlm_detail.c:301
Hmm... calling fnmatch() when the packet was *not* read from the detail file is a bad idea. Oops.
On closer inspection, much of the logic in rlm_detail is broken.
If you need the FreeRADIUS -X malarkey, then do ask, it is just tricker to get on a production box... :)
Nah. I think the Feynman method is fine.
1) look at problem 2) think hard 3) write down solution
Give me a bit and I'll push a change to "git".
It now seems to create a *directory* with the name that should be the detail *file*... custard radius # find ./ -type d ./ ./radacct ./radacct/eduroamalien-soh-bsql ./radacct/vpi-soh-bsql ./radacct/eduroamlocal-soh-bsql ./radacct/nomadicvpn-bsql ./radacct/uobgear ./radacct/eduroamlocal-inner ./radacct/eduroamlocal-bsql ./radacct/vpi ./radacct/eduroamalien-inner ./radacct/eduroamlocal ./radacct/vpi-inner ./radacct/eduroamalien ./radacct/nomadicvpn custard radius # killall -9 radiusd ; /usr/local/sbin/radiusd custard radius # tail -n 0 -f radius*.log <SNIP> ==> radiusd-eduroamlocal.log <== Mon May 9 17:50:25 2011 : Error: [detail-bsql] rlm_detail: Couldn't open file /var/log/radius/radacct/eduroamlocal-bsql/detail-bsql.log: Is a directory Mon May 9 17:50:25 2011 : Error: [detail-bsql] rlm_detail: Couldn't open file /var/log/radius/radacct/eduroamlocal-bsql/detail-bsql.log: Is a directory ls -la also shows that radiusd has indeed created a directory with what should have been the file name. module config: custard radius # cat /usr/local/etc/serviceraddb/modules/detail-bsql | grep '[[:print:]]' | grep -v '#' detail detail-bsql { detailfile = ${radacctdir}/%{%{Virtual-Server}:-UNKNOWN}-bsql/detail-bsql.log detailperm = 0600 header = "%t" } -James
participants (4)
-
Alan Buxey -
Alan DeKok -
Alexander Clouter -
James J J Hooper