Re: Proposed new pcap format

["Fulvio Risso" <fulvio.risso () polito it>]

> -----Original Message-----
> From: tcpdump-workers-owner () lists sandelman ca
> [mailto:tcpdump-workers-owner () lists sandelman ca]On Behalf Of Loris
> Degioanni
> Sent: martedì 13 aprile 2004 19.53
> To: tcpdump-workers () tcpdump org
> Subject: Re: [tcpdump-workers] Proposed new pcap format
>
>
> Ronnie,
>
> > ----- Original Message -----
> > From: "Loris Degioanni"
> > Sent: Monday, April 12, 2004 2:56 PM
> > Subject: Re: [tcpdump-workers] Proposed new pcap format
> >
> >
> > > > I'd prefer a general flag field, which would include a direction
> > > > indication (which might also include, for received packets, an
> > > > indication of how it was received, e.g.
> > > > unicast/multicast/broadcast/promiscuous/not specified), and
> could also
> > > > include some other information (length of FCS, with 0 meaning
> "absent",
> > > > and possibly link-layer-type-dependent error flags such as "runt
> frame",
> > > > "bad CRC", etc.).
> > >
> > > The problem is: all this information is not granted to be present, so
> you
> > > need to define default values, which in most cases mean "0", or "not
> > > available", or "absent". At this point why not using options?
> >
> > If they are made mandatory they WILL always be present, or else it will
> not
> > be a pcap compatible file.
>
> Some systems, e.g. WinPcap, don't provide information about the the
> direction. In addition, they never provide FCS, so its length would be
> always 0. They don't give indication about the link-layer-type-dependent
> errors (at least, they don't give a per packet indication).
> I think, indeed, that this is the behavior of most capture drivers. So,
> granting that all this information will always be present is not
> so easy...

I agree with Loris.
I know that this flag would be extremely useful, but there are no guarantees
that you're able to get this info from the NIC / NIC driver.
Perhaps, what we should to is to use 2 bits for each flag, where the first
one means "flag is valid", and the second one it is the flag value.
E.g.:

  1                 0                0                  0 . . . . . .
 ^^^               ^^^              ^^^                ^^^
 "incoming" flag   packet is        "outcoming" flag   No meaning
 is valid          not "incoming"   is NOT valid

Cheers,

        fulvio

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.