Hi Guy,
Thanks for the comments, addressed inline:
> I have attached a more detailed description as a text file (lest email
> mangle the ASCII-art), but in short, a packet would look on the wire like:
> >
> > * SOF
> > * Destination address
> > * Source Address
> > * EtherType/Length
> > * Payloa
On Jul 25, 2018, at 1:47 AM, David Mirabito wrote:
> I have attached a more detailed description as a text file (lest email mangle
> the ASCII-art), but in short, a packet would look on the wire like:
>
> * SOF
> * Destination address
> * Source Address
> * EtherType/Length
> * Payload
> * FCS
On Wed, 25 Jul 2018 09:11:23 +0100 Guy Harris wrote
> On Jul 25, 2018, at 12:57 AM, Denis Ovsienko wrote:
>
> > Roughly a half of the libpcap man pages text uses the values -1 and -2 to
> > discuss the return value of particular libpcap functions, the other half
> > uses PC
On 24 July 2018 at 11:46, Guy Harris wrote:
> On Jul 23, 2018, at 6:36 PM, David Mirabito wrote:
>
> > We'd like to request a new DLT_ value for Metamako's packet capture
> trailer
> > that is generated by our MetaWatch network application.
> >
> > https://www.metamako.com/applications/meta
On Jul 25, 2018, at 12:57 AM, Denis Ovsienko wrote:
> Roughly a half of the libpcap man pages text uses the values -1 and -2 to
> discuss the return value of particular libpcap functions, the other half uses
> PCAP_ERROR and PCAP_ERROR_BREAK.
>
> Is there a good reason to keep it this way inst
Hello list.
Roughly a half of the libpcap man pages text uses the values -1 and -2 to
discuss the return value of particular libpcap functions, the other half uses
PCAP_ERROR and PCAP_ERROR_BREAK.
Is there a good reason to keep it this way instead of using
PCAP_ERROR/PCAP_ERROR_BREAK consisten
