Battery power bank, WiFi USB stick, and thumb drive

I then turn away to motor-less small storage, a 32 Gigs USB thumb drive so I can move on to other concern: on-the-fly encryption. Hence, I follow instructions to install True Crypt on Raspberry Pi. After unpacking of wxWidgets-2.8.12.tar.gz and TrueCrypt 7.1a Source.tar.gz in place, putting header files from pkcs-11-cryptoki2.20, and then install libfuse-dev, the following make will require long time:

$ export PKCS11_INC=/usr/local/src/truecrypt/pkcs/
 
$ make NOGUI=1 WX_ROOT=/usr/src/wxWidgets wxbuild
Configuring wxWidgets library...
Building wxWidgets library...
/usr/src/wxWidgets/src/common/string.cpp:84:39: warning: ‘wxEmptyString’ initialized and declared ‘extern’ [enabled by default]

$ make NOGUI=1 WX_ROOT=/usr/src/wxWidgets wxbuild
Compiling Buffer.cpp
Compiling Exception.cpp
Compiling Event.cpp
...
../Crypto/Aeskey.c:527:25: warning: operation on ‘ss[7]’ may be undefined [-Wsequence-point]
../Crypto/Aeskey.c:527:25: warning: operation on ‘ss[7]’ may be undefined [-Wsequence-point]
../Crypto/Aeskey.c:527:25: warning: operation on ‘ss[7]’ may be undefined [-Wsequence-point]
...
Converting Language.xml
Compiling Resources.cpp
Linking truecrypt

I created the TrueCrypt volume separately via its desktop GUI with ext3 file system to then mount it in Pi to a configured Samba share. As pointed out in a post, the following changes are added to smb.conf

...
wins support = yes
...
[pitruecrypt]
   comment= Pi Truecrypt Volume
   path=<the mount path of the USB thumb drive TrueCrypt volume>
   browseable=Yes
   writeable=Yes
   only guest=no
   create mask=0777
   directory mask=0777
   public=no

and then user-password are entered via interactive command.

For mobility, I already had the Pi as WiFi access point using hostapd (check these steps) and power bank, so it’s now matter of performance. In the case of rsync, initial sync of some 1,500 items totaling in 1 Gig size elapses in approximately the same 12 minutes of time compared to one bulk file of the same size. Of course, over the next incremental sync, it only takes less than a minute for the thousand items to just update slight differences.

Security

Back to security, there surely risk by opening Samba share to mounted TrueCrypt volume. But, for me it would be practically manageable (cross my finger). There is more concern to the fate of TrueCrypt after it is being closed in such a weird way, given that last audit finds nothing severe. Anyway, I found brute force tool, but no critical attack exists currently, unless e.g. it stays powered on and mounted, the person gain physical access. Beats me again.

Low level view of WPAD interactions involving DHCP, DNS, and HTTP servers in packet capture (shared in CloudShark)

In DHCP discovery-offer-request-acknowledgement cycle, WPAD information is given in option 252 (check section 4.4.1 of the draft). I used dhcpd3-server package in Ubuntu and setup /ip dhcp-server option add code=252 ... in Mikrotik 5.20 for example variations. For both, trailing “\n” are added to wpad.dat URL value as most howtos recommend.

"http://wpad.some-company.net/wpad.dat\n"

In the above example value, wpad.dat is hosted in Apache2 HTTP server resolvable by the DNS to the actual host IP of wpad.some-company.net. When the client use all DHCP offered items, it gets domain name (option 15) some-company.net besides other things e.g. router (option 3), DNS (option 6), etc. In a case where the client use its own DNS (only use IP from DHCP), WPAD likely won’t work unless it is able to resolve the example some-company.net or wpad.some-company.net. Following the tail of /var/log/apache2/access.log, successful wpad.dat request will appear as

192.168.40.75 - - [01/May/2013:21:51:15 +0700] "GET /wpad.dat HTTP/1.1" 200 1070 "-" "-"

In the above tail, I enabled a Windows 7′s network adapter (from previously disabled) and it would soon try to HTTP GET the wpad.dat even when no browser opened yet.

