Re: TMPL_TYPE_LITERAL has non-zero bytes in its data union
Hi Jorge, all data (or at least how reproduce it) are available in the previous post in ML: - http://lists.freeradius.org/pipermail/freeradius-devel/2019-June/013544.html - http://lists.freeradius.org/pipermail/freeradius-devel/2019-June/013554.html Alan, like me after some emails he clean mail thread :) Bye On Fri, 2019-07-05 at 14:36 -0300, Jorge Pereira wrote:
Please, Share the radius -XXx output. And If you are getting some crash, please share the stack trace as you got previously.—Jorge Pereira
On 5 Jul 2019, at 14:34, Geaaru <geaaru@gmail.com> wrote: Hi,I had investigate a bit on this and it's very weird.I revert the code of the tag 3.0.17 that is now in production and wherecode with PAP/CHAP condition works perfectly, but now with the same3.0.17 in upgraded rootfs I receive the same error.I fear that could be related to some library used by Freeradius.Between the differences I have:- glibc-2.28 (works) => glibc-2.29 (doesn't work)- json- c-0.12 => json-c-0.13.1- talloc-2.1.14 => talloc-2.2.0Is there a specific library that is used by unlang parser? Could berelated to glibc or talloc? On Wed, 2019-06-26 at 14:03 -0400, Alan DeKok wrote:
On Jun 26, 2019, at 1:01 PM, Geaaru <geaaru@gmail.com> wrote:
I saw your patch on upstream and I dunno if your commits covercompletely this use case.
It doesn't fix it.
But if could help, now I have a different stack for the exceptionwith your last changes:
It now complains when the problem occurs, and not many functionslater. I've tracked it down to exactly the situation that needs to befixed. We should have a fix in a few days. Alan DeKok. -List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Take a look at the libkqueue version. — Jorge Pereira
On 5 Jul 2019, at 14:42, Geaaru <geaaru@gmail.com> wrote:
Hi Jorge,
all data (or at least how reproduce it) are available in the previous post in ML:
- http://lists.freeradius.org/pipermail/freeradius-devel/2019-June/013544.html <http://lists.freeradius.org/pipermail/freeradius-devel/2019-June/013544.html> - http://lists.freeradius.org/pipermail/freeradius-devel/2019-June/013554.html <http://lists.freeradius.org/pipermail/freeradius-devel/2019-June/013554.html>
Alan, like me after some emails he clean mail thread :)
Bye
On Fri, 2019-07-05 at 14:36 -0300, Jorge Pereira wrote:
Please,
Share the radius -XXx output. And If you are getting some crash, please share the stack trace as you got previously. — Jorge Pereira
On 5 Jul 2019, at 14:34, Geaaru < geaaru@gmail.com <mailto:geaaru@gmail.com>> wrote:
On Jun 26, 2019, at 1:01 PM, Geaaru < geaaru@gmail.com <mailto:geaaru@gmail.com>> wrote:
I saw your patch on upstream and I dunno if your commits cover completely this use case.
It doesn't fix it.
But if could help, now I have a different stack for the exception with your last changes:
It now complains when the problem occurs, and not many functions later. I've tracked it down to exactly the situation that needs to be fixed. We should have a fix in a few days. Alan DeKok.
Hi, I had investigate a bit on this and it's very weird. I revert the code of the tag 3.0.17 that is now in production and where code with PAP/CHAP condition works perfectly, but now with the same 3.0.17 in upgraded rootfs I receive the same error. I fear that could be related to some library used by Freeradius. Between the differences I have: - glibc-2.28 (works) => glibc-2.29 (doesn't work)- json-c- 0.12 => json-c-0.13.1- talloc-2.1.14 => talloc- 2.2.0 Is there a specific library that is used by unlang parser? Could be related to glibc or talloc? On Wed, 2019-06-26 at 14:03 -0400, Alan DeKok wrote: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html <http://www.freeradius.org/list/devel.html>
Hi, this issue is on 3.0.x branch (not tested on master branch) and I don't use libkqueue. I downgrade to talloc-2.1.14 (also 2.1.9) and I have the same issue. But it seems that happens only if it's enabled -Xx debug. If I disable debug freeradius bootstrap correctly.So, probably this means that I'm not sure that libraries currently in production haven't the issue because debug is disabled. But I'm sure that this configuration in the past worked correctly also with debug. It's very weird. I executed a test also with tagged version 3.0.16 and 3.0.15 and I reproduced the same issue. I will investigate a bit on FreeRadius parser for try to indentify the issue. On Fri, 2019-07-05 at 15:45 -0300, Jorge Pereira wrote:
Take a look at the libkqueue version.—Jorge Pereira
On 5 Jul 2019, at 14:42, Geaaru <geaaru@gmail.com> wrote: Hi Jorge, all data (or at least how reproduce it) are available in the previous post in ML: - http://lists.freeradius.org/pipermail/freeradius-devel/2019-June/013544.html < http://lists.freeradius.org/pipermail/freeradius-devel/2019-June/013544.html> ;- http://lists.freeradius.org/pipermail/freeradius-devel/2019-June/013554.html < http://lists.freeradius.org/pipermail/freeradius-devel/2019-June/013554.html
Alan, like me after some emails he clean mail thread :) Bye On Fri, 2019-07-05 at 14:36 -0300, Jorge Pereira wrote:
Please, Share the radius -XXx output. And If you are getting some crash, please share the stack trace as you got previously.—Jorge Pereira
On 5 Jul 2019, at 14:34, Geaaru <geaaru@gmail.com <mailto:geaaru@gmail.com>> wrote: Hi,I had investigate a bit on this and it's very weird.I revert the code of the tag 3.0.17 that is now in production and wherecode with PAP/CHAP condition works perfectly, but now with the same3.0.17 in upgraded rootfs I receive the same error.I fear that could be related to some library used by Freeradius.Between the differences I have:- glibc- 2.28 (works) => glibc-2.29 (doesn't work)- json-c- 0.12 => json-c-0.13.1- talloc-2.1.14 => talloc-2.2.0Is there a specific library that is used by unlang parser? Could berelated to glibc or talloc? On Wed, 2019-06-26 at 14:03 -0400, Alan DeKok wrote:
On Jun 26, 2019, at 1:01 PM, Geaaru <geaaru@gmail.com <mailto:geaaru@gmail.com>> wrote:
I saw your patch on upstream and I dunno if your commits covercompletely this use case.
It doesn't fix it.
But if could help, now I have a different stack for the exceptionwith your last changes:
It now complains when the problem occurs, and not many functionslater. I've tracked it down to exactly the situation that needs to befixed. We should have a fix in a few days. Alan DeKok. -List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html <http://www.freeradius.org/list/devel.html>
-List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On Jul 8, 2019, at 2:05 PM, Geaaru <geaaru@gmail.com> wrote:
this issue is on 3.0.x branch (not tested on master branch) and I don't use libkqueue.
I downgrade to talloc-2.1.14 (also 2.1.9) and I have the same issue.
The issue isn't related to malloc or other libraries.
But it seems that happens only if it's enabled -Xx debug. If I disable debug freeradius bootstrap correctly. So, probably this means that I'm not sure that libraries currently in production haven't the issue because debug is disabled.
No. It means that when using "-Xx", the server does additional sanity checking on it's data structures.
But I'm sure that this configuration in the past worked correctly also with debug. It's very weird.
I executed a test also with tagged version 3.0.16 and 3.0.15 and I reproduced the same issue.
I will investigate a bit on FreeRadius parser for try to indentify the issue.
The issue is in value_data_from_str(). If it fails to parse the string, it still mangles the data. The solution is to have that function update the output data only when it succeeds. Alan DeKok.
On Jul 8, 2019, at 8:43 AM, Alan DeKok <aland@deployingradius.com> wrote:
The issue is in value_data_from_str(). If it fails to parse the string, it still mangles the data. The solution is to have that function update the output data only when it succeeds.
Nope. The issue was elsewhere. I've pushed a fix in commit 1a3206c Alan DeKok.
Ok, thanks. I will test it at the end of the month. Thanks again for your help. On Wed, Jul 17, 2019, 12:58 Alan DeKok <aland@deployingradius.com> wrote:
On Jul 8, 2019, at 8:43 AM, Alan DeKok <aland@deployingradius.com> wrote:
The issue is in value_data_from_str(). If it fails to parse the string, it still mangles the data. The solution is to have that function update the output data only when it succeeds.
Nope. The issue was elsewhere.
I've pushed a fix in commit 1a3206c
Alan DeKok.
Hi, now it seems that Freeradius bootstrap correctly but I have another issue on store in Memcache (afte Accounting-Start request). I have also a migration to GCC 8 I don't know if could be related to this. Tue Jul 30 19:20:32 2019 : Debug: (0) cache_auth: EXPAND %{Calling- Station-Id}-%{NAS-Identifier}-authTue Jul 30 19:20:32 2019 : Debug: (0) cache_auth: --> 39330XXXXXXXXX-GGSN_MI5-authTue Jul 30 19:20:32 2019 : Debug: rlm_cache (cache_auth): Reserved connection (1)Tue Jul 30 19:20:32 2019 : Debug: (0) cache_auth: No cache entry found for "39330XXXXXXXXX-GGSN_MI5-auth"Tue Jul 30 19:20:32 2019 : Debug: (0) cache_auth: Creating new cache entryTue Jul 30 19:20:32 2019 : Debug: (0) cache_auth: &control:My-Auth := &control:My-Auth -> 'Reject'Tue Jul 30 19:20:32 2019 : Error: ASSERT FAILED /home/geaaru/Projects/freeradius-server/src/main/map.c[967]: 0CAUGHT SIGNAL: AbortedBacktrace of last 25 frames:/tmp/radius/usr/lib/libfreeradius- radius.so(fr_fault+0x12c)[0x7ffff7f44078]/tmp/radius/usr/lib/libfreerad ius- server.so(rad_assert_fail+0x46)[0x7ffff7fad9c4]/tmp/radius/usr/lib/libf reeradius- server.so(map_to_vp+0xd00)[0x7ffff7fa5d67]/tmp/radius/usr/lib/rlm_cache .so(+0x2e6d)[0x7ffff7b86e6d]/tmp/radius/usr/lib/rlm_cache.so(+0x38b4)[0 x7ffff7b878b4]/tmp/radius/usr/sbin/radiusd(+0x31239)[0x555555585239]/tm p/radius/usr/sbin/radiusd(+0x3198b)[0x55555558598b]/tmp/radius/usr/sbin /radiusd(+0x31401)[0x555555585401]/tmp/radius/usr/sbin/radiusd(+0x3247b )[0x55555558647b]/tmp/radius/usr/sbin/radiusd(+0x31401)[0x555555585401] /tmp/radius/usr/sbin/radiusd(+0x3247b)[0x55555558647b]/tmp/radius/usr/s bin/radiusd(modcall+0xb1)[0x5555555872f2]/tmp/radius/usr/sbin/radiusd(i ndexed_modcall+0x366)[0x55555558274f]/tmp/radius/usr/sbin/radiusd(proce ss_accounting+0x22)[0x555555584b63]/tmp/radius/usr/sbin/radiusd(rad_acc ounting+0xec)[0x555555568651]/tmp/radius/usr/sbin/radiusd(+0x46d9e)[0x5 5555559ad9e]/tmp/radius/usr/sbin/radiusd(+0x459a6)[0x5555555999a6]/tmp/ radius/usr/sbin/radiusd(request_receive+0x82f)[0x55555559b6b2]/tmp/radi us/usr/sbin/radiusd(+0x1f55b)[0x55555557355b]/tmp/radius/usr/sbin/radiu sd(+0x4f4d5)[0x5555555a34d5]/tmp/radius/usr/lib/libfreeradius- radius.so(fr_event_loop+0x651)[0x7ffff7f6eb2c]/tmp/radius/usr/sbin/radi usd(radius_event_process+0x26)[0x5555555a54de]/tmp/radius/usr/sbin/radi usd(main+0xcb8)[0x55555558de45]/lib64/libc.so.6(__libc_start_main+0xe7) [0x7ffff745fc07]/tmp/radius/usr/sbin/radiusd(_start+0x2a)[0x5555555684a a]No panic action set Program received signal SIGABRT, Aborted.0x00007ffff78b46cb in raise () from /lib64/libpthread.so.0(gdb) bt#0 0x00007ffff78b46cb in raise () from /lib64/libpthread.so.0#1 0x00007ffff7f4433f in fr_fault (sig=6) at /home/geaaru/Projects/freeradius- server/src/lib/debug.c:763#2 0x00007ffff7fad9c4 in rad_assert_fail (file=0x7ffff7fbf560 "/home/geaaru/Projects/freeradius- server/src/main/map.c", line=967, expr=0x7ffff7fbfaf2 "0") at /home/geaaru/Projects/freeradius- server/src/main/util.c:557#3 0x00007ffff7fa5d67 in map_to_vp (ctx=0x555555b2cba0, out=0x7fffffffadf0, request=0x555555b2a7d0, map=0x555555ae0760, uctx=0x0) at /home/geaaru/Projects/freeradius- server/src/main/map.c:967#4 0x00007ffff7b86e6d in cache_insert (inst=0x5555558d0730, request=0x555555b2a7d0, handle=0x7fffffffaf48, key=0x7fffffffaf90 "39330XXXXXXXXX-GGSN_MI5-auth", ttl=30) at /home/geaaru/Projects/freeradius- server/src/modules/rlm_cache/rlm_cache.c:277#5 0x00007ffff7b878b4 in mod_cache_it (instance=0x5555558d0730, request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius- server/src/modules/rlm_cache/rlm_cache.c:533#6 0x0000555555585239 in call_modsingle (component=MOD_ACCOUNTING, sp=0x555555b12420, request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius- server/src/main/modcall.c:304#7 0x000055555558598b in modcall_recurse (request=0x555555b2a7d0, component=MOD_ACCOUNTING, depth=2, entry=0x7fffffffc880, do_next_sibling=true) at /home/geaaru/Projects/freeradius- server/src/main/modcall.c:580#8 0x0000555555585401 in modcall_child (request=0x555555b2a7d0, component=MOD_ACCOUNTING, depth=2, entry=0x7fffffffc868, c=0x555555b11a60, result=0x7fffffffbb00, do_next_sibling=true) at /home/geaaru/Projects/freeradius- server/src/main/modcall.c:410#9 0x000055555558647b in modcall_recurse (request=0x555555b2a7d0, component=MOD_ACCOUNTING, depth=1, entry=0x7fffffffc868, do_next_sibling=true) at /home/geaaru/Projects/freeradius-server/src/main/modcall.c:791#10 0x0000555555585401 in modcall_child (request=0x555555b2a7d0, component=MOD_ACCOUNTING, depth=1, entry=0x7fffffffc850, c=0x555555b117a0, result=0x7fffffffc1e0, do_next_sibling=true) at /home/geaaru/Projects/freeradius-server/src/main/modcall.c:410#11 0x000055555558647b in modcall_recurse (request=0x555555b2a7d0, component=MOD_ACCOUNTING, depth=0, entry=0x7fffffffc850, do_next_sibling=true) at /home/geaaru/Projects/freeradius- server/src/main/modcall.c:791#12 0x00005555555872f2 in modcall (component=MOD_ACCOUNTING, c=0x555555b10e30, request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius-server/src/main/modcall.c:1136#13 0x000055555558274f in indexed_modcall (comp=MOD_ACCOUNTING, idx=0, request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius- server/src/main/modules.c:1030#14 0x0000555555584b63 in process_accounting (acct_type=0, request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius-server/src/main/modules.c:2187#15 0x0000555555568651 in rad_accounting (request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius-server/src/main/acct.c:93#16 0x000055555559ad9e in request_running (request=0x555555b2a7d0, action=1) at /home/geaaru/Projects/freeradius- server/src/main/process.c:1628#17 0x00005555555999a6 in request_queue_or_run (request=0x555555b2a7d0, process=0x55555559ac5f <request_running>) at /home/geaaru/Projects/freeradius- server/src/main/process.c:1106#18 0x000055555559b6b2 in request_receive (ctx=0x555555b2a560, listener=0x555555b26bb0, packet=0x555555b2a5c0, client=0x555555b24090, fun=0x555555568565 <rad_accounting>) at /home/geaaru/Projects/freeradius-server/src/main/process.c:1892#19 0x000055555557355b in acct_socket_recv (listener=0x555555b26bb0) at /home/geaaru/Projects/freeradius-server/src/main/listen.c:1693#20 0x00005555555a34d5 in event_socket_handler (xel=0x55555588fe40, fd=29, ctx=0x555555b26bb0) at /home/geaaru/Projects/freeradius- server/src/main/process.c:4848#21 0x00007ffff7f6eb2c in fr_event_loop (el=0x55555588fe40) at /home/geaaru/Projects/freeradius- server/src/lib/event.c:649#22 0x00005555555a54de in radius_event_process () at /home/geaaru/Projects/freeradius- server/src/main/process.c:5933#23 0x000055555558de45 in main (argc=9, argv=0x7fffffffd1d8) at /home/geaaru/Projects/freeradius- server/src/main/radiusd.c:641 with this in my local dictionary: ATTRIBUTE My-Auth 3002 string I will try to reproduce it with a more easy example tomorrow. Release used: $# git log -n2 --onelinedcdd77c46d (HEAD -> v3.0.x, upstream/v3.0.x, origin/v3.0.x) typoa2a1f57087 Framed-Interface-ID is string, not inet. Manual port of #2817 Thanksg. On Wed, 2019-07-17 at 18:33 +0200, Geaaru wrote:
Ok, thanks. I will test it at the end of the month.
Thanks again for your help. On Wed, Jul 17, 2019, 12:58 Alan DeKok <aland@deployingradius.com> wrote:
On Jul 8, 2019, at 8:43 AM, Alan DeKok <aland@deployingradius.com> wrote:
The issue is in value_data_from_str(). If it fails to parse the string, it still mangles the data. The solution is to have that function update the output data only when it succeeds.
Nope. The issue was elsewhere.
I've pushed a fix in commit 1a3206c
Alan DeKok.
Geaaru, Something went wrong with your e-mail client messing up the content (impossible to read). Can you try to send the backtrace again?
On 30 Jul 2019, at 14:51, Geaaru <geaaru@gmail.com> wrote:
Hi, now it seems that Freeradius bootstrap correctly but I have another issue on store in Memcache (afte Accounting-Start request). I have also a migration to GCC 8 I don't know if could be related to this. Tue Jul 30 19:20:32 2019 : Debug: (0) cache_auth: EXPAND %{Calling- Station-Id}-%{NAS-Identifier}-authTue Jul 30 19:20:32 2019 : Debug: (0) cache_auth: --> 39330XXXXXXXXX-GGSN_MI5-authTue Jul 30 19:20:32 2019 : Debug: rlm_cache (cache_auth): Reserved connection (1)Tue Jul 30 19:20:32 2019 : Debug: (0) cache_auth: No cache entry found for "39330XXXXXXXXX-GGSN_MI5-auth"Tue Jul 30 19:20:32 2019 : Debug: (0) cache_auth: Creating new cache entryTue Jul 30 19:20:32 2019 : Debug: (0) cache_auth: &control:My-Auth := &control:My-Auth -> 'Reject'Tue Jul 30 19:20:32 2019 : Error: ASSERT FAILED /home/geaaru/Projects/freeradius-server/src/main/map.c[967]: 0CAUGHT SIGNAL: AbortedBacktrace of last 25 frames:/tmp/radius/usr/lib/libfreeradius- radius.so(fr_fault+0x12c)[0x7ffff7f44078]/tmp/radius/usr/lib/libfreerad ius- server.so(rad_assert_fail+0x46)[0x7ffff7fad9c4]/tmp/radius/usr/lib/libf reeradius- server.so(map_to_vp+0xd00)[0x7ffff7fa5d67]/tmp/radius/usr/lib/rlm_cache .so(+0x2e6d)[0x7ffff7b86e6d]/tmp/radius/usr/lib/rlm_cache.so(+0x38b4)[0 x7ffff7b878b4]/tmp/radius/usr/sbin/radiusd(+0x31239)[0x555555585239]/tm p/radius/usr/sbin/radiusd(+0x3198b)[0x55555558598b]/tmp/radius/usr/sbin /radiusd(+0x31401)[0x555555585401]/tmp/radius/usr/sbin/radiusd(+0x3247b )[0x55555558647b]/tmp/radius/usr/sbin/radiusd(+0x31401)[0x555555585401] /tmp/radius/usr/sbin/radiusd(+0x3247b)[0x55555558647b]/tmp/radius/usr/s bin/radiusd(modcall+0xb1)[0x5555555872f2]/tmp/radius/usr/sbin/radiusd(i ndexed_modcall+0x366)[0x55555558274f]/tmp/radius/usr/sbin/radiusd(proce ss_accounting+0x22)[0x555555584b63]/tmp/radius/usr/sbin/radiusd(rad_acc ounting+0xec)[0x555555568651]/tmp/radius/usr/sbin/radiusd(+0x46d9e)[0x5 5555559ad9e]/tmp/radius/usr/sbin/radiusd(+0x459a6)[0x5555555999a6]/tmp/ radius/usr/sbin/radiusd(request_receive+0x82f)[0x55555559b6b2]/tmp/radi us/usr/sbin/radiusd(+0x1f55b)[0x55555557355b]/tmp/radius/usr/sbin/radiu sd(+0x4f4d5)[0x5555555a34d5]/tmp/radius/usr/lib/libfreeradius- radius.so(fr_event_loop+0x651)[0x7ffff7f6eb2c]/tmp/radius/usr/sbin/radi usd(radius_event_process+0x26)[0x5555555a54de]/tmp/radius/usr/sbin/radi usd(main+0xcb8)[0x55555558de45]/lib64/libc.so.6(__libc_start_main+0xe7) [0x7ffff745fc07]/tmp/radius/usr/sbin/radiusd(_start+0x2a)[0x5555555684a a]No panic action set Program received signal SIGABRT, Aborted.0x00007ffff78b46cb in raise () from /lib64/libpthread.so.0(gdb) bt#0 0x00007ffff78b46cb in raise () from /lib64/libpthread.so.0#1 0x00007ffff7f4433f in fr_fault (sig=6) at /home/geaaru/Projects/freeradius- server/src/lib/debug.c:763#2 0x00007ffff7fad9c4 in rad_assert_fail (file=0x7ffff7fbf560 "/home/geaaru/Projects/freeradius- server/src/main/map.c", line=967, expr=0x7ffff7fbfaf2 "0") at /home/geaaru/Projects/freeradius- server/src/main/util.c:557#3 0x00007ffff7fa5d67 in map_to_vp (ctx=0x555555b2cba0, out=0x7fffffffadf0, request=0x555555b2a7d0, map=0x555555ae0760, uctx=0x0) at /home/geaaru/Projects/freeradius- server/src/main/map.c:967#4 0x00007ffff7b86e6d in cache_insert (inst=0x5555558d0730, request=0x555555b2a7d0, handle=0x7fffffffaf48, key=0x7fffffffaf90 "39330XXXXXXXXX-GGSN_MI5-auth", ttl=30) at /home/geaaru/Projects/freeradius- server/src/modules/rlm_cache/rlm_cache.c:277#5 0x00007ffff7b878b4 in mod_cache_it (instance=0x5555558d0730, request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius- server/src/modules/rlm_cache/rlm_cache.c:533#6 0x0000555555585239 in call_modsingle (component=MOD_ACCOUNTING, sp=0x555555b12420, request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius- server/src/main/modcall.c:304#7 0x000055555558598b in modcall_recurse (request=0x555555b2a7d0, component=MOD_ACCOUNTING, depth=2, entry=0x7fffffffc880, do_next_sibling=true) at /home/geaaru/Projects/freeradius- server/src/main/modcall.c:580#8 0x0000555555585401 in modcall_child (request=0x555555b2a7d0, component=MOD_ACCOUNTING, depth=2, entry=0x7fffffffc868, c=0x555555b11a60, result=0x7fffffffbb00, do_next_sibling=true) at /home/geaaru/Projects/freeradius- server/src/main/modcall.c:410#9 0x000055555558647b in modcall_recurse (request=0x555555b2a7d0, component=MOD_ACCOUNTING, depth=1, entry=0x7fffffffc868, do_next_sibling=true) at /home/geaaru/Projects/freeradius-server/src/main/modcall.c:791#10 0x0000555555585401 in modcall_child (request=0x555555b2a7d0, component=MOD_ACCOUNTING, depth=1, entry=0x7fffffffc850, c=0x555555b117a0, result=0x7fffffffc1e0, do_next_sibling=true) at /home/geaaru/Projects/freeradius-server/src/main/modcall.c:410#11 0x000055555558647b in modcall_recurse (request=0x555555b2a7d0, component=MOD_ACCOUNTING, depth=0, entry=0x7fffffffc850, do_next_sibling=true) at /home/geaaru/Projects/freeradius- server/src/main/modcall.c:791#12 0x00005555555872f2 in modcall (component=MOD_ACCOUNTING, c=0x555555b10e30, request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius-server/src/main/modcall.c:1136#13 0x000055555558274f in indexed_modcall (comp=MOD_ACCOUNTING, idx=0, request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius- server/src/main/modules.c:1030#14 0x0000555555584b63 in process_accounting (acct_type=0, request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius-server/src/main/modules.c:2187#15 0x0000555555568651 in rad_accounting (request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius-server/src/main/acct.c:93#16 0x000055555559ad9e in request_running (request=0x555555b2a7d0, action=1) at /home/geaaru/Projects/freeradius- server/src/main/process.c:1628#17 0x00005555555999a6 in request_queue_or_run (request=0x555555b2a7d0, process=0x55555559ac5f <request_running>) at /home/geaaru/Projects/freeradius- server/src/main/process.c:1106#18 0x000055555559b6b2 in request_receive (ctx=0x555555b2a560, listener=0x555555b26bb0, packet=0x555555b2a5c0, client=0x555555b24090, fun=0x555555568565 <rad_accounting>) at /home/geaaru/Projects/freeradius-server/src/main/process.c:1892#19 0x000055555557355b in acct_socket_recv (listener=0x555555b26bb0) at /home/geaaru/Projects/freeradius-server/src/main/listen.c:1693#20 0x00005555555a34d5 in event_socket_handler (xel=0x55555588fe40, fd=29, ctx=0x555555b26bb0) at /home/geaaru/Projects/freeradius- server/src/main/process.c:4848#21 0x00007ffff7f6eb2c in fr_event_loop (el=0x55555588fe40) at /home/geaaru/Projects/freeradius- server/src/lib/event.c:649#22 0x00005555555a54de in radius_event_process () at /home/geaaru/Projects/freeradius- server/src/main/process.c:5933#23 0x000055555558de45 in main (argc=9, argv=0x7fffffffd1d8) at /home/geaaru/Projects/freeradius- server/src/main/radiusd.c:641 with this in my local dictionary: ATTRIBUTE My-Auth 3002 string I will try to reproduce it with a more easy example tomorrow. Release used: $# git log -n2 --onelinedcdd77c46d (HEAD -> v3.0.x, upstream/v3.0.x, origin/v3.0.x) typoa2a1f57087 Framed-Interface-ID is string, not inet. Manual port of #2817 Thanksg.
Ok, thanks. I will test it at the end of the month.
Thanks again for your help. On Wed, Jul 17, 2019, 12:58 Alan DeKok <aland@deployingradius.com> wrote:
On Jul 8, 2019, at 8:43 AM, Alan DeKok <aland@deployingradius.com> wrote:
The issue is in value_data_from_str(). If it fails to parse the string, it still mangles the data. The solution is to have that function update the output data only when it succeeds.
Nope. The issue was elsewhere.
I've pushed a fix in commit 1a3206c
Alan DeKok.
On Wed, 2019-07-17 at 18:33 +0200, Geaaru wrote: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
ah sorry. I try with HTML email and monospace. Tue Jul 30 19:20:32 2019 : Debug: (0) cache_auth: EXPAND %{Calling- Station-Id}-%{NAS-Identifier}-authTue Jul 30 19:20:32 2019 : Debug: (0) cache_auth: --> 39330XXXXXXXXX-GGSN_MI5-authTue Jul 30 19:20:32 2019 : Debug: rlm_cache (cache_auth): Reserved connection (1)Tue Jul 30 19:20:32 2019 : Debug: (0) cache_auth: No cache entry found for "39330XXXXXXXXX-GGSN_MI5-auth"Tue Jul 30 19:20:32 2019 : Debug: (0) cache_auth: Creating new cache entryTue Jul 30 19:20:32 2019 : Debug: (0) cache_auth: &control:My-Auth := &control:My-Auth -> 'Reject'Tue Jul 30 19:20:32 2019 : Error: ASSERT FAILED /home/geaaru/Projects/freeradius-server/src/main/map.c[967]: 0CAUGHT SIGNAL: AbortedBacktrace of last 25 frames:/tmp/radius/usr/lib/libfreeradius- radius.so(fr_fault+0x12c)[0x7ffff7f44078]/tmp/radius/usr/lib/libfreerad ius- server.so(rad_assert_fail+0x46)[0x7ffff7fad9c4]/tmp/radius/usr/lib/libf reeradius- server.so(map_to_vp+0xd00)[0x7ffff7fa5d67]/tmp/radius/usr/lib/rlm_cache .so(+0x2e6d)[0x7ffff7b86e6d]/tmp/radius/usr/lib/rlm_cache.so(+0x38b4)[0 x7ffff7b878b4]/tmp/radius/usr/sbin/radiusd(+0x31239)[0x555555585239]/tm p/radius/usr/sbin/radiusd(+0x3198b)[0x55555558598b]/tmp/radius/usr/sbin /radiusd(+0x31401)[0x555555585401]/tmp/radius/usr/sbin/radiusd(+0x3247b )[0x55555558647b]/tmp/radius/usr/sbin/radiusd(+0x31401)[0x555555585401] /tmp/radius/usr/sbin/radiusd(+0x3247b)[0x55555558647b]/tmp/radius/usr/s bin/radiusd(modcall+0xb1)[0x5555555872f2]/tmp/radius/usr/sbin/radiusd(i ndexed_modcall+0x366)[0x55555558274f]/tmp/radius/usr/sbin/radiusd(proce ss_accounting+0x22)[0x555555584b63]/tmp/radius/usr/sbin/radiusd(rad_acc ounting+0xec)[0x555555568651]/tmp/radius/usr/sbin/radiusd(+0x46d9e)[0x5 5555559ad9e]/tmp/radius/usr/sbin/radiusd(+0x459a6)[0x5555555999a6]/tmp/ radius/usr/sbin/radiusd(request_receive+0x82f)[0x55555559b6b2]/tmp/radi us/usr/sbin/radiusd(+0x1f55b)[0x55555557355b]/tmp/radius/usr/sbin/radiu sd(+0x4f4d5)[0x5555555a34d5]/tmp/radius/usr/lib/libfreeradius- radius.so(fr_event_loop+0x651)[0x7ffff7f6eb2c]/tmp/radius/usr/sbin/radi usd(radius_event_process+0x26)[0x5555555a54de]/tmp/radius/usr/sbin/radi usd(main+0xcb8)[0x55555558de45]/lib64/libc.so.6(__libc_start_main+0xe7) [0x7ffff745fc07]/tmp/radius/usr/sbin/radiusd(_start+0x2a)[0x5555555684a a] No panic action set Program received signal SIGABRT, Aborted.0x00007ffff78b46cb in raise () from /lib64/libpthread.so.0(gdb) bt#0 0x00007ffff78b46cb in raise () from /lib64/libpthread.so.0#1 0x00007ffff7f4433f in fr_fault (sig=6) at /home/geaaru/Projects/freeradius- server/src/lib/debug.c:763#2 0x00007ffff7fad9c4 in rad_assert_fail (file=0x7ffff7fbf560 "/home/geaaru/Projects/freeradius- server/src/main/map.c", line=967, expr=0x7ffff7fbfaf2 "0") at /home/geaaru/Projects/freeradius- server/src/main/util.c:557#3 0x00007ffff7fa5d67 in map_to_vp (ctx=0x555555b2cba0, out=0x7fffffffadf0, request=0x555555b2a7d0, map=0x555555ae0760, uctx=0x0) at /home/geaaru/Projects/freeradius- server/src/main/map.c:967#4 0x00007ffff7b86e6d in cache_insert (inst=0x5555558d0730, request=0x555555b2a7d0, handle=0x7fffffffaf48, key=0x7fffffffaf90 "39330XXXXXXXXX-GGSN_MI5-auth", ttl=30) at /home/geaaru/Projects/freeradius- server/src/modules/rlm_cache/rlm_cache.c:277#5 0x00007ffff7b878b4 in mod_cache_it (instance=0x5555558d0730, request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius- server/src/modules/rlm_cache/rlm_cache.c:533#6 0x0000555555585239 in call_modsingle (component=MOD_ACCOUNTING, sp=0x555555b12420, request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius- server/src/main/modcall.c:304#7 0x000055555558598b in modcall_recurse (request=0x555555b2a7d0, component=MOD_ACCOUNTING, depth=2, entry=0x7fffffffc880, do_next_sibling=true) at /home/geaaru/Projects/freeradius- server/src/main/modcall.c:580#8 0x0000555555585401 in modcall_child (request=0x555555b2a7d0, component=MOD_ACCOUNTING, depth=2, entry=0x7fffffffc868, c=0x555555b11a60, result=0x7fffffffbb00, do_next_sibling=true) at /home/geaaru/Projects/freeradius- server/src/main/modcall.c:410#9 0x000055555558647b in modcall_recurse (request=0x555555b2a7d0, component=MOD_ACCOUNTING, depth=1, entry=0x7fffffffc868, do_next_sibling=true) at /home/geaaru/Projects/freeradius-server/src/main/modcall.c:791#10 0x0000555555585401 in modcall_child (request=0x555555b2a7d0, component=MOD_ACCOUNTING, depth=1, entry=0x7fffffffc850, c=0x555555b117a0, result=0x7fffffffc1e0, do_next_sibling=true) at /home/geaaru/Projects/freeradius-server/src/main/modcall.c:410#11 0x000055555558647b in modcall_recurse (request=0x555555b2a7d0, component=MOD_ACCOUNTING, depth=0, entry=0x7fffffffc850, do_next_sibling=true) at /home/geaaru/Projects/freeradius- server/src/main/modcall.c:791#12 0x00005555555872f2 in modcall (component=MOD_ACCOUNTING, c=0x555555b10e30, request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius-server/src/main/modcall.c:1136#13 0x000055555558274f in indexed_modcall (comp=MOD_ACCOUNTING, idx=0, request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius- server/src/main/modules.c:1030#14 0x0000555555584b63 in process_accounting (acct_type=0, request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius-server/src/main/modules.c:2187#15 0x0000555555568651 in rad_accounting (request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius-server/src/main/acct.c:93#16 0x000055555559ad9e in request_running (request=0x555555b2a7d0, action=1) at /home/geaaru/Projects/freeradius- server/src/main/process.c:1628#17 0x00005555555999a6 in request_queue_or_run (request=0x555555b2a7d0, process=0x55555559ac5f <request_running>) at /home/geaaru/Projects/freeradius- server/src/main/process.c:1106#18 0x000055555559b6b2 in request_receive (ctx=0x555555b2a560, listener=0x555555b26bb0, packet=0x555555b2a5c0, client=0x555555b24090, fun=0x555555568565 <rad_accounting>) at /home/geaaru/Projects/freeradius-server/src/main/process.c:1892#19 0x000055555557355b in acct_socket_recv (listener=0x555555b26bb0) at /home/geaaru/Projects/freeradius-server/src/main/listen.c:1693#20 0x00005555555a34d5 in event_socket_handler (xel=0x55555588fe40, fd=29, ctx=0x555555b26bb0) at /home/geaaru/Projects/freeradius- server/src/main/process.c:4848#21 0x00007ffff7f6eb2c in fr_event_loop (el=0x55555588fe40) at /home/geaaru/Projects/freeradius- server/src/lib/event.c:649#22 0x00005555555a54de in radius_event_process () at /home/geaaru/Projects/freeradius- server/src/main/process.c:5933#23 0x000055555558de45 in main (argc=9, argv=0x7fffffffd1d8) at /home/geaaru/Projects/freeradius- server/src/main/radiusd.c:641 with this in my local dictionary: ATTRIBUTE My-Auth 3002 string I will try to reproduce it with a more easy example tomorrow. Release used: $# git log -n2 --onelinedcdd77c46d (HEAD -> v3.0.x, upstream/v3.0.x, origin/v3.0.x) typoa2a1f57087 Framed-Interface-ID is string, not inet. Manual port of #2817 On Tue, 2019-07-30 at 14:57 -0300, Jorge Pereira wrote:
Geaaru,
Something went wrong with your e-mail client messing up the content (impossible to read). Can you try to send the backtrace again?
On 30 Jul 2019, at 14:51, Geaaru < geaaru@gmail.com
wrote:
Hi, now it seems that Freeradius bootstrap correctly but I have another issue on store in Memcache (afte Accounting-Start request). I have also a migration to GCC 8 I don't know if could be related to this.
On Wed, 2019-07-17 at 18:33 +0200, Geaaru wrote:
Ok, thanks. I will test it at the end of the month. Thanks again for your help.On Wed, Jul 17, 2019, 12:58 Alan DeKok <aland@deployingradius.com>wrote:
On Jul 8, 2019, at 8:43 AM, Alan DeKok < aland@deployingradius.com
wrote:
The issue is in value_data_from_str(). If it fails to parse
the string, it still mangles the data. The solution is to have that function update the output data only when it succeeds.
Nope. The issue was elsewhere.
I've pushed a fix in commit 1a3206c
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Nothing... I will open an issue to Gnome Evolution before share here my Freeradius issue :) It seems that email is sent in text/plain format automatically and HTML type is ignored. :'( Sorry for the spam. On Tue, 2019-07-30 at 20:20 +0200, Geaaru wrote:
On Tue, 2019-07-30 at 14:57 -0300, Jorge Pereira wrote:
Geaaru,
Something went wrong with your e-mail client messing up the content (impossible to read). Can you try to send the backtrace again?
On 30 Jul 2019, at 14:51, Geaaru < geaaru@gmail.com
wrote:
Hi, now it seems that Freeradius bootstrap correctly but I have another issue on store in Memcache (afte Accounting-Start request). I have also a migration to GCC 8 I don't know if could be related to this.
On Wed, 2019-07-17 at 18:33 +0200, Geaaru wrote:
Ok, thanks. I will test it at the end of the month. Thanks again for your help.On Wed, Jul 17, 2019, 12:58 Alan DeKok <aland@deployingradius.com>wrote:
On Jul 8, 2019, at 8:43 AM, Alan DeKok < aland@deployingradius.com
wrote:
The issue is in value_data_from_str(). If it fails to parse
the string, it still mangles the data. The solution is to have that function update the output data only when it succeeds.
Nope. The issue was elsewhere.
I've pushed a fix in commit 1a3206c
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Still the same. Try to use the service https://pastebin.com/ <https://pastebin.com/> and just share the link.
On 30 Jul 2019, at 15:20, Geaaru <geaaru@gmail.com> wrote:
ah sorry. I try with HTML email and monospace. Tue Jul 30 19:20:32 2019 : Debug: (0) cache_auth: EXPAND %{Calling- Station-Id}-%{NAS-Identifier}-authTue Jul 30 19:20:32 2019 : Debug: (0) cache_auth: --> 39330XXXXXXXXX-GGSN_MI5-authTue Jul 30 19:20:32 2019 : Debug: rlm_cache (cache_auth): Reserved connection (1)Tue Jul 30 19:20:32 2019 : Debug: (0) cache_auth: No cache entry found for "39330XXXXXXXXX-GGSN_MI5-auth"Tue Jul 30 19:20:32 2019 : Debug: (0) cache_auth: Creating new cache entryTue Jul 30 19:20:32 2019 : Debug: (0) cache_auth: &control:My-Auth := &control:My-Auth -> 'Reject'Tue Jul 30 19:20:32 2019 : Error: ASSERT FAILED /home/geaaru/Projects/freeradius-server/src/main/map.c[967]: 0CAUGHT SIGNAL: AbortedBacktrace of last 25 frames:/tmp/radius/usr/lib/libfreeradius- radius.so(fr_fault+0x12c)[0x7ffff7f44078]/tmp/radius/usr/lib/libfreerad ius- server.so(rad_assert_fail+0x46)[0x7ffff7fad9c4]/tmp/radius/usr/lib/libf reeradius- server.so(map_to_vp+0xd00)[0x7ffff7fa5d67]/tmp/radius/usr/lib/rlm_cache .so(+0x2e6d)[0x7ffff7b86e6d]/tmp/radius/usr/lib/rlm_cache.so(+0x38b4)[0 x7ffff7b878b4]/tmp/radius/usr/sbin/radiusd(+0x31239)[0x555555585239]/tm p/radius/usr/sbin/radiusd(+0x3198b)[0x55555558598b]/tmp/radius/usr/sbin /radiusd(+0x31401)[0x555555585401]/tmp/radius/usr/sbin/radiusd(+0x3247b )[0x55555558647b]/tmp/radius/usr/sbin/radiusd(+0x31401)[0x555555585401] /tmp/radius/usr/sbin/radiusd(+0x3247b)[0x55555558647b]/tmp/radius/usr/s bin/radiusd(modcall+0xb1)[0x5555555872f2]/tmp/radius/usr/sbin/radiusd(i ndexed_modcall+0x366)[0x55555558274f]/tmp/radius/usr/sbin/radiusd(proce ss_accounting+0x22)[0x555555584b63]/tmp/radius/usr/sbin/radiusd(rad_acc ounting+0xec)[0x555555568651]/tmp/radius/usr/sbin/radiusd(+0x46d9e)[0x5 5555559ad9e]/tmp/radius/usr/sbin/radiusd(+0x459a6)[0x5555555999a6]/tmp/ radius/usr/sbin/radiusd(request_receive+0x82f)[0x55555559b6b2]/tmp/radi us/usr/sbin/radiusd(+0x1f55b)[0x55555557355b]/tmp/radius/usr/sbin/radiu sd(+0x4f4d5)[0x5555555a34d5]/tmp/radius/usr/lib/libfreeradius- radius.so(fr_event_loop+0x651)[0x7ffff7f6eb2c]/tmp/radius/usr/sbin/radi usd(radius_event_process+0x26)[0x5555555a54de]/tmp/radius/usr/sbin/radi usd(main+0xcb8)[0x55555558de45]/lib64/libc.so.6(__libc_start_main+0xe7) [0x7ffff745fc07]/tmp/radius/usr/sbin/radiusd(_start+0x2a)[0x5555555684a a] No panic action set Program received signal SIGABRT, Aborted.0x00007ffff78b46cb in raise () from /lib64/libpthread.so.0(gdb) bt#0 0x00007ffff78b46cb in raise () from /lib64/libpthread.so.0#1 0x00007ffff7f4433f in fr_fault (sig=6) at /home/geaaru/Projects/freeradius- server/src/lib/debug.c:763#2 0x00007ffff7fad9c4 in rad_assert_fail (file=0x7ffff7fbf560 "/home/geaaru/Projects/freeradius- server/src/main/map.c", line=967, expr=0x7ffff7fbfaf2 "0") at /home/geaaru/Projects/freeradius- server/src/main/util.c:557#3 0x00007ffff7fa5d67 in map_to_vp (ctx=0x555555b2cba0, out=0x7fffffffadf0, request=0x555555b2a7d0, map=0x555555ae0760, uctx=0x0) at /home/geaaru/Projects/freeradius- server/src/main/map.c:967#4 0x00007ffff7b86e6d in cache_insert (inst=0x5555558d0730, request=0x555555b2a7d0, handle=0x7fffffffaf48, key=0x7fffffffaf90 "39330XXXXXXXXX-GGSN_MI5-auth", ttl=30) at /home/geaaru/Projects/freeradius- server/src/modules/rlm_cache/rlm_cache.c:277#5 0x00007ffff7b878b4 in mod_cache_it (instance=0x5555558d0730, request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius- server/src/modules/rlm_cache/rlm_cache.c:533#6 0x0000555555585239 in call_modsingle (component=MOD_ACCOUNTING, sp=0x555555b12420, request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius- server/src/main/modcall.c:304#7 0x000055555558598b in modcall_recurse (request=0x555555b2a7d0, component=MOD_ACCOUNTING, depth=2, entry=0x7fffffffc880, do_next_sibling=true) at /home/geaaru/Projects/freeradius- server/src/main/modcall.c:580#8 0x0000555555585401 in modcall_child (request=0x555555b2a7d0, component=MOD_ACCOUNTING, depth=2, entry=0x7fffffffc868, c=0x555555b11a60, result=0x7fffffffbb00, do_next_sibling=true) at /home/geaaru/Projects/freeradius- server/src/main/modcall.c:410#9 0x000055555558647b in modcall_recurse (request=0x555555b2a7d0, component=MOD_ACCOUNTING, depth=1, entry=0x7fffffffc868, do_next_sibling=true) at /home/geaaru/Projects/freeradius-server/src/main/modcall.c:791#10 0x0000555555585401 in modcall_child (request=0x555555b2a7d0, component=MOD_ACCOUNTING, depth=1, entry=0x7fffffffc850, c=0x555555b117a0, result=0x7fffffffc1e0, do_next_sibling=true) at /home/geaaru/Projects/freeradius-server/src/main/modcall.c:410#11 0x000055555558647b in modcall_recurse (request=0x555555b2a7d0, component=MOD_ACCOUNTING, depth=0, entry=0x7fffffffc850, do_next_sibling=true) at /home/geaaru/Projects/freeradius- server/src/main/modcall.c:791#12 0x00005555555872f2 in modcall (component=MOD_ACCOUNTING, c=0x555555b10e30, request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius-server/src/main/modcall.c:1136#13 0x000055555558274f in indexed_modcall (comp=MOD_ACCOUNTING, idx=0, request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius- server/src/main/modules.c:1030#14 0x0000555555584b63 in process_accounting (acct_type=0, request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius-server/src/main/modules.c:2187#15 0x0000555555568651 in rad_accounting (request=0x555555b2a7d0) at /home/geaaru/Projects/freeradius-server/src/main/acct.c:93#16 0x000055555559ad9e in request_running (request=0x555555b2a7d0, action=1) at /home/geaaru/Projects/freeradius- server/src/main/process.c:1628#17 0x00005555555999a6 in request_queue_or_run (request=0x555555b2a7d0, process=0x55555559ac5f <request_running>) at /home/geaaru/Projects/freeradius- server/src/main/process.c:1106#18 0x000055555559b6b2 in request_receive (ctx=0x555555b2a560, listener=0x555555b26bb0, packet=0x555555b2a5c0, client=0x555555b24090, fun=0x555555568565 <rad_accounting>) at /home/geaaru/Projects/freeradius-server/src/main/process.c:1892#19 0x000055555557355b in acct_socket_recv (listener=0x555555b26bb0) at /home/geaaru/Projects/freeradius-server/src/main/listen.c:1693#20 0x00005555555a34d5 in event_socket_handler (xel=0x55555588fe40, fd=29, ctx=0x555555b26bb0) at /home/geaaru/Projects/freeradius- server/src/main/process.c:4848#21 0x00007ffff7f6eb2c in fr_event_loop (el=0x55555588fe40) at /home/geaaru/Projects/freeradius- server/src/lib/event.c:649#22 0x00005555555a54de in radius_event_process () at /home/geaaru/Projects/freeradius- server/src/main/process.c:5933#23 0x000055555558de45 in main (argc=9, argv=0x7fffffffd1d8) at /home/geaaru/Projects/freeradius- server/src/main/radiusd.c:641
with this in my local dictionary: ATTRIBUTE My-Auth 3002 string
I will try to reproduce it with a more easy example tomorrow. Release used: $# git log -n2 --onelinedcdd77c46d (HEAD -> v3.0.x, upstream/v3.0.x, origin/v3.0.x) typoa2a1f57087 Framed-Interface-ID is string, not inet. Manual port of #2817
Geaaru,
Something went wrong with your e-mail client messing up the content (impossible to read). Can you try to send the backtrace again?
On 30 Jul 2019, at 14:51, Geaaru < geaaru@gmail.com
wrote:
Hi, now it seems that Freeradius bootstrap correctly but I have another issue on store in Memcache (afte Accounting-Start request). I have also a migration to GCC 8 I don't know if could be related to this.
On Wed, 2019-07-17 at 18:33 +0200, Geaaru wrote:
Ok, thanks. I will test it at the end of the month. Thanks again for your help.On Wed, Jul 17, 2019, 12:58 Alan DeKok <aland@deployingradius.com>wrote:
On Jul 8, 2019, at 8:43 AM, Alan DeKok < aland@deployingradius.com
wrote:
The issue is in value_data_from_str(). If it fails to parse
the string, it still mangles the data. The solution is to have that function update the output data only when it succeeds.
Nope. The issue was elsewhere.
I've pushed a fix in commit 1a3206c
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html <http://www.freeradius.org/list/devel.html>
On Tue, 2019-07-30 at 14:57 -0300, Jorge Pereira wrote: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html <http://www.freeradius.org/list/devel.html>
Done: https://pastebin.com/qrvviLTV id="-x-evo-selection-start-marker"> On Tue, 2019-07-30 at 15:24 -0300, Jorge Pereira wrote:
Still the same. Try to use the service https://pastebin.com/ and just share the link.
On Jul 31, 2019, at 5:09 AM, Geaaru <geaaru@gmail.com> wrote:
Done: https://pastebin.com/qrvviLTV id="-x-evo-selection-start-marker">
Hmm... What is the configuration for the "cache" section? The assertion is that the "map" being applied by the cache section isn't in the right format. That "map" is taken from the configuration, in order to do right-side to left-side cache assignments. So something in the configuration looks to be unexpected. Also, if you could break at src/main/map.c:967, and do: (gdb) print *map That would let us know exactly what is in the "map" structure. Which then lets us fix it. Alan DeKok.
Maybe share the entire `radius -X` output.
On 31 Jul 2019, at 10:04, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 31, 2019, at 5:09 AM, Geaaru <geaaru@gmail.com> wrote:
Done: https://pastebin.com/qrvviLTV id="-x-evo-selection-start-marker">
Hmm... What is the configuration for the "cache" section?
The assertion is that the "map" being applied by the cache section isn't in the right format. That "map" is taken from the configuration, in order to do right-side to left-side cache assignments. So something in the configuration looks to be unexpected.
Also, if you could break at src/main/map.c:967, and do:
(gdb) print *map
That would let us know exactly what is in the "map" structure. Which then lets us fix it.
Alan DeKok.
(gdb) p *map$1 = { lhs = 0x555555adfe00, rhs = 0x555555adffd0, op = T_OP_SET, ci = 0x5555557f2230, next = 0x555555ae01a0} I'm sure that is a regression because the same code now is in production with 3.0.17. # Cache for store authentication datacache cache_auth { # driver = "rlm_cache_rbtree" driver = "rlm_cache_memcached" memcached { options = "--SERVER=localhost" pool { start = ${thread[pool].start_servers} min = ${thread[pool].min_spare_servers} max = ${thread[pool].max_servers} spare = ${thread[pool].max_spare_servers} uses = 0 lifetime = 0 idle_timeout = 60 } } key = "%{Calling-Station-Id}-%{NAS-Identifier}-auth" # The TTL of cache entries, in seconds. # This value should be between 10 and 86400. ttl = 120 add_stats = no update { &control:My-Auth := &control:My-Auth &control:My-User := &control:My-User &control:Cleartext-Password := &Control:Cleartext-Password &control:Framed-IP-Netmask := &control:Framed-IP-Network &control:Framed-Protocol := &control:Framed-Protocol &control:Pool-Name := &control:Pool-Name } } AVP available are these: Wed Jul 31 19:27:54 2019 : Debug: (0) sql: Conditional check items matched, merging assignment check itemsWed Jul 31 19:27:54 2019 : Debug: (0) sql: My-Auth := "Reject"Wed Jul 31 19:27:54 2019 : Debug: (0) sql: My-Sim := "0"Wed Jul 31 19:27:54 2019 : Debug: (0) sql: Cache-TTL := 30 And accounting section is this: accounting { update control { &Cache-Status-Only := 'yes' &Cache-Merge := 'no' } cache_auth { notfound = 1 } if (notfound) { # POST: no entry on cache. sql.authorize update control { &Cache-Status-Only := 'no' &Cache- Merge := 'yes' } cache_auth } else { # POST: entry found on cache update control { &Cache-Status-Only := 'no' &Cache- Merge := 'yes' } # Retrieve data from cache cache_auth } } # end accounting Could be related to setting of control:My-User when is not present? I will try to do a bisect. thanks for support. On Wed, 2019-07-31 at 09:04 -0400, Alan DeKok wrote:
On Jul 31, 2019, at 5:09 AM, Geaaru <geaaru@gmail.com> wrote:
Done:https://pastebin.com/qrvviLTV id="-x-evo-selection-start- marker">
Hmm... What is the configuration for the "cache" section? The assertion is that the "map" being applied by the cache section isn't in the right format. That "map" is taken from the configuration, in order to do right-side to left-side cache assignments. So something in the configuration looks to be unexpected. Also, if you could break at src/main/map.c:967, and do: (gdb) print *map That would let us know exactly what is in the "map" structure. Which then lets us fix it. Alan DeKok.
On Jul 31, 2019, at 2:37 PM, Geaaru <geaaru@gmail.com> wrote:
(gdb) p *map $1 = { lhs = 0x555555adfe00, rhs = 0x555555adffd0, op = T_OP_SET, ci = 0x5555557f2230, next = 0x555555ae01a0 }
Hmm.. and what's the output of this: (gdb) p *map->lhs (gdb) p *map->res That should give a bit more information.
I'm sure that is a regression because the same code now is in production with 3.0.17.
OK.
# Cache for store authentication data cache cache_auth { ... }
Yeah, nothing weird there.
Could be related to setting of control:My-User when is not present?
Maybe. It's hard to say. Alan DeKok.
participants (3)
-
Alan DeKok -
Geaaru -
Jorge Pereira