On Aug 31, 2016, at 11:49 AM, Jonathan Brucker
wrote:
> On Wed, Aug 31, 2016 at 6:27 PM, Guy Harris wrote:
>> On Aug 31, 2016, at 11:03 AM, Jonathan Brucker
>> wrote:
>>
>>> RFtap is here to bridge this gap, for all protocols.
>>
>> That's exactly why I don't like its current design!
>>
>>
The RFtap protocol is designed to encapsulate any type of packet:
Wi-Fi, Bluetooth, or packets from any proprietary protocol.
RFtap is designed to carry RF metadata which is not handled by
current metadata protocols such as gsmtap, radiotap, and PPI.
You can read more about the typical use case i
On Aug 31, 2016, at 9:18 AM, Jonathan Brucker wrote:
> I am posting to request a value for DLT_RFTAP and LINKTYPE_RFTAP.
>
> RFtap is a simple protocol designed to provide Radio Frequency (RF)
> metadata about packets,
What types of packets? 802.11 packets? If so, this is probably better done
-Original Message-
From: m...@sandelman.ca [mailto:m...@sandelman.ca]
Sent: den 28 juni 2013 01:51
To: Anders Broman
Cc: tcpdump-workers@lists.tcpdump.org
Subject: Re: [tcpdump-workers] Request for new DLT
Anders Broman wrote:
> Currently there is two tags defined to indic
Anders Broman wrote:
> Currently there is two tags defined to indicate which protocol the
> packet block starts with:
> #define EXP_PDU_TAG_LINKTYPE 11 /**< The value part is the
linktype value defined by tcpdump
> * http://www.tcpdump.org/linktypes.html
> */
> #
-Original Message-
From: Anders Broman
Sent: den 19 juni 2013 19:23
To: 'm...@sandelman.ca'
Cc: tcpdump-workers@lists.tcpdump.org
Subject: RE: [tcpdump-workers] Request for new DLT
-Original Message-
From: m...@sandelman.ca [mailto:m...@sandelman.ca]
Sent: den 19
-Original Message-
From: m...@sandelman.ca [mailto:m...@sandelman.ca]
Sent: den 19 juni 2013 14:50
To: Anders Broman
Cc: tcpdump-workers@lists.tcpdump.org
Subject: Re: [tcpdump-workers] Request for new DLT
Anders Broman wrote:
Anders> Hi, Any chance of getting forward on t
tcpdump-workers@lists.tcpdump.org
Subject: Re: [tcpdump-workers] Request for new DLT
-Original Message-
From: m...@sandelman.ca [mailto:m...@sandelman.ca]
Sent: den 23 maj 2013 20:03
To: Anders Broman
Cc: tcpdump-workers@lists.tcpdump.org
Subject: Re: [tcpdump-workers] Request for new DLT
>>&
-Original Message-
From: m...@sandelman.ca [mailto:m...@sandelman.ca]
Sent: den 23 maj 2013 20:03
To: Anders Broman
Cc: tcpdump-workers@lists.tcpdump.org
Subject: Re: [tcpdump-workers] Request for new DLT
>>>>> "Anders" == Anders Broman writes:
Pasca
Hi Michael,
Le 23/05/2013 20:03, Michael Richardson a écrit :
>> "Anders" == Anders Broman writes:
> Pascal> Anders can describe it better than me, but the format
> Pascal> intends to be versatile.It allows you to export any higher
> Pascal> level PDUs in a pcap file while maintai
> "Anders" == Anders Broman writes:
Pascal> Anders can describe it better than me, but the format
Pascal> intends to be versatile.It allows you to export any higher
Pascal> level PDUs in a pcap file while maintaining some basic
Pascal> information about the lower layers
So,
From: Pascal Quantin [mailto:pascal.quan...@gmail.com]
Sent: den 19 maj 2013 10:25
To: Michael Richardson
Cc: Anders Broman; tcpdump-workers@lists.tcpdump.org
Subject: Re: [tcpdump-workers] Request for new DLT
Hi Michael,
2013/5/18 Michael Richardson
>>>>> "Pascal"
Hi Michael,
2013/5/18 Michael Richardson
>
> > "Pascal" == Pascal Quantin writes:
> Pascal> Anders Broman, Wireshark core developer, is currently
> designing an export
> Pascal> functionality for PDUs and would need a DLT allocated for this
> new
> Pascal> functionality.
> P
> "Pascal" == Pascal Quantin writes:
Pascal> Anders Broman, Wireshark core developer, is currently designing an
export
Pascal> functionality for PDUs and would need a DLT allocated for this new
Pascal> functionality.
Pascal> You will find below the email he tried to send to t
Hi,
I would need a DLT for a wrapper around higher level PDU's or per-packet DLT:s
the format is multipurpose and consists of a number of TLV:s proceeding the
actual PDU.
There are TLV:s which describes which protocol the PDU is and meta data such as
IP address and port (if the transport protoc
Guy Harris alum.mit.edu> writes:
>
> OK, I've assigned 236 as LINKTYPE_MUX27010 and DLT_MUX27010.
>
Thank you very much!
Kind regards,
Christoph Schemmel
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Mar 3, 2011, at 9:01 AM, Schemmel, Hans-Christoph wrote:
> this is the detailed description of the data format.
>
> LINKTYPE_MUX27010
OK, I've assigned 236 as LINKTYPE_MUX27010 and DLT_MUX27010.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Guy Harris alum.mit.edu> writes:
>
> Not yet - I've been somewhat busy the past week and a half, and I have to
condense all the e-mail on this thread
> into a complete and precise description of the data format, to put into the
pcap/bpf.h and pcap-common.c
> files. If somebody else were to do s
On Mar 2, 2011, at 7:49 AM, Schemmel, Hans-Christoph wrote:
> I just want to ask if you´ve already assigned a DLT value for the dissector?
Not yet - I've been somewhat busy the past week and a half, and I have to
condense all the e-mail on this thread into a complete and precise description
of
I just want to ask if you´ve already assigned a DLT value for the dissector?
Kind regards,
Christoph Schemmel
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Guy Harris alum.mit.edu> writes:
>
> The PPP chunks are indicated by the {Msg_ID, Freq_ID, Start_Pos, End_Pos,
Flag} quintuplets, where
> Start_Pos is the 1-origin index (i.e., the first byte of the MUX_Frame has an
index of 1, not 0), from the
> beginning of MUX_Frame, of the first byte of the
On Feb 14, 2011, at 6:26 AM, Schemmel, Hans-Christoph wrote:
> Yes, Start_Pos and End_Pos are relative to the beginning of the MUX_Frame,
> but a
> PPP chunk does not start directly at the beginning of a MUX_Frame
> (Start_Pos=0).
> The PPP frame starts after the header fields of the MUX_Frame.
Guy Harris alum.mit.edu> writes:
>
> Start_Pos and End_Pos are relative to the beginning of MUX_Frame, right?
I.e., a 4-byte chunk starting at
> the beginning of MUX_Frame would have a Start_POS of 0? Would End_POS be 3
(meaning that it's the offset of
> the last byte of the chunk) or 4 (meani
On Feb 4, 2011, at 1:59 AM, Schemmel, Hans-Christoph wrote:
> Guy Harris alum.mit.edu> writes:
>
>>
>> OK, so it's:
>>
>> Header_Size: 1 octet
>>
>> A sequence of zero or more instances of:
>>
>> Msg_ID: 2 octets
>>
>> Freq_ID: 2 octets
>>
>>
Guy Harris alum.mit.edu> writes:
> should I just describe the holes as "other data", so you're not
> constrained to forever make them all be AT command/response text, or is it
guaranteed (now and forever) to
> be AT-command-or-response text?-
The description of the holes as "other data" sounds
On Feb 4, 2011, at 1:59 AM, Schemmel, Hans-Christoph wrote:
> The parts that don´t correspond to a PPP packet are AT commands or responses
> (like "ATI", "AT+CSQ" or "+CSQ: 18,99"). This content is interpreted and
> displayed as raw text in the Wireshark subtree for the payload/information of
>
Guy Harris alum.mit.edu> writes:
>
> OK, so it's:
>
> Header_Size: 1 octet
>
> A sequence of zero or more instances of:
>
> Msg_ID: 2 octets
>
> Freq_ID: 2 octets
>
> Start_Pos: 1 octet
>
> End_Pos: 1 octet
>
>
On Feb 3, 2011, at 2:05 AM, Schemmel, Hans-Christoph wrote:
> I´ve mixed up some field sizes in my previous mail. Msg_ID and Freq_ID have a
> size of 2 octects, not 1 octect like the other fields, sorry. So the optional
> part has a size of 7 octects. But your conclusion is correct: The Header_Si
Guy Harris alum.mit.edu> writes:
> OK, so the Direction field and Header_Size fields are always present, and the
Header_size field gives the
> size of the *optional* fields; if a frame contains N PPP packets, the
Header_Size field has the value 5N.
> (If Header_Size isn't a multiple of 5, the fr
On Jan 26, 2011, at 2:30 AM, Schemmel, Hans-Christoph wrote:
> The size of the header depends on the number of PPP packets in the payload of
> the MUX frame. The Header_Size indicates whether Msg_ID, Freq_ID, Start_Pos,
> End_Pos, and Flag are present.
> For example:
> The header of a frame witho
Guy Harris alum.mit.edu> writes:
>
> So are any of those fields optional? For example, is the fragment ID
optional? If so, what indicates whether
> it's present? If nothing is optional, why is the header size not always 7?
>
The size of the header depends on the number of PPP packets in th
On Jan 20, 2011, at 3:05 AM, Schemmel, Hans-Christoph wrote:
> The format of the additional header is:
>
> | Header_Size | Msg_ID | Freq_ID | Start_Pos | End_Pos | Flag | ... |
> Msg_ID |
> Freq_ID | Start_Pos | End_Pos | Flag | Direction | MUX_Frame
>
> Header_Size (1 Octet): Total length
Guy Harris alum.mit.edu> writes:
>
> What is the format of the additional header?-
The format of the additional header is:
| Header_Size | Msg_ID | Freq_ID | Start_Pos | End_Pos | Flag | ... | Msg_ID |
Freq_ID | Start_Pos | End_Pos | Flag | Direction | MUX_Frame
Header_Size (1 Octet): To
Guy Harris alum.mit.edu> writes:
>
> OK, so it sounds as if this isn't raw standard 27.010 traffic. Is MUX27010
likely to be used as a name for that
> traffic? If not, we could call it DLT_MUX27010/LINKTYPE_MUX27010.
>
> What is the format of the additional header?-
> This is the tcpdump-work
On Jan 17, 2011, at 5:52 AM, Schemmel, Hans-Christoph wrote:
> Concerning dissecting: The communication between GSM modem and the host is
> captured with an USB Tracer. The tracer uses a proprietary format for the
> trace
> files, but the data of these files can be exported, e.g. as csv file. I´
> Is this DLT value only for the Basic Option, or is it also used for the
Advanced Option? If it's also for the
> Advanced Option:
>
> 1) Is the flag octet 0x7E if the Advanced Option is being used?
>
> 2) If the Advanced Option is being used, do the packet contents include
escape oc
On Jan 12, 2011, at 4:59 AM, Schemmel, Hans-Christoph wrote:
> A packet begins with a flag (octet 0xF9, section 5.2.1.1), followed by address
> and control field.
Is this DLT value only for the Basic Option, or is it also used for the
Advanced Option? If it's also for the Advanced Option:
Guy Harris alum.mit.edu> writes:
>
>
> On Jan 10, 2011, at 6:16 AM, Schemmel, Hans-Christoph wrote:
>
> > I´ve written a dissector (MUX27010) for wireshark and I want to commit it to
the project. Therefore I need
> a new DLT value for this dissector/protocol because the protocol doesn´t base
u
On Jan 10, 2011, at 6:16 AM, Schemmel, Hans-Christoph wrote:
> I´ve written a dissector (MUX27010) for wireshark and I want to commit it to
> the project. Therefore I need a new DLT value for this dissector/protocol
> because the protocol doesn´t base upon another data link layer protocol.
> Wh
On Dec 28, 2010, at 8:23 PM, Gianluca Varenni wrote:
> This is what PPI does.
>
> http://www.cacetech.com/documents/PPI%20Header%20format%201.0.10.pdf
That document misspells "linktype" as "dlt". :-)
DLT_ values are platform-dependent; there is no guarantee that DLT_xxx will
have the same va
This is what PPI does.
http://www.cacetech.com/documents/PPI%20Header%20format%201.0.10.pdf
There is already a DLT for PPI (DLT_PPI). The only difference from your
solution is that the minimum header before the packet is 8 bytes (instead of
4). The advantage is that Wireshark already supports
This is what PPI does.
http://www.cacetech.com/documents/PPI%20Header%20format%201.0.10.pdf
There is already a DLT for PPI (DLT_PPI). The only difference from your
solution is that the minimum header before the packet is 8 bytes (instead of
4). The advantage is that Wireshark already supports
On Apr 15, 2010, at 11:26 AM, Guy Harris wrote:
>So, for all of the following:
>> DNP3 Serial framing (DLT_DNP3 and LINKTYPE_DNP3)
>> Modbus RTU Framing (DLT_MODBUS and LINKTYPE_MODBUS)
>> SSCP Framing (In the process of making this protocol an IEEE standard which
>> is the impetus for this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "Thomas" == Thomas Edgar writes:
Thomas> With the timing method I am using I was going for a method
Thomas> to capture anything from a COM port and then allow the
Thomas> parsing mechanism (like the heuristic dissectors in
Thoma
On Apr 15, 2010, at 9:59 AM, Edgar, Thomas wrote:
> After looking at how the pcap_set_datalink process works I think I have
> decided to keep my timing method as the default COM interface datalink type.
> But I will create it with the capability of setting the datalink type so that
> you can
On Apr 13, 2010, at 3:30 PM, Guy Harris wrote:
>I think heuristics are what you use when you can't use anything else; if
>they're too strong, they will fail to identify things that they should (and
>people will complain about it), and if they're too weak, they will identify
>things that they sh
On Apr 13, 2010, at 2:34 PM, Edgar, Thomas wrote:
> I am open to the possibility of going forward with that approach. Just to
> clarify, does this work by the user preselecting the framing mechanism before
> the capture is started?
Yes.
> For instance, I would have to know that DNP3 is being
On Apr 13, 2010, at 12:02 PM, Guy Harris wrote:
>Then perhaps the right thing to do is to have *multiple* DLT_/LINKTYPE_
>values, one for each protocol, and use the particular protocol's framing
>mechanism when capturing a particular protocol. libpcap has an API to select
>link-layer type hea
On Apr 13, 2010, at 8:53 AM, Edgar, Thomas wrote:
> We are targeting framed protocols over serial, such as the serial versions of
> DNP3 and Modbus,
Then perhaps the right thing to do is to have *multiple* DLT_/LINKTYPE_ values,
one for each protocol, and use the particular protocol's framing
On Tue, Apr 13, 2010 at 11:53 AM, Edgar, Thomas wrote:
> On Apr 12, 2010, at 4:26 PM, Guy Harris wrote:
> >> I am posting to request a value for DLT_SERIAL and LINKTYPE_SERIAL for
> use with libpcap. I am >working on a project to update libpcap and
> Wireshark to capture and parse RS232 and RS48
On Apr 12, 2010, at 4:26 PM, Guy Harris wrote:
>> I am posting to request a value for DLT_SERIAL and LINKTYPE_SERIAL for use
>> with libpcap. I am >working on a project to update libpcap and Wireshark
>> to capture and parse RS232 and RS485 traffic >(written such that it could
>> handle a wid
On Apr 12, 2010, at 3:18 PM, Edgar, Thomas wrote:
> I am posting to request a value for DLT_SERIAL and LINKTYPE_SERIAL for use
> with libpcap. I am working on a project to update libpcap and Wireshark to
> capture and parse RS232 and RS485 traffic (written such that it could handle
> a wide r
al Message-
From: tcpdump-workers-ow...@lists.tcpdump.org
[mailto:tcpdump-workers-ow...@lists.tcpdump.org] On Behalf Of Michael Richardson
Sent: Tuesday, May 12, 2009 10:05 AM
To: tcpdump-workers@lists.tcpdump.org
Subject: Re: [tcpdump-workers] request for new DLT type
>>>>> &qu
On May 12, 2009, at 7:05 AM, Michael Richardson wrote:
What is "AOS"?
Advanced Orbiting Systems, according to
http://public.ccsds.org/publications/archive/732x0b1s.pdf
and
http://standards.gsfc.nasa.gov/reviews/450-502/450-502.pdf
-
This is the tcpdump-workers list.
Visit h
> "Eric" == Eric Lidwa writes:
Eric> I would like to request a new DLT type, DLT_AOS. We need it
Eric> for AOS Space Data Link Protocol. I have already written
What is "AOS"?
/*
* From: "Lidwa, Eric (GSFC-582.0)[SGT INC]"
* Date: Mon, 11 May 2009 11:18:30 -0500
*
* DLT_AOS. We
55 matches
Mail list logo
