niklata / ndhc Goto Github PK

When rfkill is used (here, with a hardware switch), ndhc should consider the interface down (not sure how it can detect it gets up again, but it seems to "flap" from up -> down -> up when rfkill is toggled).

2015-02-13T10:16:38.38295 user.notice: ndhc: wlan0 hardware address a0:88:b4:a1:ce:50
2015-02-13T10:16:38.38309 user.notice: ndhc: wlan0: (rtnl_if_flags_send) netlink sendto returned NLMSG_ERROR: Operation not possible due to RF-kill
2015-02-13T10:16:38.38321 user.notice: ndhc: wlan0: (perform_ifup) Failed to set link to be up.
2015-02-13T10:16:38.38328 user.notice: ndhc: failed to set the interface to up state

p.s.: I hope you don't mind all the bugs I report, but I like ndhc a lot so far! You did a good job.

The check for glibc should not fail, but assume that -lrt is not required. This will simplify cross-building (where try_run doesn't work) and support alternative libc such as musl.

I'm on a network which uses DHCP proxying, thus the DHCP server is not on the same level-2 network and cannot be arppinged.

ndhc: ndhc client 1.5 started on interface [wlan0].
ndhc: wlan0: Discovering DHCP servers...
ndhc: wlan0: Received an offer of 10.181.15.152 from server 10.156.33.139.
ndhc: wlan0: Sending a selection request for 10.181.15.152...
ndhc: wlan0: UDP length [576] does not match header length field [328].
ndhc: wlan0: Sending a selection request for 10.181.15.152...
ndhc: wlan0: UDP length [576] does not match header length field [328].
ndhc: wlan0: Sending a selection request for 10.181.15.152...
ndhc: wlan0: Received a DHCP ACK with an unexpected server id: 10.156.33.138.  Ignoring it.
ndhc: wlan0: Accepted a firm offer for 10.181.15.152.  Validating...
ndhc: wlan0: arp: Probing for hosts that may conflict with our lease...
ndhc: wlan0: arp: Probing for hosts that may conflict with our lease...
ndhc: wlan0: Lease of 10.181.15.152 obtained.  Lease time is 2400 seconds.
ndhc: wlan0: Sent to ifchd: 'ip4:10.181.15.152,255.255.240.0,10.181.15.255;routr:10.181.15.254;dns:10.156.33.53,129.187.5.1;dom:eduroam.mwn.de;'
ndhc: wlan0: arp: Searching for dhcp server and gw addresses...
ndhc: wlan0: Interface IP, subnet, and broadcast were already OK.
ndhc: wlan0: Gateway router set to: '10.181.15.254'
ndhc: Added DNS server: '10.156.33.53,129.187.5.1'
ndhc: wlan0: arp: Gateway hardware address d8:67:d9:6e:9b:42
ndhc: Added DNS domain: 'eduroam.mwn.de'
ndhc: wlan0: Commands received and successfully executed.
ndhc: wlan0: arp: Still looking for DHCP server hardware address...
ndhc: wlan0: arp: Still looking for DHCP server hardware address...
ndhc: wlan0: arp: Still looking for DHCP server hardware address...

ndhc will look for eternity to get the DHCP server hardware address, but the server is in a different segment:

% tracepath 10.156.33.138 -n
 1?: [LOCALHOST]                                         pmtu 1500
 1:  10.181.15.254                                        16.662ms 
 1:  10.181.15.254                                        17.455ms 
 2:  129.187.0.137                                         7.956ms 
 3:  10.156.33.138                                         2.882ms reached
     Resume: pmtu 1500 hops 3 back 62 

I'm not sure what having "got_server_arp" is actually good for.

-l, --leasefile doesn't exist anymore but is still in the manpage.

-s, --state-dir and -t, --gw-metric are not in the manpage.

There is a formatting error for the -H option and between -H and -S.

After ndhc initialization, for loop inside ndhc.c starts getting CPU hungry. It takes 100% CPU not doing anything usefull besides epoll_wait with 0 timeout.

I uploaded a truncated strace even if ndhc continues with epoll_wait with 0 timeout.

http://dpaste.com/1TA8Z64

It seems like ISC's dhcpcd has support for prepending a /etc/resolv.conf.head and appending a /etc/resolv.conf.tail when it writes out /etc/resolv.conf. Support for this in ndhc would be very nice.

In a cross-build environment, CMakeList still runs uname -m to find out the compile flags. Provide an option to override the MACHINENAME or detect CMAKE_CROSSCOMPILING / CMAKE_C_COMPILER_TARGET.

After unplugging ethernet while the machine is suspended, ndhc doesn't notice the interface doesn't have a carrier anymore and tries sending renew requests. I fear this cannot be dealt with without polling (or an additional ioctl somewhere), as linux happily sendto(2)s to an interface without carrier...

I don't know how much of an inconvenience it is to require Ragel to be installed when building ndhc. If it's enough of a problem that it deters people from trying out or using ndhc, then a simple solution is to bundle pregenerated Ragel output files into the repository. This approach is already seen with many other projects for quite some time, such as fftw and its ocaml-generated output that most users are never aware of.

This of course will require a bit of effort to make sure that on my local machines the files are always rebuilt as I test, but that's easily done.

Would this be helpful?