AgentX Tutorial using Net-SNMP – Simple Scalars

Since no good tutorials are available I put together what I learnt. My approach was step by step learning and that is what I describe here. So on day 1 or step one we will see how to create a simple MIB that has only two simple read-only scalars and how to implement them in the agent. I have configured net-snmpd agentx mode to run on TCP. Check this post on how to configure that.

You should clone my git repository and follow the README which describes the changes made. I have created tags in the git repository so it is easy to reference what is done when and for what.

git clone
git checkout step1_scalars_autogenerated
git checkout step1_scalars_implement


  1. I used net-snmp 5.7.3 for this tutorial.
  2. My test MIB AGENTX-TUTORIAL-MIB is under experimental branch (. so my MIB branch is .
  3. smilint was used to verify that MIB was syntactically correct.
  4. mib2c was used with mib2c.scalar.conf to compile the MIB and generate the code, makefile and agent code.

Now wait for second tutorial where I will implement a simple table using MIB-For-Dummies configuration.

Net-SNMP configuration for non-root AgentX application

It is imperative to run the application when developing it. You may be testing it, debugging it or troubleshooting something. By default Net-SNMP uses named socket for AgentX communication which does not allow a non-root user to connect making troubleshooting difficult. There are security reasons for not allowing this kind of widely open access so do not set this up in your production environment. There are other ways to control the access which I will narrate in future posts.

To enable AgentX and allow non-root applications/Agents to connect to snmpd you can setup TCP socket as follows. TCP socket provides a cleaner access and allows easier troubleshooting e.g you could capture network traffic between snmpd and the AgentX application. Update /etc/snmp/snmpd.conf and ensure that following directives are set for TCP based AgentX communication.

rocommunity public default # or whatever community string/access control you want
master agentx # Run as an AgentX master agent
agentXSocket tcp:localhost:705 # Listen for localhost network connections instead of /var/agentx/master

Restart snmpd (/etc/init.d/snmpd restart)

Alternate is to set correct permissions for /var/agentx/master named socket or whatever you have configured.

Capture local network traffic for multi-homed host

If both end-points of a socket are on local system, network traffic will be seen on loopback interface even if applications are using non-loopback interface (e.g. eth0, wlan0…). Capturing data over loopback is quite obvious. But here I am discussing that applications are using one of the external interfaces (e.g. eth0, eth1, wlan0 …..).

Since both end-points are on  local system, kernel will shunt the traffic and not send it to the wire. The data will be delivered internally by queuing it to the read queue of other end-point. So we cannot capture the traffic on that particular interface, but this traffic is visible on loopback interface. Lets see an example.

I use netcat for setting up our test client and server program. nc -kl 9090 will run server on all interfaces on port 9090. And nc 9090 will setup a client. Here is the external IP of my system(wlan0). Now instead of using the interface name associated with that IP (in my case wlan0), we have to use loopback interface lo to capture the traffic as below.

tcpdump -i lo tcp port 9090

Now anything that is typed on the client terminal when sent will be seen by tcpdump. Problem solved.

vpn : Split Tunnel Concept

Once a user starts a vpn client to connect to company extranet, all network traffic is diverted to the vpn tunnel. Routing gets setup by VPN client such that everything would go down the tunnel. Split tunnel can fix that by keeping traffic for internet from tunnel and only direct extranet traffic to the tunnel. But it comes with few risks on its own. Lets review the concept for a minute.

The VPN tunnel can be configured to work in two modes.

  1. Mandatory (default)
    While a client tunnel is established in mandatory mode, all client traffic is tunneled through it by default. This is the default vpn mode. So accessing will go through vpn tunnel to company extranet which will then route it via its own internet connection after applying access policy etc.
  2. Split Tunneled mode
    Split Tunneling allows configuring specific network routes that are then tunneled and sent to the client’s Extranet adapter; any other traffic goes to the local PC Ethernet or Dialup adapter interface. So Split tunneling allows the user to get access to the Internet or print locally even while the system is tunneled into the company Extranet. But this comes with a security issue because it opens a backdoor into the secure office network from internet via the home system. A hacker can exploit the home system and can use that as a jump box to get into the company network. Or if the system at home is infected it will further that infection into office network. That is why organizations want vpn users to ensure they are up to date and have anti-virus installed and most will provide vpn clients that are tightly controlled to enable the Default mode. Continue reading

snmp : find network information of a system centrally

Anyone can login to a system and run ifconfig or netstat or other similar commands to find the network information of a system. But what will be even better? Do it remotely without logging in to each and every system. How? Using snmpwalk one can retrieve all this information provided that subject has both snmpd running, snmpd supporting network information and the querying host is allowed to make SNMP queries. Lets see how.

Interface table is covered by basic SNMP (just like system information, udp, tcp  socket information, address translation and snmp stats etc). Here is how to query the interface table to get the IP address and Subnet mask information.

unixite@sanbox:~/ > snmpwalk -v1 -c public sandboxS:161
iso. = IpAddress:
iso. = IpAddress:
iso. = IpAddress:
iso. = IpAddress:
unixite@sanbox:~/ > snmpwalk -v1 -c public sandboxS:161
iso. = IpAddress:
iso. = IpAddress:
iso. = IpAddress:
iso. = IpAddress:

First one here retrieves the IP addresses on the system while second one get the subnet masks. -c public has to be changed to right community string and also the version if your supports a different one. My system name here is sandboxS and snmpd is listening on default port 161. If not then you can change the port to match yours.

php : find if IP address is in Network range

Using pear Net_IPv4 module one can find if a given IP address is in provided Network range or on the subnet.

        // check if IP falls in provided subnet

        $ipAddr  = "";
        $netAddr = ""; // -

        $objIP = new Net_IPv4();

        echo $objIP->ipInNetwork($ipAddr, $netAddr) ? "$ipAddr is in $netAddrn" : "$ipAddr is not in $netAddrn";

This requires pear Net_IPv4 module which can be installing in one of the following ways.

pear install Net_IPv4
php pyrus.phar install pear/Net_IPv4

perl : find if IP address is in Network range

Using NetAddr::IP one can find if a given IP address is in provided Network range or on the subnet. This can take many different representations of the subnet address. For example you can throw at it the CIDR (e.g. or explicit start and end addresses (e.g. or even with network mask (e.g. mask Following example shows all of these possible cases.


use NetAddr::IP;

my $ipAddr  = "";
my $netAddr = ""; # -

my $network  = NetAddr::IP->new($netAddr);
#my $network  = NetAddr::IP->new("", "");
#my $network  = NetAddr::IP->new("", "29");
#my $network  = NetAddr::IP->new("");
my $ip = NetAddr::IP->new($ipAddr);

if ($ip->within($network)) {
        print $ip->addr() . " is in same subnetn";
else {
        print $ip->addr() . " is outside the subnetn";

There are multiple ways the input for network can be provided (four ways are shown above with 3 commented).