Re: Is this a bug? Strange walk behavior

This is a discussion on Re: Is this a bug? Strange walk behavior within the SNMP Coders forums, part of the Networking and Network Related category; On Wed, May 23, 2007 at 09:09:17AM +0100, Dave Shield wrote: > On 23/05/07, Steve Friedl &...


Go Back   Usenet Forums > Networking and Network Related > SNMP Coders

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 05-23-2007
Steve Friedl
 
Posts: n/a
Default Re: Is this a bug? Strange walk behavior

On Wed, May 23, 2007 at 09:09:17AM +0100, Dave Shield wrote:
> On 23/05/07, Steve Friedl <steve@unixwiz.net> wrote:
> >Let's start by walking the leading part:
> >
> > $ snmpbulkwalk localhost bgp4PathAttrASPathSegment.64.160
> > ?? where is 64.160.0.0 ?
> > bgp4PathAttrASPathSegment. 64.160.71.0 .24. 10.1.1.4 = (data)

>
> First thing - I'd suggest you test this using "snmpgetnext" rather that
> "snmpwalk".


Yah, getnext has the same behavior.

> Secondly - yes this looks like a bug.
> The next step is to locate exactly where this problem arises.
>
> Try restarting the master agent using the '-d' flag, and running the
> same snmpgetnext command.
> What do the packet dumps look like?


Well the packet dumps only show the SNMP stuff; I don't see any activity
about smux, so I ran tcpdump.

$ snmpgetnext -Os localhost bgp4PathAttrASPathSegment.64.160.0
bgp4PathAttrASPathSegment. 64.160.71.0 .24. 204.11.217.34 = Hex-STRING: 02 03 0D 1C 04 D7 35 B7

So that's the wrong one. (s/b 64.170.0.0 .12.).

Digging in, these are the -d packet dumps, and I doubt that these are going to
provide anything interesting:

SNMPD -d DUMPS
--------------

Received 49 bytes from UDP: [127.0.0.1]:8372
0000: 30 2F 02 01 01 04 07 XX XX XX XX XX XX XX A1 21 0/.....xxxxxxx.!
0016: 02 04 4E 43 DD 51 02 01 00 02 01 00 30 13 30 11 ..NC.Q......0.0.
0032: 06 0D 2B 06 01 02 01 0F 06 01 05 40 81 20 00 05 ..+........@. ..
0048: 00 .

Connection from UDP: [127.0.0.1]:8372
Received SNMP packet(s) from UDP: [127.0.0.1]:8372
GETNEXT message
-- BGP4-MIB::bgp4PathAttrASPathSegment.64.160.0

Sending 65 bytes to UDP: [127.0.0.1]:8372
0000: 30 3F 02 01 01 04 07 XX XX XX XX XX XX XX A2 31 0?.....xxxxxxx.1
0016: 02 04 4E 43 DD 51 02 01 00 02 01 00 30 23 30 21 ..NC.Q......0#0!
0032: 06 15 2B 06 01 02 01 0F 06 01 05 40 81 20 47 00 ..+........@. G.
0048: 18 81 4C 0B 81 59 22 04 08 02 03 0D 1C 04 D7 35 ..L..Y"........5
0064: B7 .


Looking at the SMUX stuff might be more productive, though it looks kinda
ugly without protocol decoders. I think I'm going to have an easier time
of this by digging into the bgpd (formerly zebra) daemon code itself and
adding some debug.

06:36:15.048194 localhost.smux > localhost.9814: P [tcp sum ok] 7:45(38) ack 47 win 32768 <nop,nop,timestamp 245487376 245486622> (DF) (ttl 64, id 11976, len 90)
0x0000 4500 005a 2ec8 4000 4006 0dd4 7f00 0001 E..Z..@.@.......
0x0010 7f00 0001 00c7 2656 f53a f04c 2abe 41b0 ......&V.:.L*.A.
0x0020 8018 8000 5a3e 0000 0101 080a 0ea1 d710 ....Z>..........
0x0030 0ea1 d41e a182 0022 0201 0102 0100 0201 ......."........
0x0040 0030 8200 1530 8200 1106 0d2b 0601 0201 .0...0.....+....
0x0050 0f06 0105 4081 2000 0500 ....@.....
06:36:15.048335 localhost.9814 > localhost.smux: P [tcp sum ok] 47:101(54) ack 45 win 32768 <nop,nop,timestamp 245487376 245487376> (DF) (ttl 64, id 11977, len 106)
0x0000 4500 006a 2ec9 4000 4006 0dc3 7f00 0001 E..j..@.@.......
0x0010 7f00 0001 2656 00c7 2abe 41b0 f53a f072 ....&V..*.A..:.r
0x0020 8018 8000 ff01 0000 0101 080a 0ea1 d710 ................
0x0030 0ea1 d710 a282 0032 0201 0102 0100 0201 .......2........
0x0040 0030 8200 2530 8200 2106 152b 0601 0201 .0..%0..!..+....
0x0050 0f06 0105 4081 2047 0018 814c 0b81 5922 ....@..G...L..Y"
0x0060 0408 0203 0d1c 04d7 35b7 ........5.
06:36:15.143999 localhost.smux > localhost.9814: . [tcp sum ok] 45:45(0) ack 101 win 32768 <nop,nop,timestamp 245487386 245487376> (DF) (ttl 64, id 11981, len 52)
0x0000 4500 0034 2ecd 4000 4006 0df5 7f00 0001 E..4..@.@.......
0x0010 7f00 0001 00c7 2656 f53a f072 2abe 41e6 ......&V.:.r*.A.
0x0020 8010 8000 b3dd 0000 0101 080a 0ea1 d71a ................
0x0030 0ea1 d710 ....

Thanks for the help.

Steve

--
Stephen J Friedl | Security Consultant | UNIX Wizard | +1 714 544-6561
www.unixwiz.net | Tustin, Calif. USA | Microsoft MVP | steve@unixwiz.net

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders
Reply With Quote
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT +1. The time now is 03:15 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0