Manger.Table: Data type changed during WALK

[lextudio-support]

Hi !

I use "Variable[,] table = Manger.Table(...)" to retrive the "ifXTable" [.1.3.6.1.2.1.31.1.1]. In a loop enumerating the rows, I retrieve only some columns in an indexed way:

string alias = ((OctetString) ifXTable[row, 16].Data).ToString();

Unexpedtedly, the code bombs somewhere in the enum loop with a dataconversion error. After some analysis, I made a shorter testprogram and found, that, something about in the middle of the table, the last two columns of a row are changed their position within the row and so my dataconversion fails. I made a small testprogram and a wireshark network trace [the latter, sorry, is not completely understand by me] and I have attached a zip files with all files to reproduce the problem. The problem appears against all cisco switches, I can test. My debian [linux] box implements this table and the problem does not occur. So it could just be a cisco bug !?? I use similar code for the "ifTable" itself and no such problem occurs.

Any help is really very welcomed!

br--mabra

Sorry for using the tracker, but it's the only place to attach a file .... ;-)

Original Reported Date: 2009-02-15T15:02:45.687-08:00 Planned For Release: Original CodePlex ID: 3817

[lextudio-support]

Copied from CodePlex without authors:

mabra,

Why not use this tracker? It is a nice place to report issues you meet.

I will spare some time today to check your wireshark log.

-Lex

Original Posted Date: 2009-02-20T17:37:06.413-08:00

[lextudio-support]

Copied from CodePlex without authors:

mabra,

I am afraid that you might have to recapture wireshark log for this issue. The attached one contains only one packet which does not reveal any useful information.

But your log file is very useful, as it shows that

row: 31 [id: .1.3.6.1.2.1.31.1.1.1.1.10031] [cols: 18] 0[OctetString], 1[Counter32], 2[Counter32], 3[Counter32], 4[Counter32], 5[Counter64], 6[Counter64], 7[Counter64], 8[Counter64], 9[Counter64], 10[Counter64], 11[Counter64], 12[Counter64], 13[Integer32], 14[Gauge32], 15[Integer32], 16[Integer32], 17[OctetString],

row: 32 [id: .1.3.6.1.2.1.31.1.1.1.1.10032] [cols: 18] 0[OctetString], 1[Counter32], 2[Counter32], 3[Counter32], 4[Counter32], 5[Counter64], 6[Counter64], 7[Counter64], 8[Counter64], 9[Counter64], 10[Counter64], 11[Counter64], 12[Integer32], 13[Gauge32], 14[Integer32], 15[Integer32], 16[OctetString], 17[TimeTicks],

You may notice that starting from row 32 the 16th data type changed from Integer to OctetString, while 17th changed from OctetString to TimeTicks.

Please use net-snmp to test this issue again (also with a wireshark log) to see if it suffers, too. At this moment I guess it is a Cisco problem, but we need to investigate further.

Original Posted Date: 2009-02-20T20:28:07.583-08:00

[lextudio-support]

Copied from CodePlex without authors:

Hello lextm !

Much thanks for your investigations!

I made both tests again and captured the packages [yes, this time, I re-opened them, to verify, that some packages are really inside ... ;-) ].

What you wrote, is excactly what I discovered while making a direct acces to a table-column and what I initally have been written. My direct acces to column 16 failes, because the columns 17 and 18 [from OID view;or 16 and 17 for programmatic access] have changed their positions inside the resultset and so - naturally - my dataconversion fails [one column is OctetString the other is TimeTicks].

For my current program, instead of using "Manager.Table(.:)" I make two walks, specifying the columns and then I consolidate them internally to my table. This works and I get the expected results!

But the most interesting aspect is, that "net-snmp.snmptable.exe" returns the table in a right way. But I also discovered, that - sometimes - snmptable shows a question mark for some columns, which suspects me. So I just tested all my local switches and indeed, they seem to return a different number of columns for the ifXTable. But net-snmp shows a question mark, while SharpSnmp changes columns or even return less columns, then expected. My new walks to get the two variables works successfull all the time. So it looks like a problem/implementation-thing with SharpSnmp. On the other hand:I found some cisco implementation bugs while googling for the problem. I asked my collegues and found a location, where a HP switch is located. For this switch, SharpSnmp and net-snmp returns the same resultset! So, it has something to do with cisco and different IOS versions. But:As I said before:net-snmp returns all columns right, but might have empty or null values for some of the variables in a row.

br--mabra

Original Posted Date: 2009-02-21T09:54:09.407-08:00

[lextudio-support]

Copied from CodePlex without authors:

mabra,

Thanks for the new logs. Now I am sure that this problem you meet is duplicate to 2668.

Why net-snmp displays question marks? Because the SNMP agent skips the missing objects and returns nothing about them in the conversation. Sadly our current implementation of GetTable does not take such sparse table into consideration.

I will close this item as duplicate later. And we shall work on 2668 during 3.0 time frame.

-Lex

Original Posted Date: 2009-02-21T17:38:05.693-08:00

[lextudio-support]

Copied from CodePlex without authors:

Duplicate to 2668. But mabra provides a good workaround by utilizing WALK directly.

** Closed by lextm 02/21/2009 5:39PM

Original Posted Date: 2009-02-21T17:39:24.363-08:00

[lextudio-support]

Original Closed Date: 2010-11-05T19:09:56.747-07:00