Feature request

[GoogleCodeExporter]

Attached patch provides support for pcap_offline_filter().

The API is little hideous due to the fact that the packet header and buffer is 
tied to the handle and we can therefor only refer to the packet data that is 
currently buffered in the pcap-handle struct. However I find it of great use to 
define a set a filters and quickly apply them to a received packet without 
having to do inspection using gocode.

Original issue reported on code.google.com by lukas.l...@gmail.com on 26 Jul 2014 at 9:01

Attachments:

• filter.diff

[GoogleCodeExporter]

Hey, Lukas,

Thanks for the patch!  I'll work on integrating this during the next day or 
two, and send you an update as things progress.

Would you like your name added to the AUTHORS file?  If so, just let me know 
the email address to use, etc.

  --Graeme

Original comment by gconnell@google.com on 28 Jul 2014 at 5:26

• Changed state: Accepted

[GoogleCodeExporter]

It's "Lukas Lueg <lukas.lueg@gmail.com>"

I have no knowledge when pcap_offline_filter() was added to pcap or if it is 
available on all platforms; the function  may have to get stubbed.

Original comment by lukas.l...@gmail.com on 30 Jul 2014 at 6:49

[GoogleCodeExporter]

Hey, Lukas,

Just wanted to give you a quick update on this.  Work is in progress, I'm just 
doing a few tweaks to the API, and I should have something out early next week, 
Monday at the best.

Thanks again!

Original comment by gconnell@google.com on 1 Aug 2014 at 11:21

[GoogleCodeExporter]

This is out, as of 
https://code.google.com/p/gopacket/source/detail?r=e6b5b3373263a6d3e18506c02e984
940337b4ddf

Original comment by gconnell@google.com on 7 Aug 2014 at 2:46

• Changed state: Fixed

[GoogleCodeExporter]

Ok, thanks.

Be aware that there is a subtle change in the API which also now mismatches the 
docs: NewBPF() originally put the finalizer on the hidden field BPF.bpf instead 
of BPF{} itself; the point about not putting the finalizer on the struct (as 
loosely documented) is that some code outside of gopacket may put a finalizer 
on struct itself, causing a memory leak as C.pcap_freecode() is never called.

Original comment by lukas.l...@gmail.com on 7 Aug 2014 at 3:00

[GoogleCodeExporter]

Ah, interesting.  I actually put it on the &BPF{} instead of bpf.bpf because of 
this section of http://golang.org/pkg/runtime/#SetFinalizer :

"The argument x must be a pointer to an object allocated by calling new or by 
taking the address of a composite literal."

Since bpf.bpf does not technically fit that description, I felt it safer to use 
&BPF{} itself, which does.  Things work with the bpf.bpf way currently, but I 
worry that some future GC change might cause a breakage.

Original comment by gconnell@google.com on 7 Aug 2014 at 3:04

[GoogleCodeExporter]

I stumbled upon the same section, which gives a second requirement about the 
func-parameter and ends in " If either of these is not true, SetFinalizer 
aborts the program".

What I take away from this is that SetFinalizer does check if the pointer is 
actually maintained by the gc. Otherwise it would not be able to check the 
stated condition and "abort the program".

Original comment by lukas.l...@gmail.com on 7 Aug 2014 at 3:14