Bug #11610
open
NET-SNMP is not setting the correct permissions on AgentX
0%
Description
When we go to FRR -> Global Settings -> (Scroll down to "Modules" and tick the "Enable agentx support for accessing FRR Zebra data via SNMP with the net-snmp package."
After this is done, we get the following error trying to restart FRR:
[2.5.0-RELEASE][admin@pfSense.localdomain]/root: /bin/sh /usr/local/etc/rc.d/frr.sh restart
Stopping FRR
Stopping bgpd.
Waiting for PIDS: 97224.
Stopping staticd.
Waiting for PIDS: 96454.
Performing intergrated config test
Starting FRR
Checking intergrated config...
Checking vtysh.conf
OK
Starting zebra.
2021/03/03 11:04:39 ZEBRA: [EC 4043309111] Disabling MPLS support (no kernel support)
Starting staticd.
Starting bgpd.
Booting for integrated-vtysh-config...
% [BGP] Unknown command: agentx
line 10: Failure to communicate[2] to bgpd, line: agentx
Configuration file[/var/etc/frr/frr.conf] processing failure: 2
Starting watchfrr
Updated by Viktor Gurov almost 4 years ago
- Priority changed from Normal-package to Normal
- Target version deleted (
2.5.1) - Affected Version deleted (
2.5.0)
Unable to reproduce with FRR pkg 1.1.0_8 -
frr starts successfully with the "Enable agentx" option:
# ps auxww | grep zebra frr 35713 0.0 1.1 54068 22988 - Is 09:04 0:00.10 /usr/local/sbin/zebra -M snmp -d # grep auxww | grep bgpd frr 93851 0.0 0.5 26376 10688 - Ss 09:12 0:00.02 /usr/local/sbin/bgpd -d # grep agentx /var/etc/frr/frr.conf agentx
Updated by Yif Swery almost 4 years ago
Viktor Gurov wrote:
Unable to reproduce with FRR pkg 1.1.0_8 -
frr starts successfully with the "Enable agentx" option:
[...]
I have just updated to version 1.1.0_8 of FRR and still having the same issue
When GLOBAL SETTINGS "Enable Agent X" is enabled, in CLI I get:
/bin/sh /usr/local/etc/rc.d/frr.sh restart ... Performing intergrated config test Starting FRR Checking intergrated config... Checking vtysh.conf OK Starting zebra. 2021/03/16 10:47:47 ZEBRA: [EC 4043309111] Disabling MPLS support (no kernel support) Starting staticd. Starting bgpd. Booting for integrated-vtysh-config... % [BGP] Unknown command: agentx line 11: Failure to communicate[2] to bgpd, line: agentx Configuration file[/var/etc/frr/frr.conf] processing failure: 2 Starting watchfrr
when its NOT enabled
/bin/sh /usr/local/etc/rc.d/frr.sh restart ... Performing intergrated config test Starting FRR Checking intergrated config... Checking vtysh.conf OK Starting zebra. 2021/03/16 10:57:25 ZEBRA: [EC 4043309111] Disabling MPLS support (no kernel support) Starting staticd. Starting bgpd. Booting for integrated-vtysh-config... Starting watchfrr
As you see the difference and the error
Updated by Yif Swery almost 4 years ago
I think the issue is somewhere in here /usr/local/pkg/frr.inc
in the segment as follows:
/* SNMP */
foreach ($config_key_daemons as $config_key => $daemon) {
$frr_daemon_modules[$daemon[0]] = '';
if ($config['installedpackages'][$config_key]['config'][0]['enablesnmpagentx']) {
$frr_daemon_modules[$daemon[0]] .= ' -M snmp';
}
}
Since its trying to start a daemon that might not support the -M snmp params? thats just a gut feelings though, I could be wrong
Updated by Yif Swery over 3 years ago
Found the issue,
net-snmp is the issue since it sets the agentx file with permissions that could not be accessed by FRR hence FRR crashes.
The fix is to go Services -> SNMP (net-snmp) -> General -> Advance Options
and add
agentxperms 777 777
Updated by Jim Pingle over 3 years ago
- Subject changed from FRR - Failure to communicate[2] to bgpd, line: agentx to NET-SNMP is not setting the correct permissions on AgentX
- Category changed from FRR to NET-SNMP
- Status changed from Feedback to New
Updating issue to reflect that it's really a problem in NET-SNMP.
Setting the permissions to 777/777 seems less than ideal to me since that leaves it wide open to anything. A better way would be to use a group or similar mechanism and grant permissions to the group, then ensure all other packages which access agentx are doing so through a user in that group. That may not be feasible, however, but it needs to be tried before going straight to relaxing permissions.