workaround libpcap 4 extra bytes

Ran into an issue trying to hide/secure an internet-of-things style group of tiny beaglebone servers with fwknop.. a bit of debugging later and I noticed that libpcap was giving fwknopd back a length that is 4 bytes longer than the packet on the wire.  This was observed on:
- Linux beaglebone 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 armv7l GNU/Linux
- ldd fwknopd:
 - libfko.so.2 => /usr/local/lib/libfko.so.2 (0xb6f62000)
 - libpcap.so.0.8 => /usr/lib/arm-linux-gnueabihf/libpcap.so.0.8 (0xb6f20000)
 - libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6e3b000)
 - /lib/ld-linux-armhf.so.3 (0xb6f94000)
 - libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6e17000)

I didn't dive in to the libpcap code to see if the specific linked version has a bug or a different usage style.  I just went straight to calculating the new pkt_end from the length in the provided in the packet's IP header. This results in a fwknopd that is able to correctly parse the captured packet on the beaglebone and passes all the same tests that the unmodified code did (both fail: [Rijndael+HMAC] [FUZZING] pkts from fko-wrapper due to "fko-wrapper/send_spa_payloads does not exist").

No worries if you don't feel that this workaround should be pulled into master, I just wanted it to be available out there for anyone else interested in securing a beaglebone with the latest fwknopd and the current versions of the shared libs.