Re: New DLT_ value request

["Will Barker" <w.barker () zen co uk>]

Is this request OK/in the queue?

When should I expect it to have been completed?

Thanks

Will

-----Original Message-----
From: Will Barker [mailto:w.barker () zen co uk] 
Sent: 30 November 2007 09:57
To: 'tcpdump-workers () lists tcpdump org'
Subject: RE: [tcpdump-workers] New DLT_ value request

> ...should the rule be just "zero means received, non-zero means sent", or
> should a specific value mean "sent" (which means we'd then have to decide
> whether the header is big-endian or little-endian)?

Well it just has to allow for the mapping for the corresponding dissectors
e.g.

static void visual_set_pseudo_header(int encap, struct visual_pkt_hdr
*vpkt_hdr,
.
.
.
    case WTAP_ENCAP_CHDLC_WITH_PHDR:
    case WTAP_ENCAP_PPP_WITH_PHDR:
        pseudo_header->p2p.sent = (packet_status & PS_SENT) ? TRUE : FALSE;
        break;

    case WTAP_ENCAP_FRELAY_WITH_PHDR:
    case WTAP_ENCAP_LAPB:
        pseudo_header->x25.flags =
            (packet_status & PS_SENT) ? 0x00 : FROM_DCE;
        break;
    }
}

So either approach should be OK - the latter being a bit more flexible. Is
there no general preference in this regard? Or (non-formalised?) standard
approach generally adopted now in the libpcap/wireshark world?

> So what's the header for your encapsulation type?

In this case I would want the frame-specific info to be in the frame content
itself (and decoded by the DLT-specific dissector) and so no fixed header
would be required. This approach will allow the captured content to be
version-specific without affecting the plumbing of libpcap/wireshark - only
the capturing device and the dissector itself would need to know the
specifics of the message content. This would allow for great flexibility as
the capturing device is extended over time (i.e. without needing to affect
the libpcap/wireshark plumbing).

Will

-----Original Message-----
From: tcpdump-workers-owner () lists tcpdump org
[mailto:tcpdump-workers-owner () lists tcpdump org] On Behalf Of Guy Harris
Sent: 29 November 2007 19:17
To: tcpdump-workers () lists tcpdump org
Subject: Re: [tcpdump-workers] New DLT_ value request

Will Barker wrote:
> > What is the format of the extra information you'll be putting at the 
> > beginning of the {PPP, Cisco HDLC, Frame Relay, LAPB} packets to hold 
> > the packet direction?  (Number of bytes, values to be put there, etc.)
>
> It should just be akin to the pseudo header used for generic p2p links
e.g.
> /* Packet "pseudo-header" for point-to-point links with direction flags.
*/
> struct p2p_phdr {
>       gboolean        sent; /* TRUE=sent, FALSE=received */
> };

That'd be a 32-bit pseudo-header; should the rule be just "zero means 
received, non-zero means sent", or should a specific value mean "sent" 
(which means we'd then have to decide whether the header is big-endian 
or little-endian)?

> > > In addition is it acceptable to have one further value defined for our 
> > > own proprietary encapsulation type?
>
> > By "proprietary" do you mean you'll be using this only internally within 
> > your company, with special internal versions of tcpdump/Wireshark/etc. 
> > or special internal-only Wireshark plugins, or do you mean you'll be, 
> > for example, submitting a dissector for that encapsulation for inclusion 
> > in Wireshark?
>
> The latter (submitting a dissector for that encapsulation for inclusion in
> Wireshark)

So what's the header for your encapsulation type?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

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