They had different Virtual-Access interfaces, but the physical source
interface on both of these was the same and they were derived from the same
Virtual-Template.
The whole semi-randomness of this would be a bit difficult to implement in a
dissector. =)
Frank
-----Original Message-----
From: Sake Blok [mailto:sake@xxxxxxxxxx]
Sent: Sunday, March 02, 2008 8:21 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 03:58:31PM -0600, Frank Bulk wrote:
> I used bittwiste to remove the first 12 bytes of the attached packet
capture
> that included a variety of traffic, and you'll see that some packets are
> fine, but others, such as 4, 7, 8, etc are not.
>
> Can anyone make sense of it?
As in my other mail, I don't think the first 12 bytes are incorrect.
These are the expected src and dst mac when using "ip traffic-export".
Frame 1, 2 and 3 in this capture file show the exact behavior of
the capture you sent in earlier.
However, frame 4, 7 and 8 show a different, but similar behavior:
First the dst-mac, ie the mac which is configured in the "ip export-traffic"
profile:
00 12 79 63 1a 8c
Then the mac-addres of the egress cisco interface towards the wireshark-PC:
00 30 b6 53 00 06
Then again the Ethertype for IP:
08 00
Now things get funny, these three bytes look like the last three bytes
of the PPPoE header, where is the rest???:
0a 00 36
Again the PP header:
00 21
And the IP-header plus data:
45 00 00 34 0d d7 40 00 7f 06 71 4f ac
10 00 0f 62 d8 6d a6 c8 b2 01 bb 46 31 f7 17 00
00 00 00 80 02 20 00 ca cf 00 00 02 04 05 a0 01
03 03 08 01 01 04 02
Could it be that there were two different source interfaces which
were "ip export-traffic" forwarded? Maybe even of a different
interface type?
For these frames, deleting the 5 bytes between the Ethertype IP (08 00)
and the IP layer (starting with 45 00) will result in valid frames.
In the other frames, deleting 12 bytes between the src-mac and the
PPPoE session ethertype (88 64) makes them valid frames.
Hmmm... if you want all frames to be persistent with each other and
with the normal output of "ip traffic-export", deleting the 5 or 20
bytes between the IP Ethertype (08 00) and the start of the IP header
(45 00) would do the trick. Unfortunately I don't think bittwiste
will support that though :(
Cheers,
Sake
