If FS is not behind NAT, then every call generates at least three
INFO-level log messages:
[INFO] switch_nat.c:589 NAT port mapping disabled
This is useless noise. The message is only interesting if you do have
NAT enabled but mapping disabled, which might indicate a configuration
issue.
With this change, we just skip the entire nat_add_mapping function if
the NAT system isn't initialized or we're not behind NAT.
Putting `net-snmp-config --cflags` into CFLAGS causes major pollution;
it overrides optimization and debugging levels, warnings, and more.
While normally we do want to automatically locate library headers,
there has to be a better way to do this. libsnmp is normally in the
usual place and doesn't need special handling. Perhaps people with
libsnmp in a weird place should just need to add the -I flag to their
CFLAGS before build.
Calling out to net-snmp-config --agent-libs causes transitive
dependencies to get pulled in, but we don't need those -- a sensible
dynamic linker pulls those in automatically. Trying to track the
transitive dependencies manually would be a losing battle.
People were recently hitting this on Debian sid/jessie, where libpci
is in the transitive dependency list but isn't otherwise one of our
build dependencies.
This seems to be a paradox when running a perl script from a session then executing perl again on the same session from a different thread.
I fixed it by converting any execution of perl in the execute_on_* family of operators to only run background mode which is to store the command in the session stack to be executed only by the session thread instead of on the spot by the outide thread. changing the execute_on_answer to perl::/path/to/script.pl would also eliminate the crash in code that has not been updated with this patch.
This is just a limitation of embedded perl we have to live with.
On start DTMF packets we were showing the last write timestamp as a
signed value when it's an unsigned value, which could result in it
appearing incongruous with later packets where the value was displayed
correctly.
Previously we would continue considering phrase actions even after
receiving a break action; we would only break on the next input
clause. It appears the intent here was to break before the next
action.