From testing with Windows XP, Windows 7, and Ubuntu (with different browsers mostly), DHCP Inform‘s WPAD behavior can be seen with Windows 7 test by analyzing the packet going out after some time since the initial DHCP stream (check the packet capture for 7 seconds after DHCP Discover). It asked for WPAD in one of the Parameter Request List Item (apply the filter bootp.option.request_list_item == 252 for a closer look), but received no answer.

I failed to reproduce other samples of DHCP Inform packet asking for WPAD. Hence, for the rest, it’s the browser who is doing the GET to http://wpad.some-company.net/wpad.dat with DHCP only supplied domain name instead of complete WPAD (check another packet capture, this time for Ubuntu with Firefox 20). The GET attempt isn’t actually one shot attempt. When it fails to find the wpad.dat in http://wpad.some-company.net/wpad.dat, it should iteratively try to find within the higher domain e.g. http://some-company.net/wpad.dat.

Getting proxy setting (WPAD) from DHCP or directly by browser iterative decision

DHCP server configuration used, wpad.dat file example (I simply use symbolic link to proxy.pac), and Apache2 VirtualHost config are available in my github, an attempt to integrate Squid3 cache with WPAD, PAC, and DHCP.

History

For trailing character in WPAD value mentioned earlier, I once configured option 252 value with “wpad.dat\?“, “proxy.pa“, and some other likely wrong variations. I also configured the browser in Windows XP and 7 with these variations of wrong values before getting the browser to use proxy auto-discovery again. Somehow it kept the wrong GET with trailing character resulting in 404 (page not found):

1. Firefox

192.168.40.78 - - [30/Apr/2013:16:20:39 +0700] "GET /wpad.dat/ HTTP/1.1" 404 478 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Win32)"

2. IE 6

192.168.40.78 - - [30/Apr/2013:16:28:07 +0700] "GET /wpad.dat/ HTTP/1.1" 404 478 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Win32)"

3. IE 8

192.168.40.77 - - [01/May/2013:20:07:24 +0700] "GET /wpad.dat/? HTTP/1.1" 404 534 "-" "-"

I was able to force it to GET the correct WPAD value by adding new network adapter which received different IP lease from DHCP server. Afterwards, connecting with the old adapter will also keep correct behavior.

I still don’t know how they keep the previously incorrect behavior. In short we can’t rely on WPAD alone, but there is probability that some portions of the network clients will find the proxy this way, automatically without technical assistance.

$ sudo service squid3 {start|stop|restart}

To specify what to run, an upstart must have exec or script stanza. When the goal is to start two or more (multiple) instances of squid3, exec is meant to replace existing process image of /usr/sbin/squid3 executable, therefore will not start two instances.

Multiple squid3 instances started via upstart exec

As workaround we can have symbolic link to squid3 executable instead and add new upstart job configuration with exec call to the link. I need two instances running in the same machine due to the implementation design where the fist instance is HTTP proxy cache while the second one is accelerator/interceptor (reverse proxy) that serves default landing page telling user to use proxy (and how to do that). Hence, for the second instance I add:

lrwxrwxrwx 1 root root 6 May  3 09:25 /usr/sbin/squid3ins2 -> squid3
-rw-r--r-- 1 root root 1156 May  6 13:30 /etc/init/squid3ins2.conf

and for the first instance I add:

-rw-r--r-- 1 root root 298 May  3 10:13 /etc/init/squid3.override

squid3ins2 is our link and /etc/init/squid3ins2.conf contains exec call to it to run second squid3. For the first instance I choose to write an override (/etc/init/squid3.override) so that the original job configuration file is left intact. For the complete content of all files check my github v1.1 of the Squid integration. There, in details you’ll also find how both instances PID, log, etc. are differentiated by each instance config via the following directives:

http_port
cache_dir
pid_filename
cache_access_log
cache_log

Background:
I need to setup an HTTPS site with not just server certificate to secure it, but requiring also client side certificate. The site will only show the content to authorized users with the correct pair of server-client certificate. It will also expire after a certain date. The certificates are self-signed as they’re for closed environment usage.

This post covers two general processes: generating and signing.

How to generate SSL certificate using openssl is a straightforward process of:

1. generate its key
2. create certificate request with that key
3. generate certificate from request and key

Hence, in any type of the certificate I have a general <some-cert-key>.key, <some-cert-request>.csr, and <some-cert>.crt. When I mean “type”, they are CA (Certificate Authority), one/more server certificate, and one/more client certificate.

