[tcpdump-workers] Proprietary link layer headers (DLT:s)?

[Anders Broman]

Hi,
What would be required to request a DLT for a proprietary format?
Best regards
Anders

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

[tcpdump-workers] Request for DLT

[Anders Broman]

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 protocol(s) are striped off).

The format can be used by logging functions in various nodes, say after 
deserialization(SS7 over TDM) decryption(GSM/UMTS/LTE Nodes?) etc.
Tag values and an outline of the format can be found here 
http://anonsvn.wireshark.org/viewvc/trunk/epan/exported_pdu.h?revision=49285&view=markup

Best regards
Anders Broman
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] Request for new DLT

[Anders Broman]

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 protocol(s) are striped off).

The format can be used by logging functions in various nodes, say after 
deserialization(SS7 over TDM) decryption(GSM/UMTS/LTE Nodes?) etc.
Tag values and an outline of the format can be found here 
http://anonsvn.wireshark.org/viewvc/trunk/epan/exported_pdu.h?revision=49285&view=markup

LINKTYPE_ANY_PDU or something like that?

Best regards
Anders Broman
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for new DLT

[Anders Broman]

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 protocol(s) are striped off).

The format can be used by logging functions in various nodes, say after 
deserialization(SS7 over TDM) decryption(GSM/UMTS/LTE Nodes?) etc.
Tag values and an outline of the format can be found here 
http://anonsvn.wireshark.org/viewvc/trunk/epan/exported_pdu.h?revision=49285&view=markup
 

LINKTYPE_ANY_PDU or something like that?

Best regards
Anders Broman
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for new DLT

[Anders Broman]

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" == 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 this mailing list 
a few
    Pascal> days ago and that got bounced. I hope mine will go through
    Pascal> :)

sorry.

    Anders>  I would need a DLT for a wrapper around higher level PDU's or 
per-packet
    Anders> DLT:s the format is multipurpose and consists of a number of TLV:s
    Anders> proceeding the actual PDU.
    Anders> There are TLV:s which describes which protocol the PDU is and meta 
data
    Anders> such as IP address and port (if the transport protocol(s) are 
striped off).

    Anders> The format can be used by logging functions in various nodes, say 
after
    Anders> deserialization(SS7 over TDM) decryption(GSM/UMTS/LTE Nodes?) etc.
    Anders> Tag values and an outline of the format can be found here
    Anders> 
http://anonsvn.wireshark.org/viewvc/trunk/epan/exported_pdu.h?revision=49285&view=markup

Looks like a rather sane TLV structure.
Is it intended to be used beyond SS7 stuff?

Pascal> Anders can describe it better than me, but the format intends to be 
versatile.It allows you to export any higher level PDUs in a pcap file while 
maintaining some basic information about the lower layers
Pascal>  (like the transport one). The current code sample in Wireshark is 
for SIP protocol, but could be extended to any protocol if there is a need. 
With a DLT allocated, it would allow the feature to work out of 
Pascal> the box without any user configuration required (right now the 
implementation is mapped on a user DLT, so you must configure Wireshark 
accordingly).
Pascal> For example I would see a use for it for the logging capabilities 
of a mobile phone that use higher layer protocols decoded by Wireshark without 
the traditional network oriented transport layers. Right now
   Pascal> I need to play tricks with user DLT and it prevents mixing protocols.

Yes the intention is to have a versatile format that can fulfill many needs. 
One more use case could be to save decrypted application signaling. The 
intension is to publish the TLV list and description
A bit more prominently - Wiresharks wiki? Once the format stabilizes and the 
most useful TLV:s has been defined. 

Regards
Anders 

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for new DLT

[Anders Broman]

-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:
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, how are the higher level PDUs going to be described?
>that is, will you have a recursive DLT value, or what exactly?

Pascal> (like the transport one). The current code sample in
Pascal> Wireshark is for SIP protocol, but could be extended to any
Pascal> protocol if there is a need. With a DLT allocated, it would
Pascal> allow the feature to work out of  

>I'd rather have it be rather specific and well defined, then loose and 
>nebulous.  DLTs already require too much specialized knowledge to decode as it 
>is.

