Workaround for libpcap returning a length that is 4 bytes longer than
the
packet on the wire. 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)
Calculate the new pkt_end from the length in the ip header.
External IP resolution via '-R' (or '--resolve-ip-http') is now done via SSL by
default. The IP resolution URL is now 'https://www.cipherdyne.org/cgi-gin/myip',
and a warning is generated in '-R' mode whenever a non-HTTPS URL is specified
(it is safer just to use the default). The fwknop client leverages 'wget' for
this operation since that is cleaner than having fwknop link against an SSL
library.
With this commit PF rules are added correctly regardless of whether ALTQ support
is available or not. Thanks to Barry Allard for discovering and reporting this
issue. Closes issue #121 on github.
Bug fix discovered with the libfiu fault injection tag
"fko_get_username_init" combined with valgrind analysis. This bug
is only triggered after a valid authenticated and decrypted SPA
packet is sniffed by fwknopd:
==11181== Conditional jump or move depends on uninitialised value(s)
==11181== at 0x113B6D: incoming_spa (incoming_spa.c:707)
==11181== by 0x11559F: process_packet (process_packet.c:211)
==11181== by 0x5270857: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.4.0)
==11181== by 0x114BCC: pcap_capture (pcap_capture.c:270)
==11181== by 0x10F32C: main (fwknopd.c:195)
==11181== Uninitialised value was created by a stack allocation
==11181== at 0x113476: incoming_spa (incoming_spa.c:294)
