October 11, 2011


Support for Unknown Devices

Virtually any SNMP device can be managed by NeDi and I don’t just mean reading some default MIBs. All you need is a .def file which resides in the sysobj folder. In addition CLI support can be added by following the steps in the tutorial or even editing libcli-iopty.pm, but that’s a bit trickier…

Defining Devices

If an unknown device is discovered, you can create a definition file and assign an icon to it, with that it can be properly supported within NeDi.

The easiest way is through Defgen, which can be invoked by clicking on the sysobj value in Devices-List or the triangle icon in Devices-Status. Consult the help (life-saver icon on top) or have a look at the tutorial to learn how to use Defgen.

Device Icons

In order to provide some sort of consistency while not limiting expanding device support, I’ve come up with this scheme, which should cover most of the device types out there. A few exceptions exist, mainly concerning printers and supervisor(s). Use the browser in Defgen to select the icon according to the following scheme…


The top-level distinction (vendor) is made with the main color:

Vendor Color
Cisco blue
Dell (Force10) cyan
HP green
Avaya (Nortel) orange
Extreme purple
Alcatel-Lucent yellow
Brocade (Foundry) red
Other black

Bold charactar is substituted below for the x. In addition some icons use shades (d=dark,n=normal,p=pale) to differentiate between device size:


Type Subtype Shade Icon Name
Workgroup (L2) ~12 Port pale w2xp
Workgroup (L2) ~24 Port normal w2xn
Workgroup (L2) ~48 Port dark w2xd
Workgroup (L3) ~12 Port pale w3xp
Workgroup (L3) ~24 Port normal w3xn
Workgroup (L3) ~48 Port dark w3xd
Chassis (L2) small pale c2xp
Chassis (L2) medium normal c2xn
Chassis (L2) big dark c2xd
Chassis (L3) small pale c3xp
Chassis (L3) medium normal c3xn
Chassis (L3) big dark c3xd
Switch Processor spxn
Router small rsxn
Router medium rmxn
Router big rbxn
Firewall boxed fwxn
Firewall virtual fvxn
VPN GW/HW Client vpxn
Appliance apxn
Content Switch (GW) csxn
Load Balancer lbxn
IP Phone phxn
Wlan Access Point waxn
Wlan Bridge wbxn
Wlan Controller wcxn
Sensor sexn
Video Conference System ivxn
IP Camera icxn
Bladeserver Chassis bsxn
Server (ILO) svxn
Cloud (dummy device) clxn
Fiberchannel Switch fcxn
Storage stxn
Hypervisor hvxy
Virtual Switch vsxn
ATA box (VoIP converter) atxn
DSLAM (xdsl switch) dsxn
Fiber converter fixn
Printer (color, bw) pcxn,pgxn
Stack skxn
Hub w1xn


NeDi’s API allows reading data from a table. You can use basic-auth with GET request or submit credentials as well with POST:

GET or POST options:

  • t table (prepend with COUNT to count values instead listing them)
  • q query in the form of column (= LIKE < > | &) string
  • o order column (prepend with – for descending)
  • l limit number[,offset]
  • m mode csv also returns load and available memory in the 1st row (default is json)

POST only:

  • u user
  • p password

It uses query.php, which can be presented intuitively with a rewrite rule:

rewrite rule for nginx

location /api {
rewrite ^/api/(\w*)$ /query.php?t=$1&q=$args last;

I recommend using RESTClient for Firefox or the Chrome extension “postman” for testing:

As you can see, the rewrite rule assigns the path after API/ to the table (t) variable and the optional query to q…

Without rewrite rule, the API can be used like this:

Queries can be worked out with regular GUI modules. As admin, click on the ladybug in the top right corner to enter debug mode. You can click on a query to examine it further in System-Export. This export module is helpful to explore the database structure as well.

Due to the fact that queries can circumvent NeDi’s tenant filters, the user cannot have a “Filter Devices” set in User-Management.