I know it is not an asterisk bug, but it happened already on two sites, so I think it is worth reporting. Without any relevant change, one morning every comparison in the asterisk dialplan resolves to Nan with disastrous results. Asterisk is running on CentOS 7 on a Redhat virtualization platform I …

Is this not the same issue as in [image] Conditional Applications/Functions Not Working Asterisk Support Installing Asterisk v18.0.1 on Centos 7.9.2009 (Kernel 3.10.0-1127.el7.x86_64) and try to implement these simple dialplan [default] exten => *100,1,NoOP(Hello there) …

yum downgrade glibc-devel glibc glibc-common glibc-headers systemctl restart asterisk There was a similar thread on the forum and was solved with the above commands

The problem seems to be this security fix: 26649 – (CVE-2020-29573) printf should handle non-normal x86 long double numbers gracefully (CVE-2020-29573) I’m not sure what code in Asterisk triggers this new behaviour, but this is clearly the source new “nan” text now produced by evaluating conditions…

The problem with the “nan” output was fixed in package glibc-2.17-323.el7_9.x86_64 ( 1925204 – glibc: printf of long double with a value of 0 results in "nan" [rhel-7.9.z] ). With that release, the conditional evaluation to “nan” problem is gone. So now, if you update CentOS and then run yum downgrad…

Thanks Red Hat Customer Portal - Access to 24x7 support and knowledge

All comparison equal to Nan

Asterisk Asterisk Dialplan

david551 February 7, 2021, 10:17am 2

Is this not the same issue as in

That one is attributed to a bug in glibc.

Topic		Replies	Views
Conditional Applications/Functions Not Working Asterisk Support	4	903	February 5, 2021
Conditions in dialplan Asterisk Support	3	1439	April 28, 2022
Whats wrong with my expression? Asterisk Support	6	369	March 19, 2007
Eval $[...] always returning 0? Asterisk Support	2	196	November 29, 2005
Warning with GOTOIF Asterisk Dialplan	4	383	May 6, 2021

All comparison equal to Nan

Related topics