Generating Pairs of Key-Certificate with openSSL: CA, server, & client

In terms of signing the certificates, all of them are signed using the CA. Which files to be used in the server will become the subject of the next post.

openssl will run interactively. To go through all the recurring questions using prepared default answers, we need to create a config file first. I created caconfig.cnf (find it on the bottom of the post) and use -config caconfig.cnf option in some commands.

First, prepare set of directories to clearly separate what we’re working on (keys, requests, and resulting certificates in different places for server and user):

mkdir certs
mkdir private
mkdir server
mkdir server/certs
mkdir server/creqs
mkdir server/ckeys
mkdir user
mkdir user/certs
mkdir user/creqs
mkdir user/ckeys

Prepare “database” and index number to keep track of certificates issued:

echo 01 > serial
touch index.txt

Generate the CA: (again) generate key, create request (the interactive part), and create certificate:

openssl genrsa -out private/myCA.key 2048
openssl req -new -key private/myCA.key -out certs/myCA.csr -config caconfig.cnf 
openssl req -x509 -days 365 -in certs/myCA.csr -out certs/myCA.crt -key private/myCA.key

We can always check:

openssl x509 -in certs/myCA.crt -text

Now, generating for the server, I use the name lakmus as an example. First the key:

openssl genrsa -des3 -out server/ckeys/lakmus.key 2048

(Triple-DES cipher will ask for pass phrase of 4 characters minimum)

Enter pass phrase for server/ckeys/lakmus.key:
Verifying - Enter pass phrase for server/ckeys/lakmus.key:

Then, the request (which will ask for the above key pass phrase):

openssl req -new -key server/ckeys/lakmus.key -out server/creqs/lakmus.csr -config caconfig.cnf

Note that organizationName field needs to be the same with the CA certificate.

Then, signing it with the CA (and again check as text):

openssl ca -days 365 -in server/creqs/lakmus.csr -cert certs/myCA.crt -out server/certs/lakmus.crt -keyfile private/myCA.key -config caconfig.cnf
 
openssl x509 -in server/certs/lakmus.crt -text

During signing we’ll see something like (expiry date and validity periode)

Certificate is to be certified until <some date> (365 days)
Sign the certificate? [y/n]:

and index.txt is updated:

V	140123034822Z		01	unknown	/C=ID/ST=WEST JAVA/O=My Organization/CN=lakm.us
V	140123041441Z		02	unknown	/C=ID/ST=WEST JAVA/O=My Organization/CN=client

Finally, the same generate with own key and sign with CA except this time is for client:

openssl genrsa -des3 -out user/ckeys/client1.key 2048
openssl req -new -key user/ckeys/client1.key -out user/creqs/client1.csr -config caconfig.cnf
 
openssl ca -in user/creqs/client1.csr -cert certs/myCA.crt -keyfile private/myCA.key -out user/certs/client1.crt -config caconfig.cnf 
 
openssl x509 -in user/certs/client1.crt -text

For the client certificate to be usable when importing to browser, convert it to PKCS 12

openssl pkcs12 -export -clcerts -in user/certs/client1.crt -inkey user/ckeys/client1.key -out user/certs/client1.p12

It will ask for pass phrase and export password (that will be prompted when importing to browser)

Enter pass phrase for user/ckeys/client1.key:
Enter Export Password:
Verifying - Enter Export Password:

Troubleshooting

If the CA generation already worked smoothly, it is better to remove the key, request, and certificate files of subsequent signing process before repeating them when any error is found. Otherwise it will finally show error such as:

failed to update database
TXT_DB error number 2

Or something like

No certificate matches private key

when exporting to PKCS 12.

We can check the index.txt, index.old, serial, and serial.old to figure our situation by evaluating indexes of signed certificate.

CA Config

I used parts from Code Ghar post for my caconfig.cnf:

