> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Loris
> Degioanni
> Sent: marted́ 13 aprile 2004 19.53
> To: [EMAIL PROTECTED]
> 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.
