[CDBUG-talk] BPF Berkeley Packet Filter Question
Juan Herrera
mybsdmailing at gmail.com
Wed Dec 30 10:39:25 EST 2015
Hello Steve, Greg
Indeed I am skipping IP, TCP, UDP headers
I am using raw ethernet, and testing with ARP
Brief Explanation of what I want to do
I am sending ARP requests packets(encapsulated with my metadata at the
end), so it is Raw Ethernet like this "ARP Req bytes + Metadata bytes", I
already did a test to filter with BPF jumbo ethernet packets and I can
filter if I want against the last byte in the packet, but to do this I need
to place in my program code the C filter code (generated with tcpdump),
exacly the byte position I want to use for filtering, so the issue with
this is that when I receive another ethernet frame that it is not an ARP
Req, the byte position to filter will not be the right one(because it
moves) to use because the packet is bigger or smaller so my metadata has
shift left or shift right depending on the case, so I want BPF to read the
total packet length to return it in a variable, and then I use this
variable to calculate the right byte to use for filtering, depending on the
packet length.
I need to match with a specific metadata field base on length, but dont
know how to use BPF to read packet's length
Thanks!
2015-12-30 9:09 GMT-06:00 Greg Troxel <gdt at lexort.com>:
>
> First, it's not clear from your mail that what you are doing is
> sensible. You seem to be skipping IP and perhaps using raw Ethernet,
> and insisting on adding fields at the end vs encapsulating. But you
> didn't explain and didn't ask...
>
> The bpf language is fairly powerful, but you'll have to write in BPF
> assembler because libpcap doesn't already have compilation support to do
> what you need. See bpf(4) - I suspect it is adequate to find the
> metadata field based on length. Certainly it can find the UDP header
> based on IP header length, and things like that.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nycbug.org/pipermail/cdbug-talk/attachments/20151230/e5b2f262/attachment.html>
More information about the CDBUG-talk
mailing list