[ ca ]
default_ca = CA_default
[ CA_default ]
dir = /home/arif/ssl
serial = $dir/serial
database = $dir/index.txt
new_certs_dir = $dir/certs
certificate = $dir/certs/myCAcert.crt
private_key = $dir/private/myCA.key
default_days = 365
default_md = md5
preserve = no
email_in_dn = no
nameopt = default_ca
certopt = default_ca
policy = policy_match
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[ req ]
default_bits = 2048 # Size of keys
default_keyfile = key.pem # name of generated keys
default_md = md5 # message digest algorithm
string_mask = nombstr # permitted characters
distinguished_name = req_distinguished_name
[ req_distinguished_name ]
# Variable name Prompt string
#------------------------- ----------------------------------
0.organizationName = Organization Name (company)
organizationalUnitName = Organizational Unit Name (department, division)
emailAddress = Email Address
emailAddress_max = 40
localityName = Locality Name (city, district)
stateOrProvinceName = State or Province Name (full name)
countryName = Country Name (2 letter code)
countryName_min = 2
countryName_max = 2
commonName = Common Name (hostname, IP, or your name)
commonName_max = 64
# Default values for the above, for consistency and less typing.
# Variable name Value
#------------------------ ------------------------------
0.organizationName_default = My Organization
localityName_default = BOGOR
stateOrProvinceName_default = WEST JAVA
countryName_default = ID
emailAddress_default = fake@lakm.us
commonName_default = lakm.us

Installing RPMs from Geekymedia seems to be the easiest. I only need the following to make it work:

1. python26-2.6-geekymedia1.i386.rpm
2. python26-libs-2.6-geekymedia1.i386.rpm

Eltek Smartpack Controller rear view (type that comes with SNMP support)

It is presumably in its default configuration and I can snmpwalk through its corporate specific OIDs (under 12148 tree) to find i.e. output voltage, current, battery temperature, etc. Doing it without translating against the MIB will retrieve all the values perfectly fine. However, I want to show you a mistake in practice related to how the MIB is written and put to place, which is a version 4 by the name of ELTEK-DISTRIBUTED-PLANTV4-MIB. It has tabular part as clipped in the following tree (see previous post on how to write such part in your own MIB):

            |     +--eltek(12148)
            |        |
            |        +--eltekDistributedPlantV4(9)
...
            |           |
            |           |     |
            |           |     +--rectifierStatusTable(2)
            |           |        |
            |           |        +--rectifierStatusEntry(1)
            |           |           |  Index: rectifierStatusID
            |           |           |
            |           |           +-- -R-- Integer32 rectifierStatusID(1)
            |           |           |        Range: 1..100
...
            |           |           +-- -R-- Integer32 rectifierStatusOutputVoltage(4)
            |           |           |        Range: 0..65535

Looking at the above rectifierStatusEntry branch, it marks a tabular entry expected to range from 1 to 100 as defined by rectifierStatusID. Hence, putting 0 as one of the output voltage index will confuse the OID reported by GET as

1. belong to the scalar type (a misconception that is)
2. belong to the tabular type but out of index range

GET against the MIB will return the following error

$ sudo snmpget -m +ELTEK-DISTRIBUTED-PLANTV4-MIB -v 1 -c public raddlex ELTEK-DISTRIBUTED-PLANTV4-MIB::rectifierStatusOutputCurrent.0
ELTEK-DISTRIBUTED-PLANTV4-MIB::rectifierStatusOutputCurrent.0: Unknown Object Identifier (Index out of range: 0 (rectifierStatusID))

while the item (output current) actually has value in it as found below

$ sudo snmpget -v 1 -c public raddlex .1.3.6.1.4.1.12148.9.5.5.2.1.3.0
SNMPv2-SMI::enterprises.12148.9.5.5.2.1.3.0 = INTEGER: 1

By this time the MIB is already the latest to be used with firmware version 4.3.

ioctl[SIOCSIWENCODEEXT]: Invalid argument
ioctl[SIOCSIWENCODEEXT]: Invalid argument

TP Link TL-WN321G USB WiFi Stick

Within minutes it will also crash the system with messages similar to:

kernel: [ 5645.279693] SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) thaw-filesystems(J) saK show-backtrace-all-active-cpus(L) show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) unRaw Sync show-task-states(T) Unmount ETM buffer dump show-blocked- tasks(W) dump-ftrace-buffer(Z)

The correct way to attach is

wpa_supplicant -B -Dnl80211 -iwlan0 -c/etc/wpa_supplicant.conf

The config file content is just like what the community help suggested. The stick with vendor & product ID of 148f:2573 has been part of the nl80211 development at Linux Wireless.

