SNMP V3 - SNMP

This is a discussion on SNMP V3 - SNMP ; I have been snmpget'ing system.sysUpTime.0 from my client's RH 7.0 - 7.3 based machines for some time. I recently upgraded a client's machine and used RH 9.0. I had to change the snmpget statement to look like: snmpget -v 1 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: SNMP V3

  1. SNMP V3

    I have been snmpget'ing system.sysUpTime.0 from my client's RH 7.0 - 7.3 based machines for some time. I
    recently upgraded a client's machine and used RH 9.0. I had to change the snmpget statement to look like:
    snmpget -v 1 -c public localhost system.sysUpTime.0
    and that works but I need to poll the machine over the internet. When I issue the query from my machine
    (where I text message my phone if the machine is off the net for X # of successive failures) it always times
    out. I noticed there's instructions to map the community name into a security name. The example shows
    headings sed.name SOURCE community and the item under SOURCE shows network/24. Can someone tell me how I
    express the IP address of the machine in the example so I can query uptime over the Internet?


  2. Re: SNMP V3

    rowan wrote:

    > I noticed there's instructions to map the community name into a
    > security name. The example shows
    > headings secname SOURCE community and the item under SOURCE shows
    > network/24. Can someone tell me how I express the IP address of the
    > machine in the example so I can query uptime over the Internet?


    The simplest approach is to use the directive

    rocommunity COMMUNITY

    which will allow (read-only) access from anywhere.
    If you want to restrict things to a particular range of network addresses
    then something like

    rocommunity COMMUNITY 12.34.56.0/24

    will allow access from 12.34.56.1 through to 12.34.56.255
    (the /24 means "match 24 bits" - i.e. the first three octets)

    If you need to allow access from two ranges of network addresses
    (and the same community string), then yes - you'll need to use the
    com2sec/group/view/access directives.
    Try something like

    com2sec mynet COMMUNITY 12.34.56.0/24
    com2sec melocal COMMUNITY 127.0.0.1
    group us v1 mynet
    group us v1 melocal
    view all ,1
    access us "" v1 noauth 0 all none none

    (And that's exactly why we supply the "rocommunity" and
    "rwcommunity" directives!)


    Dave

  3. Re: SNMP V3

    Dave Shield wrote:
    > rowan wrote:
    >
    >
    >> I noticed there's instructions to map the community name into a
    >>security name. The example shows
    >>headings secname SOURCE community and the item under SOURCE shows
    >>network/24. Can someone tell me how I express the IP address of the
    >>machine in the example so I can query uptime over the Internet?

    >
    >
    > The simplest approach is to use the directive
    >
    > rocommunity COMMUNITY
    >
    > which will allow (read-only) access from anywhere.
    > If you want to restrict things to a particular range of network addresses
    > then something like
    >
    > rocommunity COMMUNITY 12.34.56.0/24
    >
    > will allow access from 12.34.56.1 through to 12.34.56.255
    > (the /24 means "match 24 bits" - i.e. the first three octets)
    >
    > If you need to allow access from two ranges of network addresses
    > (and the same community string), then yes - you'll need to use the
    > com2sec/group/view/access directives.
    > Try something like
    >
    > com2sec mynet COMMUNITY 12.34.56.0/24
    > com2sec melocal COMMUNITY 127.0.0.1
    > group us v1 mynet
    > group us v1 melocal
    > view all ,1
    > access us "" v1 noauth 0 all none none
    >
    > (And that's exactly why we supply the "rocommunity" and
    > "rwcommunity" directives!)
    >
    >
    > Dave


    Dave, thanks for the follow-up. I tried several variations of above but nothing worked. I then moved the
    snmpd.conf to a backup and use the
    snmpconf -g basic_setup
    command to create one from scratch. The snmpconf program wrote a line into the new snmpd.conf file with the line
    rocommunity public
    I restarted the snmp daemon and was able to get system.sysUpTime.0 on the local machine but again I am not
    able to get it from across the Internet. I verified the Linksys is directing port 161 to the private IP
    address (192.168.2.202). Anything else I can try?



  4. Re: SNMP V3

    rowan wrote:
    > The snmpconf program wrote a line
    > into the new snmpd.conf file with the line rocommunity public
    > I restarted the snmp daemon and was able to get system.sysUpTime.0 on the
    > local machine but again I am not
    > able to get it from across the Internet.


    OK - two possibilities spring to mind:

    a) The 'snmpd' agent is using the 'hosts.allow' file as an
    additional level of access control.
    Try putting an entry in there to allow general access.

    b) You've got kernel-level traffic filtering, which is
    discarding the request before it ever gets to the agent.
    Try checking the iptables configuration.


    If you run the agent in packet dump mode ('snmpd -d -f -L') and probe
    it from the remote box, that might indicate which is the more likely.
    If you see incoming PDUs but nothing sent back, then it's probably
    hosts.allow. If you don't see anything at all (except for requests
    from localhost), then it's probably kernel level filtering.


    Dave


  5. Re: SNMP V3

    Dave Shield wrote:
    > rowan wrote:
    >
    >> The snmpconf program wrote a line
    >>into the new snmpd.conf file with the line rocommunity public
    >>I restarted the snmp daemon and was able to get system.sysUpTime.0 on the
    >>local machine but again I am not
    >>able to get it from across the Internet.

    >
    >
    > OK - two possibilities spring to mind:
    >
    > a) The 'snmpd' agent is using the 'hosts.allow' file as an
    > additional level of access control.
    > Try putting an entry in there to allow general access.
    >
    > b) You've got kernel-level traffic filtering, which is
    > discarding the request before it ever gets to the agent.
    > Try checking the iptables configuration.
    >
    >
    > If you run the agent in packet dump mode ('snmpd -d -f -L') and probe
    > it from the remote box, that might indicate which is the more likely.
    > If you see incoming PDUs but nothing sent back, then it's probably
    > hosts.allow. If you don't see anything at all (except for requests
    > from localhost), then it's probably kernel level filtering.
    >
    >
    > Dave
    >


    Dave, I could not get snmpd to load with -d -f -L it would hang. I put the IP address into the
    /etc/host.allow file and am now able to query the device with snmpget. Thanks for you help.


+ Reply to Thread