workaround libpcap 4 extra bytes

[stubbsw]

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 Add full IPv6 support to fwknop #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.

[mrash]

Bill,

Thank you indeed for the patch. Quick question - what does pcap_datalink() return on your beaglebone system?

[stubbsw]

Michael,
pcap_datalink(pcap) returns: 1 == DLT_EN10MB
Happy to lend a hand.
- Bill

[mrash]

Ok, I wonder if your ethernet card is including the frame check sequence at the end of each ethernet frame? From what I understand, this is not very common, but some networking gear+driver combinations do return this info. Wireshark tries to compensate when the FCS is included: https://www.wireshark.org/faq.html#q7.10

One way to verify this might be to take a packet trace on the beaglebone with something like "tcpdump -i eth0 -l -nn -s 0 -c 10 -w 10pkts.pcap" and then move it to a system where you can examine the trace under wireshark to see if the FCS is included (I'm assuming wireshark will display this info).

Either way, I suspect that maybe fwknopd should try to handle ethernet frames where the FCS is included, so calculating the packet length from the IP header - as you did in your patch - may be the right strategy. If you have some extra cycles, could you examine the trace mentioned above with wireshark? Thanks.

[stubbsw]

Michael,
You are correct. It is the Ethernet FCS being included in the capture on
the BeagleBone system (confirmed with your suggested test). Previously I
had Wiresharked the outgoing packet (client) side (Ubuntu) in my earlier
debugging and was thrown off when the client captured packet not including
the FCS did not match the server side (BeagleBone) libpcap captured packet.
Good to know that this is system dependent.

I updated the pull request code to indicate this is expected behavior in a
small number of cases. Let me know if you have any other
comments/questions.

All the best,

• Bill

On Mon, Aug 18, 2014 at 8:11 PM, Michael Rash [email protected]
wrote:

Ok, I wonder if your ethernet card is including the frame check sequence
at the end of each ethernet frame? From what I understand, this is not very
common, but some networking gear+driver combinations do return this info.
Wireshark tries to compensate when the FCS is included:
https://www.wireshark.org/faq.html#q7.10

One way to verify this might be to take a packet trace on the beaglebone
with something like "tcpdump -i eth0 -l -nn -s 0 -c 10 -w 10pkts.pcap" and
then move it to a system where you can examine the trace under wireshark to
see if the FCS is included (I'm assuming wireshark will display this info).

Either way, I suspect that maybe fwknopd should try to handle ethernet
frames where the FCS is included, so calculating the packet length from the
IP header - as you did in your patch - may be the right strategy. If you
have some extra cycles, could you examine the trace mentioned above with
wireshark? Thanks.

—
Reply to this email directly or view it on GitHub
#125 (comment).

[mrash]

Oh, right, forgot that loopback won't have the FCS header. In that case, from the test/ directory, you can execute the client with the following command line (note the '1.1.1.1' IP - any off-box IP will work including your default gateway) and adjust your tcpdump command line to sniff from eth0: "LD_LIBRARY_PATH=../lib/.libs ../client/.libs/fwknop -A tcp/22 -a 127.0.0.2 -D 1.1.1.1 --no-save-args --verbose --verbose --rc-file conf/fwknoprc_default_hmac_base64_key"