I'm not sure I get the objection, do you feel that these protocol type tag 
isn't clear enough?
#define EXP_PDU_TAG_LINKTYPE  11 /**< The value part is the linktype 
value defined by tcpdump 
  * 
http://www.tcpdump.org/linktypes.html
  */ 
#define EXP_PDU_TAG_PROTO_NAME12 /**< The value part should be an ASCII 
non NULL terminated string 
  * of the short protocol name used by 
Wireshark e.g "sip"
  * Will be used to call the next 
dissector.
  */
/* Add protocol type related tags here NOTE Only one protocol type tag may be 
present in a packet, the first one found will be used*/

The meta data tags are optional.

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for new DLT

[Anders Broman]

Hi,
Any chance of getting forward on this? I'm not sure what I should change/make 
clearer to get this request accepted. We now have another use case in Wireshark:
- Exporting decrypted packets from SSL sessions by "cutting" them off after the 
SSL layer and saving the file with the new DLT value the TLV:s and then the 
PDU:s 
Following after the SSL layer.
Regards
Anders Broman


-Original Message-
From: tcpdump-workers-boun...@lists.tcpdump.org 
[mailto:tcpdump-workers-boun...@lists.tcpdump.org] On Behalf Of Anders Broman
Sent: den 24 maj 2013 10:59
To: 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:
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, how are the higher level PDUs going to be described?
>that is, will you have a recursive DLT value, or what exactly?

Pascal> (like the transport one). The current code sample in
Pascal> Wireshark is for SIP protocol, but could be extended to any
Pascal> protocol if there is a need. With a DLT allocated, it would
Pascal> allow the feature to work out of  

>I'd rather have it be rather specific and well defined, then loose and 
>nebulous.  DLTs already require too much specialized knowledge to decode as it 
>is.

I'm not sure I get the objection, do you feel that these protocol type tag 
isn't clear enough?
#define EXP_PDU_TAG_LINKTYPE  11 /**< The value part is the linktype 
value defined by tcpdump 
  * 
http://www.tcpdump.org/linktypes.html
  */ 
#define EXP_PDU_TAG_PROTO_NAME12 /**< The value part should be an ASCII 
non NULL terminated string 
  * of the short protocol name used by 
Wireshark e.g "sip"
  * Will be used to call the next 
dissector.
  */
/* Add protocol type related tags here NOTE Only one protocol type tag may be 
present in a packet, the first one found will be used*/

The meta data tags are optional.

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for new DLT

[Anders Broman]

-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 this? I'm not sure what I
Anders> should change/make clearer to get this request accepted. We now
Anders> have another use case in Wireshark: - Exporting decrypted packets
Anders> from SSL sessions by "cutting" them off after the SSL layer and
Anders> saving the file with the new DLT value the TLV:s and then the
Anders> PDU:s Following after the SSL layer.  Regards Anders Broman

After the pcap if created, how will another tool know what's in these payloads?

That's our fundamental question.  Can anyone other than the original person who 
saved these files have a clue what dissector to apply?
Forgive me if I'm just not seeing where this information is going to be.

If not, then one of the PCAP private values makes sense.
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
  */ 
#define EXP_PDU_TAG_PROTO_NAME12 /**< The value part should be an ASCII 
non NULL terminated string 
  * of the short protocol name used by 
Wireshark e.g "sip"
  * Will be used to call the next 
dissector.
  */
The Wireshak implementation currently only uses EXP_PDU_TAG_PROTO_NAME .
Is this good enough?
Regards
Anders Broman

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for new DLT

[Anders Broman]

-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 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 this? I'm not sure what I
Anders> should change/make clearer to get this request accepted. We now
Anders> have another use case in Wireshark: - Exporting decrypted packets
Anders> from SSL sessions by "cutting" them off after the SSL layer and
Anders> saving the file with the new DLT value the TLV:s and then the
Anders> PDU:s Following after the SSL layer.  Regards Anders Broman

After the pcap if created, how will another tool know what's in these payloads?

That's our fundamental question.  Can anyone other than the original person who 
saved these files have a clue what dissector to apply?
Forgive me if I'm just not seeing where this information is going to be.

If not, then one of the PCAP private values makes sense.
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
  */ 
#define EXP_PDU_TAG_PROTO_NAME12 /**< The value part should be an ASCII 
non NULL terminated string 
  * of the short protocol name used by 
