Wireshark-users: Re: [Wireshark-users] Decoding packets from a Cisco's "ip traffic-export" flow
Thanks for the detailed analysis. I think you're right on. Hopefully TAC
can set me straight.
Frank
-----Original Message-----
From: Sake Blok [mailto:sake@xxxxxxxxxx]
Sent: Sunday, March 02, 2008 2:56 AM
To: frnkblk@xxxxxxxxx; Community support list for Wireshark
Subject: Re: [Wireshark-users] Decoding packets from a Cisco's "ip
traffic-export" flow
On Sat, Mar 01, 2008 at 10:30:16AM -0600, Frank Bulk wrote:
> Thanks for your willingness to look at this. I'm glad to have a tool like
> Wireshark because I can't interpret the raw packets. =)
>
> Attached are three ping packets that my Wireshark PC caught. The info
line
> complains "Bogus IP length (8, less than header length 24)".
Looking at the first packet, I think the data is it is as follows.
First I see the dst-mac of the packet which should be the mac address
of the Wireshark-pc, as this is configured in the ip traffic-export
profile:
00 12 79 63 1a 8c dst-mac (the wireshark-PC)
Then there is the source mac-address, which is the interface address
of the cisco (as you stated in another mail):
00 30 b6 53 00 06 src-mac (the cisco interface towards the ws-pc)
Then there is the ethertype "08 00" since the cisco expects to send
out ip traffic (it is the *IP* traffic export option):
08 00 Ethertype IP (because it's ip traffic-export)
Now things get funny, there are 4 bytes that look like the last
four octets of another interface of the same cisco-router. I expect
this to be the mac-address of the interface on which the PPPoE
packet was received:
b6 53 00 08 4 leftover bytes of the original PPPoE packet's
dst-mac???
What follows looks like the rest of the PPPoE packet:
00 01 4a 9e 0e 06 original PPPoE src-address
88 64 Ethertype PPPoE session
11 00 00 06 00 3e PPPoE header
00 21 PPP header
45 00 00 .. 68 69 IP header + payload (icmp packet)
So, to me it looks like a bug in the cisco. It either needs to strip
the whole PPPoE and PPP headers and send something like:
00 12 79 63 1a 8c dst-mac (the wireshark-PC)
00 30 b6 53 00 06 src-mac (the cisco interface towards the ws-pc)
08 00 Ethertype IP (because it's ip traffic-export)
45 00 00 .. 68 69 IP header + payload (icmp packet)
Or it should strip the L2 header of the PPPoE packet and send something
like:
00 12 79 63 1a 8c dst-mac (the wireshark-PC)
00 30 b6 53 00 06 src-mac (the cisco interface towards the ws-pc)
88 64 Ethertype PPPoE session
11 00 00 06 00 3e PPPoE header
00 21 PPP header
45 00 00 .. 68 69 IP header + payload (icmp packet)
Both of which will generate valid frames. The first would be more
consistent with the functionality, ie *IP* traffic-export.
[...]
> This may or may not be relevant, but he's also running the same code and
> hardware platform, so, it's *possible* that what I'm seeing is the result
of
> some Cisco bug that is both in SII and IP Traffic Export.
I think it *is* a cisco bug...
I tried to open the bug-tracker, but it seems to be offline at
the moment. I think you should open a case with the Cisco-TAC
for this issue. Feel free to use my analysis in the report.
(if my assumptions on addresses were correct of course)
Cheers,
Sake
