Wireshark · Ethereal-users: RE: [Ethereal-users] Weird Cisco packet?

["Giles Scott" <gscott2@xxxxxxxxxxxxxxxxxx>]

Title: RE: [Ethereal-users] Weird Cisco packet?

not doing very well today, missed off some stuff, should be;

bridge number [2 bytes], bridge IP[4 bytes], bridge MAC [6 bytes], bridge type [1 byte], bridge status [1 byte], number of ports [1 byte], hello port type [1 byte], hello port status [1 byte], Comp MAC addr1 [6 bytes], CompMAC addr2 [6 bytes]

Most of these headers can be seen in the EMT MIB

i.e Comp MAC addr1

s5EnMsTopBdgCompBdgMac1 OBJECT-TYPE
SYNTAX MacAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The first MAC address of a companion bridge
of the bridge that sent the topology message.
The value is 00:00:00:00:00:00 for local
bridges (since there is no companion bridge)
and also when the companion MAC address
is unknown for remote bridges."
::= { s5EnMsTopBdgEntry 12 }

 

If you see the MAC in data portion, it must be a 'bridge hello' I didn't think we used that any more;

format of the frame is
SNAP Data
Vendor id 0x000081
PDU type 2
PDU type 0x1A3

bridge number [2bytes], bridge IP[4 bytes], bridge MAC [6 bytes], bridge type [1 byte], bridge status [1 byte], number of ports [1 byte], hello port type [1 byte], hello port status [1 byte]

Giles
-----Original Message-----
From: Scott, Giles [GRKD:2801:EXCH]
Sent: Saturday, October 06, 2001 7:06 AM
To: McNutt, Justin M.; 'ethereal-users@xxxxxxxxxxxx'
Subject: RE: [Ethereal-users] Weird Cisco packet?

Hi Justin,
's5emt104.mib' MIB references SONMP (SynOptics Network Management Protocol)
The protocol uses a DA multicast MAC 01-00-81-00-01-00 and 01-00-81-00-01-01
It is SNAP encoded and the vendor field is 0x000081
I have just finished writing a dissector for this protocol, I am waiting for Managerial approval before I can submit the code :-(

Optivity uses this MIB/protocol to build up and accurate layer 1/2 map of a Nortel based network.
Cheers
Giles Scott

-----Original Message-----
From: McNutt, Justin M. [mailto:McNuttJ@xxxxxxxxxxxx]
Sent: Friday, October 05, 2001 4:40 PM
To: 'ethereal-users@xxxxxxxxxxxx'
Subject: RE: [Ethereal-users] Weird Cisco packet?

One other note.  "show sys topology" on the Passport showed these things for
itself and 128.206.95.252:
0 /0  128.206.95.254   0   00:04:dc:a0:98:00 75      enetFastGigEnet true
heartbeat
1 /2  128.206.95.252   281 00:80:2d:97:61:fe 48      enetFastGigEnet true
heartbeat
If anybody has any Nortel equipment, look for the file s5emt104.mib in the
BayStack 450 MIBs on Nortel's site (you shouldn't have to have a password to
get the MIBs).  I will try to see if the stuff in these MIBs correlates with
anything in this table or in the packets I captured.
--J
> -----Original Message-----
> From: McNutt, Justin M. [mailto:McNuttJ@xxxxxxxxxxxx]
> Sent: Friday, October 05, 2001 6:35 PM
> To: 'ethereal-users@xxxxxxxxxxxx'
> Subject: RE: [Ethereal-users] Weird Cisco packet?
>
>
> It has something to do with Aironet wireless devices.  I see
> similar packets
> on my network, and we have several of these wireless access
> points in our
> LAN.
>
> I can't seem to find any aironet MIBs anywhere, though, or we
> might be able
> to figure it out.
>
> Here are some similar things that Ethereal doesn't understand
> (attached).
>
> In autotopology.bay.cap, you'll see two different L2 multicasts to the
> groups 01:00:81:00:01:00 (this segment) and 01:00:81:00:01:01
> (all segments
> in the bridged LAN).  IIRC, devices that understand Bay
> autotopology frames
> *will* forward the :01 frames as a L2 multicast, but will
> *not* forward the
> :00 frames.
>
> I don't know how to decode the whole data portion, but there
> are some things
> that are recognizable to me deeper in the frames.  For
> example, the first
> four bytes of the data payload in both type of autotopology
> frames are the
> IP address of the switch sending the frame.  In the case
> shown, the IP is
> 128.206.95.252, which is the switch I connect to.
>
> In the :01 frames:
>
> If the byte at offset 0x031 is 0x41, then at offset 0x024 we
> see the MAC
> address of the next switch upstream +0x01.  The next switch
> upstream is a
> Nortel Passport.  Passports have different MAC's for damn
> near everything.
> The base MAC address of the Passport in question is
> 00:04:DC:A0:98:00.  Add
> one and you get the MAC seen in the frames in this capture.  This MAC
> address is what the Passport uses as it's bridge address for
> Spanning Tree
> in Spanning Tree Group 1 (Passports don't do per-VLAN STP;
> they use STG's).
>
> If the byte at offset 0x031 is not 0x41, then at offset 0x024
> we see the MAC
> address of the switch sending the frame +0x1e, which is also
> the source MAC
> on the frame.  The way a BayStack 450 works, the MAC address
> of the base
> unit in a stack is used for a bunch of other things as well. 
> You add 0x1e
> to get the MAC used for autotopology.  Add 0x1f and you get
> the MAC address
> used by the IP stack.  Even weirder is that if the switch is
> a stand-alone
> (not stacked with other BayStacks), all three MAC addresses
> are simply that
> of the unit itself (00:80:2D:97:61:E0 in this case).
>
> In the :00 frames:
>
> If the byte at offset 0x031 is 0x41, we see the MAC of the
> Passport again at
> 0x024.
>
> If the byte at offset 0x031 is not 0x41, then at 0x024 we see
> something
> *similar* to eth.dst of the frame, but with the bytes in
> reverse order, and
> with the 81 byte as 18 instead.  Could be coincidence since I
> don't *really*
> know what any of these fields are.
>
> I really oughta go into our test lab and compare these to
> what I get from
> other Nortel switches and what I get if I change STP settings, etc.
>
> Does anybody have any other info about these frames?
>
> --J
>
> > -----Original Message-----
> > From: Joe Tomasone [mailto:joe@xxxxxxxx]
> > Sent: Friday, October 05, 2001 2:59 PM
> > To: ethereal-users@xxxxxxxxxxxx
> > Subject: [Ethereal-users] Weird Cisco packet?
> >
> >
> > Anyone know what this packet is?
> >
> > Looks like some funky Cisco thing, since the source MAC is
> > embedded in the
> > data portion.
> > Whatever it is, Ethereal didn't know what to do with it.
> >
> >
> >     - Joe
> >
> >
>
>
_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users