I have a table of IP addresses, destinations for traps. Here's how jmibbrowser displays the one row:


Request : Walk .1.3.6.1.4.1.4100.2.2.1.200.2.1.7

Oid : 1.3.6.1.4.1.4100.2.2.1.200.2.1.7.1.1.68.87.91.5 (destinationIpAddress.68.87.91.5 )
Value: 68.87.91.5
Oid : 1.3.6.1.4.1.4100.2.2.1.200.2.1.7.1.2.68.87.91.5 (status.68.87.91.5 )
Value: 1

Received 2 record(s) in 31 milliseconds.


When you walk this table the index displays as .DW[5 instead of the IP address. The create index dialog turns each digit entered into an octet (see picture attached).

I should add that I'm using Unbrowse SNMP 1.6.0.1278.


[img]www.unleashnetworks.com/images/fbfiles//images/indexbuilder.PNG[/img]

[quote]When you walk this table the index displays as .DW[5 instead of the IP address. The create index dialog turns each digit entered into an octet (see picture attached).[/quote]

Unbrowse uses the information contained in the MIB definition to determine whether or not to treat the index part as an IP address. If there is no matching definition, it simply tries to interpret it as ASCII, if that does not work it will print the digits.

Can you post the MIB definition of the table ?
We can look at the MIB definition and see if it contains enough information to allow us to treat the octet string as an IP address.

In the meantime, you can solve the index problem :

Tools -> Customize -> Advanced
Locate the Walker section (near the top)
Uncheck the Show strings in indexes option

Sorry, we have disabled the image uploader. Please bear with us while we find a way to enable it and also prevent spam abuse.

Best Regards,

Partway there. Un-checking the "Show strings in indexes" option solved the display problem. I'm still faced with the inability to enter the IP Address in Unbrowse's index builder.

Note that the index builder's Type Info column describes the field as "IpAddress,OctetString,Fixed Size: 4" and that entering the value "192.168.0.1" yields the index ".49.57.50.46.49.54.56.46.48.46.49" (characters turned to bytes).

--===========================================================================
-- Trap Destination Table
--===========================================================================
alarmTrapDestTable OBJECT-TYPE
SYNTAX SEQUENCE OF AlarmTrapDestEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Alarm Trap Destination Table Object"
::= { hcuAlarm 7 }

alarmTrapDestEntry OBJECT-TYPE
SYNTAX AlarmTrapDestEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Alarm Trap Destination Entry Object"
INDEX { destinationIpAddress }
::= {alarmTrapDestTable 1}

AlarmTrapDestEntry ::=
SEQUENCE {
destinationIpAddress IpAddress,
status RowStatus
}

destinationIpAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION "ip address for a trap destination"
::= {alarmTrapDestEntry 1 }

status OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "status column for row creation purpose"
::= {alarmTrapDestEntry 2 }

Thanks!

Hi,


Note that the index builder's Type Info column describes the field as "IpAddress,OctetString,Fixed Size: 4" and that entering the value "192.168.0.1" yields the index ".49.57.50.46.49.54.56.46.48.46.49" (characters turned to bytes).

This requires a software fix. We can get a new build tomorrow.

The type "IpAddress" is so called textual convention. Some vendors use NetworkAddress, IPAddr, IPAddressV4, etc. I am sure we are not handling the IpAddress (note case) properly.

Stay tuned and thanks,

I look forward to the new build!

You can find the new private build at www.unleashnetworks.com/lib/private/setu...wse_R_1_6_0_1280.msi


IP addresses that are part of an index are handled correctly for both display and table creation.

Let us know if there are any issues with the above build. We will test it for another two days before releasing it on our download page.


Best,