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 -- ] 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] Query about running many, many, rules
How does PCAP handle running many rules? The current approach is to open one PCAP interface per rule. The end goal is to be able to run an live application with 1000's of simultaneous rules. The issue is that the current pcap_open_* interfaces are pretty limited. I could open one pcap structure per rule. But for my eventual application, that would be bad. It would mean copying each packet from kernel space to user space, once for every rule. At gigabit speeds, we quickly become overloaded. I have some hardware which does a quick pass over the packet, binning it into one of N buckets. It uses a bloom filter approach to reject many packets which won't match any rule. The output of the HW is a tag which says "looks like it matches rule X". I'd like to be able to take that tag, and use it to feed the packet into a PCAP filter which does more in-depth checks. However... I can't do this right now. There's pcap_open_live() for interfaces. There's pcap_open_offline() for files. There's no interface which says "here's a packet, run the rule against it". I think that this may be possible, without too much work. I propose the following: 1) Create a function which will allow packet injection into pcap: typedef int (*pcap_read_callback)(pcap_t *p, void *ctx, u_char *buffer, int bufsize) This function would be called through pcap_read(). It would use a user-supplied context to write data into the buffer, and return the number of bytes written. 2) create a function which would open a "pcap" structure, using the above callback: pcap_t *pcap_open_callback(pcap_read_callback callback, void *ctx, char *ebuf, size_t size); The application could then open 1000's of these structures, as it's just memory. It would then get packets from the kernal (once), along with the hardware tag. The tag would tell it which pcap_t to use for more detailed checks. I think that API is fairly simple. It seems to fit with the current philosophy of the pcap library and API. Comments? Alan DeKok. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Query about running many, many, rules
On Jun 19, 2013, at 10:44 AM, Alan DeKok wrote:
> However... I can't do this right now. There's pcap_open_live() for
> interfaces. There's pcap_open_offline() for files. There's no
> interface which says "here's a packet, run the rule against it".
$ man pcap_offline_filter
PCAP_OFFLINE_FILTER(3PCAP) PCAP_OFFLINE_FILTER(3PCAP)
NAME
pcap_offline_filter - check whether a filter matches a packet
SYNOPSIS
#include
int pcap_offline_filter(struct bpf_program *fp,
const struct pcap_pkthdr *h, const u_char *pkt)
DESCRIPTION
pcap_offline_filter() checks whether a filter matches a packet. fp is
a pointer to a bpf_program struct, usually the result of a call to
pcap_compile(). h points to the pcap_pkthdr structure for the packet,
and pkt points to the data in the packet.
RETURN VALUE
pcap_offline_filter() returns the return value of the filter program.
This will be zero if the packet doesn't match the filter and non-zero
if the packet matches the filter.
SEE ALSO
pcap(3PCAP), pcap_compile(3PCAP)
Older versions of libpcap don't have that, but they might have bpf_filter(), in
which case you can make your own pcap_offline_filter() routine:
int
pcap_offline_filter(const struct bpf_program *fp, const struct
pcap_pkthdr *h,
const u_char *pkt)
{
const struct bpf_insn *fcode = fp->bf_insns;
if (fcode != NULL)
return (bpf_filter(fcode, pkt, h->len, h->caplen));
else
return (0);
}
Fill in a "struct pcap_pkthdr" (the filter doesn't look at the time stamp; all
it cares about is "caplen", which tells it how much packet data there is, and
"len", which tells it what the length is for the "len" value and the "less" and
"greater" tests), and pass that and a pointer to the raw packet data to
pcap_offline_filter().
To compile a filter, you could create a pcap_t with pcap_open_dead() (unless
you have a *really* old version of libpcap), passing it the appropriate DLT_
value for the particular set of link-layer headers and possible metadata
headers your packets have (if they have more than one, you'll need multiple
filters and run the appropriate one for each packet) and a snapshot length (all
you're doing with the filter is getting a "yes or no" answer, so just pass in a
non-zero value).
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Query about running many, many, rules
Guy Harris wrote: > Older versions of libpcap don't have that, Ah, that's why I couldn't find it. > Fill in a "struct pcap_pkthdr" (the filter doesn't look at the time stamp; > all it cares about is "caplen", which tells it how much packet data there is, > and "len", which tells it what the length is for the "len" value and the > "less" and "greater" tests), and pass that and a pointer to the raw packet > data to pcap_offline_filter(). > > To compile a filter, you could create a pcap_t with pcap_open_dead() (unless > you have a *really* old version of libpcap), passing it the appropriate DLT_ > value for the particular set of link-layer headers and possible metadata > headers your packets have (if they have more than one, you'll need multiple > filters and run the appropriate one for each packet) and a snapshot length > (all you're doing with the filter is getting a "yes or no" answer, so just > pass in a non-zero value). Thanks. Alan DeKok. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