wpa_supplicant version is v0.7.3. Ubuntu version is 11.10 as described further in previous post.

$ modprobe -v usbserial vendor=0x05c6 product=0x0015

or (2) usb-modeswitch, (3) Matthias Urlichs initially wrote option.c driver as a way to insert USB modem as kernel module.

This driver exists because the “normal” serial driver doesn’t work too well
with GSM modems. Issues:
- data loss — one single Receive URB is not nearly enough
- nonstandard flow (Option devices) control
- controlling the baud rate doesn’t make sense

Most modems will be successfully attached with this driver, appearing in one of the typical /dev/ttyUSB0 to /dev/ttyUSB2. The product ID 0x0015 for GSM modem compiled here is a Qualcomm (vendor ID 0x05c6) OEM modem I received from Embest DevKit8500D order. There are more than one form factor when searching for its images on Google. Closest one we have in Indonesia is ADVAN DT8-HT bundled in Telkomsel Flash.

Qualcomm 05c6:0015 from Indonesian operator

I’m compiling it for the Beagleboard xM Rev C running Ubuntu Oneiric (installed in this post). A quick look gives:

$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 005: ID 05c6:0015 Qualcomm, Inc.

The above 0x0015 product ID doesn’t exist inside option.c of linux kernel 3.0.0-12 source. Adding this to series of existing Qualcomm modems gives:

635
636
637

	{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6000)}, /* ZTE AC8700 */
	{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */
	{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0015)}, /* Qualcomm no brand */

The include also needs usb-wwan.h from that kernel source. Copy them both under /usr/src/linux-headers-3.0.6-x3/drivers/usb/serial/. For other include files, install:

1. linux-headers-3.0.0-12_3.0.0-12.20_all.deb
2. linux-image-3.0.0-12-omap_3.0.0-12.20_armel.deb

and create this link as root

1
2

$ cd /usr/src/linux-headers-3.0.6-x3/include/
$ ln -s /usr/src/linux-headers-3.0.0-12/arch/arm/mach-versatile/include/mach mach

After removing the old one (pointed to build -> /build/buildd/linux-3.0), create a link inside /lib/modules/3.0.6-x3 named build pointing to:

build -> /usr/src/linux-headers-3.0.6-x3

Modify the original Makefile to contain only rule for option.o

obj-m			+= option.o

and then build the driver

