dhcpcd-discuss

Something else I noticed. From bpf-filter.h with notes in comments:

static const struct bpf_insn arp_bpf_filter [] = {
#ifndef BPF_SKIPTYPE
       /* Make sure this is an ARP packet... */
       BPF_STMT(BPF_LD + BPF_H + BPF_ABS, 12),
       BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, ETHERTYPE_ARP, 0, 3), /* should be 5 ... */
#endif
       /* Make sure this is an ARP REQUEST... */
       BPF_STMT(BPF_LD + BPF_H + BPF_ABS, 20 + BPF_ETHCOOK),
       BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, ARPOP_REQUEST, 2, 0),
       /* or ARP REPLY... */
       BPF_STMT(BPF_LD + BPF_H + BPF_ABS, 20 + BPF_ETHCOOK), /* this line isn't strictly necessary */
       BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, ARPOP_REPLY, 0, 1), /* if it is 3 then we jump here */
       /* If we passed all the tests, ask for the whole packet. */
       BPF_STMT(BPF_RET + BPF_K, BPF_WHOLEPACKET),
       /* Otherwise, drop it. */
       BPF_STMT(BPF_RET + BPF_K, 0),
};

This can be confirmed by putting the pcap filter through a BPF compiler.

arp && (arp[6:2] == 1 || arp[6:2] == 2)

Compiles to:

static const struct bpf_insn arp_bpf_filter [] = {
#ifndef BPF_SKIPTYPE
       /* Make sure this is an ARP packet... */
       BPF_STMT(BPF_LD + BPF_H + BPF_ABS, 12),
       BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, ETHERTYPE_ARP, 0, 5),
#endif
       /* Make sure this is an ARP REQUEST or REPLY... */
       BPF_STMT(BPF_LD + BPF_H + BPF_ABS, 20 + BPF_ETHCOOK),
       BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, ARPOP_REQUEST, 1, 0),
       BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, ARPOP_REPLY, 0, 1),
       /* If we passed all the tests, ask for the whole packet. */
       BPF_STMT(BPF_RET + BPF_K, BPF_WHOLEPACKET),
       /* Otherwise, drop it. */
       BPF_STMT(BPF_RET + BPF_K, 0),
};

Nate Karstens

From: Karstens, Nate [mailto:Nate.Karstens@xxxxxxxxxx]
Sent: Thursday, December 10, 2015 8:00 AM
To: dhcpcd-discuss@xxxxxxxxxxxx
Subject: [dhcpcd-discuss] Yocto Build and Feature Request

Greetings,

First, let me thank you for your work on dhcpcd. We needed a DHCP client with good auto-IP fallback. The ISC dhclient and udhcpc seem to have some support for this when paired with an auto-IP client like avahi-autoipd, but dhcpcd continues to search for DHCP servers even after assigning a link local address, which is perfect.

We use Yocto to cross-compile for an ARM processor, but ran into a problem compiling dhcpcd in this environment. I have a fix that I'd like to run by you and a feature request that I hope you'll consider.

First, the cross-compiling issue manifested itself as a compile error related to some assembly code. Part of what Yocto does it to set up a build environment that contains the header files, libraries, etc. of the target system instead of the host system. One of the sections of dhcpcd's configure script adds a path to the header files on the build system. This causes the build system's header files to be used, which leads to x86 assembly code being introduced for the network byte order functions (e.g., htons). The change to fix this has been posted to http://patches.openembedded.org/patch/109521/. It seems to work well enough for Yocto, but I didn't know if that section of the script is needed for another platform.

Now for the feature request. Our environment is slightly different from traditional networking environments in that the DHCP server is not necessarily running when the client is started; it may be started much later. dhcpcd will continue to search for DHCP servers in this scenario, but the interval between DISCOVER messages increases until it reaches a maximum of 64 seconds (as recommended by RFC 2131). We'd like to be able to specify the maximum interval between messages so that the DHCP client can acquire a local address much faster. Unless I'm overlooking a configuration option it doesn't look like there is a way to do this. I propose introducing a "--maxinterval" parameter that defaults to 64. I have a local patch that accomplishes this and if you'd like I can clean it up, add documentation, and pass it along.

Thanks,

Nate Karstens

________________________________

CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be confidential and/or legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.