Thanks Ronnie, you've solved it!
I assumed that if fd->next is not NULL then it is valid.
Unfortunately, it is not true.
As for your criticism on the snoop-like protocol:
This is how we and our customer get information about a packet going through
the FW steps. Naturally, it is not economical as an output. However, it is
merely a debugging device and it has to put minimal burden on the FW itself.
Hope it is clearer now!
Thanks you once again!
Shaul
-----Original Message-----
From: Ronnie Sahlberg [mailto:ronnie_sahlberg@xxxxxxxxxxxxxx]
Sent: Tuesday, April 15, 2003 3:12 PM
To: Shaul Eizikovich; ethereal-dev@xxxxxxxxxxxx
Subject: Re: [Ethereal-dev] Crash when using "Per packet information"
----- Original Message -----
From: "Shaul Eizikovich"
Sent: Tuesday, April 15, 2003 9:41 PM
Subject: RE: [Ethereal-dev] Crash when using "Per packet information"
> I was probably unclear because I was trying to write a short entry.
> Let me elaborate:
>
> I'm writing a dissector that will run on the output of "fw monitor". This
> output is almost identical to "snoop" with some minor differences.
> The relevant data being: every packet is replicated several times, with
> everything but the MAC address staying unchanged. The replicated
sub-packets
> are guarantied to be sequential and continuous.
Why would the packet be duplicated several times with different link layers?
Is the purpose using the linklayer as a weird sidechannel to encode
additional data
for how the packet traverse the statemachine in some unknown entity?
Still sounds sub-optimal design to duplicate full packets playing link layer
modification games to
represent side channel data. Wastes space and makes captures huge i would
assume.
Why not redesign the representation of the sidechannel?
1, Maybe add a new frame type that preceedes every normal packet which holds
the side channel data?
2, Or preceed every normal packet with empty link layer (ethernet) frames
only consisting of headers
using a special mac source address, like having bit 2 of the first byte set
as local administrated mac address and the remaining 22 bits of the oui as
whatever mac range allocated to your organization, then use the last three
bytes of that max and all 6 bytes of the dest mac as the sidechannel but
dont duplicate the packets.
Add some magic in packet-eth.c to detect these weirdo packets.
#1 seems sane to me but #2 however kludgy could probably work as well.
No need for weird tricks playing with internal structures in pinfo that may
change whenever.
it this dissector for internal use or for inclusion in ethereal?
if for internal use only there is no issue with kludges and you can just
look at pinfo->fd->flags.visited which is 0 first time the packet is seen
and 1 othervise.