Wireshark e.g "sip"
  * Will be used to call the next 
dissector.
  */
The Wireshak implementation currently only uses EXP_PDU_TAG_PROTO_NAME .
Is this good enough?
Regards
Anders Broman


Ping?

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for new DLT

[Anders Broman]

-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 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
> */
> #define EXP_PDU_TAG_PROTO_NAME12 /**< The value part should be
>an ASCII non NULL terminated string
> * of the short protocol name used by Wireshark e.g "sip"
> * Will be used to call the next dissector.
> */
> The Wireshak implementation currently only uses EXP_PDU_TAG_PROTO_NAME .
> Is this good enough?

Seems good enough to me.
Is there a stable reference in the wireshark tree/doc/etc. I can point to?

Currently the header file contain the documentation of the TLV:s 
http://anonsvn.wireshark.org/viewvc/trunk/epan/exported_pdu.h?revision=50060&view=markup
I plan to add a wiki page at http://wiki.wireshark.org/ the "next PDU" TLV:s 
will not change but TAG:s may be added as the need arises. It would be great if 
this suffices
To get the DLT then we can proceed to finalize the documentation and have a 
nice wiki page too. If you feel more documentation is needed before allocating 
the DLT we can work on that.

Best regards
Anders Broman

How does this sound:

/*
 * DLT type for upper-protocol layer PDU saves from wireshark.
 *
 * the actual contents are determined by two TAGs stored with each
 * packet:
 *   EXP_PDU_TAG_LINKTYPE  the link type (DLT value) of the
 * original packet.
 *
 *   EXP_PDU_TAG_PROTO_NAMEthe name of the wireshark dissector
 * that can make sense of the data stored.
 */
#define DLT_WIRESHARK_UPPER_PDU 252

Code should be on github in... there:
https://github.com/the-tcpdump-group/libpcap/commit/e65639c26a00397703102861466473c24181b47c

please fork/edit with more info, and let us know how it works.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[


___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] Patch to return a pcap_pkthdr (pcap_ng_pkthdr) to caller suited for writing pcap-ng files

[Anders Broman]