$ make -C /lib/modules/3.0.6-x3/build/ M=/usr/src/linux-headers-3.0.6-x3/drivers/usb/serial/
make: Entering directory `/usr/src/linux-headers-3.0.6-x3'
  LD      /usr/src/linux-headers-3.0.6-x3/drivers/usb/serial/built-in.o
  CC [M]  /usr/src/linux-headers-3.0.6-x3/drivers/usb/serial/option.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /usr/src/linux-headers-3.0.6-x3/drivers/usb/serial/option.mod.o
  LD [M]  /usr/src/linux-headers-3.0.6-x3/drivers/usb/serial/option.ko
make: Leaving directory `/usr/src/linux-headers-3.0.6-x3`

Copy the build and deploy

$ cp /usr/src/linux-headers-3.0.6-x3/drivers/usb/serial/option.ko /lib/modules/3.0.6-x3/kernel/drivers/usb/serial/
$ depmod -a

Now syslog will show the following lines if the modem is inserted:

kernel:[ 4790.229888] usb 1-2.5: GSM modem (1-port) converter now attached to ttyUSB0
kernel:[ 4790.237121] option 1-2.5:1.0: GSM modem (1-port) converter detected
kernel:[ 4790.238250] usb 1-2.5: GSM modem (1-port) converter now attached to ttyUSB1
kernel:[ 4790.240142] option 1-2.5:1.1: GSM modem (1-port) converter detected
kernel:[ 4790.241210] usb 1-2.5: GSM modem (1-port) converter now attached to ttyUSB2
mtp-probe: checking bus 1, device 9: "/sys/devices/platform/usbhs-omap.0/ehci-omap.0/usb1/1-2/1-2.5"
mtp-probe: bus: 1, device: 9 was not an MTP device
kernel:[ 4791.227294] scsi 2:0:0:0: Direct-Access     Qualcomm MMC Storage      2.31 PQ: 0 ANSI: 2
kernel:[ 4791.232238] sd 2:0:0:0: Attached scsi generic sg0 type 0
kernel:[ 4791.246887] sd 2:0:0:0: [sda] Attached SCSI removable disk

$ snmpwalk -m +REKTRONIK-MIB -v 1 -c public monitored-host .1.3.6.1.4.1.38610
...
REKTRONIK-MIB::battery1Voltage.0 = INTEGER: 9
REKTRONIK-MIB::battery2Voltage.0 = INTEGER: 11
...

If additional 3rd battery is to be monitored, REKTRONIK-MIB.txt in this example must be modified. In small scale we don’t need consistent MIB as changes are manageable, but if a whole bunch of different people must reference to this, a better way is to have tabular object where the above batteries are indexed instead of ended with “.0” scalar identifier.

Quick approach by checking established LM-SENSORS-MIB.txt shows at least we need three object definitions inside the MIB file:

Components of writing tabular MIB

Its stemmed MIB tree to show the (1) Table, (2) Entry, and (3) Index:

...
            |     |  |     +--lmFanSensorsTable(3)
            |     |  |     |  |
            |     |  |     |  +--lmFanSensorsEntry(1)
            |     |  |     |     |  Index: lmFanSensorsIndex
            |     |  |     |     |
            |     |  |     |     +-- -R-- Integer32 lmFanSensorsIndex(1)
            |     |  |     |     |        Range: 0..65535
...

Now the writing part of those three types to our MIB, plus the batteryVoltage which is the actual object to be indexed in the final SNMP monitoring.

75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116

batteryTable OBJECT-TYPE
    SYNTAX     SEQUENCE OF BatteryEntry
    MAX-ACCESS not-accessible
    STATUS     current
    DESCRIPTION
        "The (conceptual) table of batteries contained by the
        module."
    ::= { monitor 1 }
 
batteryEntry OBJECT-TYPE
    SYNTAX     BatteryEntry
    MAX-ACCESS not-accessible
    STATUS     current
    DESCRIPTION
        "A (conceptual) entry for one battery contained by
        the module.  The batteryIndex in the index represents
        the entry in the batteryTable that corresponds to the
        batteryEntry.
 
        As an example of how objects in this table are named,
        an instance of the batteryVoltage object might be
        named batteryVoltage.3"
    INDEX { batteryIndex }
    ::= { batteryTable 1 }
 
batteryIndex OBJECT-TYPE
    SYNTAX      DeviceIndex
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "A unique value, greater than zero, for each battery. 
            It is recommended that values are assigned contiguously
            starting from 1."
    ::= { batteryEntry 1 }
 
batteryVoltage    OBJECT-TYPE 
   SYNTAX Integer32 
   ACCESS read-only 
   STATUS current 
   DESCRIPTION 
      "Voltage A/D value" 
   ::= { batteryEntry 2 }

There are some header parts of course, check the resulting REKTRONIK-MIB.txt here.

The tree view becomes:

            +--private(4)
            |  |
            |  +--enterprises(1)
            |     |
            |     +--rektronik(39559)
...
            |        |
            |        +--monitor(2)
            |        |  |
            |        |  +--batteryTable(1)
            |        |  |  |
            |        |  |  +--batteryEntry(1)
            |        |  |     |  Index: batteryIndex
            |        |  |     |
            |        |  |     +-- -R-- Integer32 batteryIndex(1)
            |        |  |     |        Textual Convention: DeviceIndex
            |        |  |     |        Range: 1..2147483647
            |        |  |     +-- -R-- Integer32 batteryVoltage(2)
            |        |  |     +-- -R-- Integer32 batteryCurrent(3)
            |        |  |
            |        |  +--environment(2)
            |        |  |  |
            |        |  |  +-- -R-- Integer32 temperature(1)
            |        |  |  +-- -R-- Integer32 humidity(2)
...

and example of getting SNMP is

$ snmpwalk -m +REKTRONIK-MIB -v 1 -c public monitored-host .1.3.6.1.4.1.38610
REKTRONIK-MIB::name.0 = STRING: "RekMini"
REKTRONIK-MIB::version.0 = STRING: "1.0"
REKTRONIK-MIB::date.0 = STRING: "2011-09-08"
REKTRONIK-MIB::batteryIndex.22 = INTEGER: 22
REKTRONIK-MIB::batteryIndex.23 = INTEGER: 23
REKTRONIK-MIB::batteryVoltage.22 = INTEGER: 9
REKTRONIK-MIB::batteryVoltage.23 = INTEGER: 11
REKTRONIK-MIB::batteryCurrent.22 = INTEGER: 2
REKTRONIK-MIB::batteryCurrent.23 = INTEGER: 2
...

in the above example any additional 3rd battery voltage insertion will be OID “REKTRONIK-MIB::batteryVoltage.24“

First put the Microchip.TXT (the MIB file) under /usr/share/snmp/mibs to easily exchange OID canonical form and name vice versa while making dummy. In this case I’ve modify the MIB to have some additional object i.e. name:
$ snmptranslate -m +Microchip -On Microchip::name
.1.3.6.1.4.1.17095.1.1
so we can then use this correct OID for our dummy.

How?

1. use SetMIBValue() in r1.pl

   $agent->SetMIBValue( '.1.3.6.1.4.1.17095.1.1', ASN_OCTET_STR, "Microchip");
   $agent->SetMIBValue( '.1.3.6.1.4.1.17095.3.13', ASN_INTEGER, 82);

2. Feed r1.snmp for playing as in

   $agent->ParseDataFile( '/usr/local/etc/snmp-emulator/r1.snmp', 0 )

   with the content of

   .1.3.6.1.4.1.17095.1.1 = STRING: Microchip
   .1.3.6.1.4.1.17095.3.13 = INTEGER: 82

In all above two examples we can only GET for Raddle to return an answer for each OID. GETNEXT as in bulk snmpwalk won’t give output because they are not sequenced.

A sample of sequenced data inside a real snmpwalk dump is:

$ snmpwalk -v 1 -c public -On localhost
 
.1.3.6.1.2.1.1.1.0 = STRING: Linux xp-racy 2.6.38-10-generic #46~lucid1-Ubuntu SMP Wed Jul 6 18:40:11 UTC 2011 i686
.1.3.6.1.2.1.1.2.0 = OID: .1.3.6.1.4.1.8072.3.2.10
.1.3.6.1.2.1.1.3.0 = Timeticks: (496371) 1:22:43.71
.1.3.6.1.2.1.1.4.0 = STRING: Root  (configure /etc/snmp/snmpd.local.conf)
.1.3.6.1.2.1.1.5.0 = STRING:
.1.3.6.1.2.1.1.6.0 = STRING: Unknown (configure /etc/snmp/snmpd.local.conf)
.1.3.6.1.2.1.1.8.0 = Timeticks: (0) 0:00:00.00
.1.3.6.1.2.1.1.9.1.2.1 = OID: .1.3.6.1.6.3.10.3.1.1
.1.3.6.1.2.1.1.9.1.2.2 = OID: .1.3.6.1.6.3.11.3.1.1

thus, we can only

$ snmpget -m +Microchip -v 1 -c public localhost Microchip::control.13
Microchip::control.13 = INTEGER: 82

or from other system with no Microchip MIB use

$ snmpget -v 1 -c public 192.168.40.105 .1.3.6.1.4.1.17095.3.13
SNMPv2-SMI::enterprises.17095.3.13 = INTEGER: 82

The tree below may visually explains sequenced data for GETNEXT where our Microchip is branched at private.enterprises.microchip :

$ snmptranslate -m +Microchip -Tp
 
+--iso(1)
   |
   +--org(3)
      |
      +--dod(6)
         |
         +--internet(1)
            |
            +--directory(1)
            |
            +--mgmt(2)
            |  |
            |  +--mib-2(1)
            |     |
            |     +--system(1)
            |     |  |
...
            +--private(4)
            |  |
...
            |  +--enterprises(1)
            |     |
...
            |     +--microchip(17095)
            |        |
            |        +--product(1)
            |        |  |

How GET and GETNEXT appeared in SNMP can be viewed by running snmpd in debug mode with this options:

$ snmpd -m +Microchip -f -L -V -C -I vacm_vars -c /usr/local/etc/snmp-emulator/r1.conf
NET-SNMP version 5.3.1
Connection from UDP: [127.0.0.1]:32770
Received SNMP packet(s) from UDP: [127.0.0.1]:32770
  GET message
    -- control.13