Hi,
Included a patch (I'm not used to git) to return a packet header suited for 
writing pacp-ng files only pcap_dispatch_ng() has been added so far. The patch 
is only compile tested.
But I'd be grateful for some feedback if this approach is acceptable and if 
it's worth my while to continue work on it or any other suggestion on how to 
proceed.
If someone wants to improve on the patch even better.

Best regards
Anders Broman
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Patch to return a pcap_pkthdr (pcap_ng_pkthdr) to caller suited for writing pcap-ng files

[Anders Broman]

-  u_char *user)
+  pcap_ng_handler callback_ng, const u_int if_id, u_char *user)
{
struct pcap_linux *handlep = handle->priv;
union thdr h;
@@ -,6 +4504,8 @@ pcap_read_linux_mmap_v3(pcap_t *handle, int max_packets, 
pcap_handler callback,
   ret = pcap_handle_packet_mmap(
  handle,
  callback,
+  callback_ng,
+  if_id,
  user,
  handlep->current_packet,
  tp3_hdr->tp_len,
diff --git a/pcap.c b/pcap.c
index 626938c..5b1 100644
--- a/pcap.c
+++ b/pcap.c
@@ -268,7 +268,7 @@ pcap_next_ex(pcap_t *p, struct pcap_pkthdr **pkt_header,
 * The first one ('0') conflicts with the return code of 0 from
 * pcap_offline_read() meaning "end of file".
*/
-return (p->read_op(p, 1, p->oneshot_callback, (u_char *)&s));
+return (p->read_op(p, 1, p->oneshot_callback, p->oneshot_callback_ng, 
p->if_id, (u_char *)&s));
}
 #if defined(DAG_ONLY)
@@ -823,7 +823,7 @@ pcap_open_offline_common(char *ebuf, size_t size)
int
pcap_dispatch(pcap_t *p, int cnt, pcap_handler callback, u_char *user)
{
-return (p->read_op(p, cnt, callback, user));
+return (p->read_op(p, cnt, callback, NULL, 0, user));
}
 /*
@@ -833,7 +833,7 @@ int
pcap_read(pcap_t *p, int cnt, pcap_handler callback, u_char *user)
{
-return (p->read_op(p, cnt, callback, user));
+return (p->read_op(p, cnt, callback, NULL, 0, user));
}
 int
@@ -853,7 +853,7 @@ pcap_loop(pcap_t *p, int cnt, pcap_handler callback, u_char 
*user)
* (or an error occurs)
*/
   do {
-n = p->read_op(p, cnt, callback, user);
+n = p->read_op(p, cnt, callback, NULL, 0, user);
   } while (n == 0);
  }
  if (n <= 0)
diff --git a/pcap/pcap.h b/pcap/pcap.h
index f2dd2d6..9223b6d 100644
--- a/pcap/pcap.h
+++ b/pcap/pcap.h
@@ -165,6 +165,22 @@ struct pcap_pkthdr {
bpf_u_int32 len; /* length this packet (off wire) */
};
+/* Enhanced Packet Block without actual packet, options, and trailing
+   Block Total Length */
+struct pcap_ng_pkthdr {
+bpf_u_int32 block_type;
+bpf_u_int32 block_total_length;
+bpf_u_int32 interface_id;
+bpf_u_int32 timestamp_high; /* Timestamp (High) and Timestamp 
(Low): high and low 32-bits of a 64-bit quantity representing the timestamp.
+ * The timestamp is a single 64-bit 
unsigned integer representing the number of units since 1/1/1970.
+ * The way to interpret this field is 
specified by the tstamp_precision option
+  */
+bpf_u_int32 timestamp_low;
+bpf_u_int32 captured_len;
+bpf_u_int32 packet_len;
+};
+#define PCAP_NG_ENHANCED_PACKET_BLOCK_TYPE 0x0006
+
/*
  * As returned by the pcap_stats()
  */
@@ -237,6 +253,9 @@ struct pcap_addr {
typedef void (*pcap_handler)(u_char *, const struct pcap_pkthdr *,
const u_char *);
+typedef void (*pcap_ng_handler)(u_char *, const struct pcap_ng_pkthdr *,
+const u_char *);
+
/*
  * Error codes for the pcap API.
  * These will all be negative, so you can check for the success or



From: Anders Broman
Sent: den 20 november 2013 18:05
To: tcpdump-workers@lists.tcpdump.org
Subject: Patch to return a pcap_pkthdr (pcap_ng_pkthdr) to caller suited for 
writing pcap-ng files

Hi,
Included a patch (I'm not used to git) to return a packet header suited for 
writing pacp-ng files only pcap_dispatch_ng() has been added so far. The patch 
is only compile tested.
But I'd be grateful for some feedback if this approach is acceptable and if 
it's worth my while to continue work on it or any other suggestion on how to 
proceed.
If someone wants to improve on the patch even better.

Best regards
Anders Broman
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] How tcpdump determines the "dropped by kernel"?

[Anders Broman]

Hi,
It's not clear to me if you are running tcpdump on the server in question, 
which might not be a good idea if its heavily loaded as tcpdump might add extra 
load to the machine. You could check with top.

Which OS are you running and what versions of tcpdump/libpcap? What is the 
packets/s  or MB/s? ( Load the capture into Wireshark and look at the Summary 
information).

*Set a snap length (MTU + 18). Depending on your OS and libpcap version this 
might give a good effect.

Regards
Anders

-Original Message-
From: tcpdump-workers-boun...@lists.tcpdump.org 
[mailto:tcpdump-workers-boun...@lists.tcpdump.org] On Behalf Of Eliezer Croitoru
Sent: den 25 november 2013 02:04
To: tcpdump-workers@lists.tcpdump.org
Subject: [tcpdump-workers] How tcpdump determines the "dropped by kernel"?

I have been reading the man pages of tcpdump and I am not sure if my OS will 
report the relevant info.

Since I would not like to research tcpdump code I would like to get some help 
about it from others.

So my kernel would declare on packets that was dropped but still the connection 
was OK and was not disrupted in any way I can think about.

What exactly this "drop by kernel" means?
Is it dropped by kernel and was not handled by any application? or it means 
that the buffers of tcpdump got filled and there-for was dropped by tcpdump?

I am not sure I am even asking the right question but this is how it seems to 
me.

In any case I would like to do a very big dump into a storage system on a very 
loaded system and which I would like to not drop any packet by either the 
kernel or any other level if possible.
In a case there are tuning to the system in couple layers I would like to at 
least minimize the drops from lots of packets into a small amount of packets.

Thanks in Advance,
Eliezer
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] Fault in pcap_list_tstamp_types()?

[Anders Broman]

Hi,
Playing with this function I get
pcap_list_tstamp_types, num tstamp_types 3
host
adapter_unsynced
adapter

Then trying to set pcap_set_tstamp_type(pcap_h, PCAP_TSTAMP_ADAPTER);

'eth1' (SIOCSHWTSTAMP failed: Numerical result out of range).

ethtool -T eth1
Time stamping parameters for eth1:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
hardware-receive  (SOF_TIMESTAMPING_RX_HARDWARE)
software-receive  (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
hardware-raw-clock(SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 1
Hardware Transmit Timestamp Modes:
off   (HWTSTAMP_TX_OFF)
on(HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none  (HWTSTAMP_FILTER_NONE)
ptpv1-l4-event(HWTSTAMP_FILTER_PTP_V1_L4_EVENT)
ptpv2-l4-event(HWTSTAMP_FILTER_PTP_V2_L4_EVENT)
ptpv2-l2-event(HWTSTAMP_FILTER_PTP_V2_L2_EVENT)

So it seems libpcap is reporting the availability of HW timestamp when in fact 
it's not available. Or am I missing something?
(1.6.0-PRE-GIT)

Regards
Anders
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] pcapng adaptions vs Wireshark

[Anders Broman]

>Are there specific things in a new API that would make wireshark happier?
>feel free to start a new thread ;-)

Having a packet header that could be written to file directly might be a good 
idea

/* pcap-ng Enhanced Packet Block without actual packet, options, and trailing
 * Block Total Length
 * ENHANCED_PACKET_BLOCK_TYPE 0x0006
 * http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html
 */
struct pcap_pkthdr_epb {
bpf_u_int32 block_type; /* Pcap-ng 
block type ENHANCED_PACKET_BLOCK_TYPE */
bpf_u_int32 block_total_length; /* Block Total Length: 
total size of this block, in bytes */
bpf_u_int32 interface_id;   /* Specifies 
the interface this packet comes from */
bpf_u_int32 timestamp_high;  
bpf_u_int32 timestamp_low;  /* High and low 
32-bits of a 64-bit quantity representing the timestamp.

 * The timestamp is a single 64-bit unsigned integer representing the 
number of units since 1/1/1970.

 * if_tsresol further specifies this field.

 */
bpf_u_int32 captured_len;   /* Captured 
Len: number of bytes captured from the packet (i.e. the length of the Packet 
Data field) */
bpf_u_int32 packet_len; /* Packet Len: 
actual length of the packet when it was transmitted on the network. 

 * It can be different from Captured Len if the user wants only a 
snapshot of the packet.

 */
};

(http://permalink.gmane.org/gmane.network.tcpdump.devel/6520 )
Regards
Anders
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Libpcap performance problem

[Anders Broman]

Hi,
What version of libpcap are you using? Version >= 1.5.3 uses TPACKET_V3 which 
may give an capacity increase.
Regards
Anders

-Original Message-
From: tcpdump-workers [mailto:tcpdump-workers-boun...@lists.tcpdump.org] On 
Behalf Of Giray Simsek
Sent: den 28 januari 2015 15:58
To: tcpdump-workers@lists.tcpdump.org
Subject: [tcpdump-workers] Libpcap performance problem

Hi,
We are currently working on testing Linux network performance. We have two 
Linux machines in our test setup. Machine1 is the attacker machine from which 
we are sending SYN packets to Machine2 at a rate of 3million pps. We are able 
to receive these packets on Machine2's external interface and forward them 
through the internal interface without dropping any packets. So far no 
problems. However, when we start another app that captures traffic on 
Machine2's external interface using libpcap, the amount of traffic that is 
forwarded drops significantly. Obviously, this second libpcap app becomes a 
bottleneck. It can capture only about 800Kpps of traffic and only about 800Kpps 
can be forwarded in this case. This drop in the amount of forwarded traffic is 
not acceptable for us.
Is there any way we can overcome this problem? Are there any settings on Os, 
ixgbe driver or libpcap that will allow us to forward all the traffic?
Both machines are running Linux kernel 3.15.
Thanks in advance.
Giray 
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] [tcpdump] Feature request: conditional run dissector on traffic (#495)

[Anders Broman]

Skickat från min Sony Xperia™-smartphone

 Michael Richardson skrev 

> > It has been mentioned briefly in #471: with the option -T radius it is
> > possible to dissect traffic over non-RADIUS ports as RADIUS, but this
> > means all traffic will be dissected as RADIUS
> 
> > A short use case as an example: FreeRADIUS has the possibility to use a
> > RESTful server for authorization My RESTful daemon will send a
> > CoA/Disconnect if this user still has another session, and my NAS
> > requires that I send it to port 1700 instead of the standard port I
> > want to see all the traffic that is relevant, which means UDP port 1812
> > for RADIUS authentication, TCP port 80 for the RESTful traffic and UDP
> > port 1700 for RADIUS CoA/Disconnect
> 
> > Until yesterday, UDP port 1700 was not marked as RADIUS, which means
> > that would not be dissected If I use -T radius, all traffic would be
> > dissected as RADIUS, so the HTTP traffic would be mangled
> 
> > It would be nice if there was a possibility to conditionally mark
> > traffic as a certain protocol, like saying -T "udp port 1700 = radius,
> > tcp port 4080 = http"
> 
> Being able to dynamically map ports -> protocols in TCPDUMP would indeed be a
> nice thing to have.I think that squishing it all into -T is too hard.
> I'd rather have a file that describes the mapping, and just bake a file like
> that in as the default.  As for a syntax...
> I was thinking that maybe we could use pcap filters as the matchers.
> 

Having port maping in a pcap-ng block might be a nice feature too which might 
be worth considering when designing the format.
Regards 
Anders 


> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works| network architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 
> ___
> tcpdump-workers mailing list
> tcpdump-workers@lists.tcpdump.org
> https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] Fwd: Remove support for AirPcap and TurboCap in master

[Anders Broman]

-- Forwarded message -
Från: Anders Broman 
Date: mån 14 okt. 2024 22:14
Subject: Remove support for AirPcap and TurboCap in master
To: 


Hi,
There are two pull requests to remove support for two obsolete HW products.
Any objections?

Both has been end of availability for more than 7 years and drivers only
work on older windows systems.
Riverbed AirPcap
<https://support.riverbed.com/content/support/software/steelcentral-npm/airpcap.html>
Riverbed TurboCap
<https://support.riverbed.com/content/support/software/steelcentral-npm/turbocap.html>

Best regards
Anders
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[tcpdump-workers] Test programs on Windows?

[Anders Broman]

Hi,
I have successfully built libpcap with VisualStudio using NPCAP SDK. But
when trying to run any of the test programs
like libpcap>run\RelWithDebInfo\findalldevstest.exe
 It complains about not finding packet.dll however packet.lib exists. Are
the tests supposed to work on Windows?
Best regards
Anders
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Re: [tcpdump-workers] Request for new LINKTYPE_* code LINKTYPE_AUERSWALD_LOG

[Anders Broman via tcpdump-workers]

--- Begin Message ---
Hi,
You should perhaps take a look at the exported plus link type and wireshark 
sources. It may be doing similar things. New tags could be added.
Regards
Anders

Hämta Outlook för Android


From: tcpdump-workers  on behalf of 
developer--- via tcpdump-workers 
Sent: Thursday, February 4, 2021 10:25:07 AM
To: Michael Richardson 
Cc: tcpdump-workers@lists.tcpdump.org 
Subject: Re: [tcpdump-workers] Request for new LINKTYPE_* code 
LINKTYPE_AUERSWALD_LOG

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://protect2.fireeye.com/v1/url?k=6834631a-37af5a37-68342381-8692dc8284cb-36a161c5fa71f9bb&q=1&e=1c2aa5de-a64f-4983-9bfb-41b294d0b43c&u=https%3A%2F%2Flists.sandelman.ca%2Fmailman%2Flistinfo%2Ftcpdump-workers
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers