types are almost identical (same number of fields, each field has the
same length), so the code worked anyway, but nlattr and rtattr are
distinct.
nlattr is the type/length part of the nlmsg header. rtattr is the
type/length part of the individual rt attribute items attached after
a nlmsg.
Use the correct rtattr type, and use the standard macros where appropriate.
manually be set to an 'up' state before much of anything can be changed.
Ensure that this is done very early in ndhc's lifetime, and record the
link status at startup time so that the hardware link status monitoring
will not get confused. A perform_ifup() function is added to faciliate
this need.
Handle nl_getifdata() and get_if_index_and_mac() separately from the
hardware link status monitoring; don't call get_if_index_and_mac() from
nl_process_msgs().
Create the permanent ndhc-master cs.nlFd socket for hardware link status
monitoring after forking subprocesses.
being updated, so perform status debouncing.
While ifch is doing work, the netlink events are ignored. Once ifch has
finished its work, netlink events are no longer ignored. Making this
work requires ifch to communicate back to ndhc, but it is no problem
since the necessary pipes are already in place for IPC.
DHCP-assigned IP, broadcast, and subnet.
The nl_foreach_nlmsg() gains a seq parameter that when set to non-0 will
cause nl_foreach_nlmsg() to ignore any nlmsg that has a seq number
that does not match the caller-supplied seq argument.
zeroing the send buffer. It's less finicky than special-casing the
ip4 command to use strnkcpy instead of strnkcat.
At the same time, centralize the command print code on the send side.
It can just live in pipewrite() rather than the callers.
Also, background() and setup_signals_ndhc() are moved from sys.c to ndhc.c.
background() also no longer attempts to re-configure signals; signals are
always set up on initial ndhc initialization.
subprocesses. ndhc-ifch can then use the stored interface index when
setting the interface ip/subnet/broadcast via netlink instead of having
to use ioctl to re-fetch the interface index.
not be longer than the total option length.
A lying field sent by the DHCP server could possibly read data past the end of
the options field in the dhcp packet into the returned options data buffer.
It's hard to see how this could lead to an exploit because the total length
of data read into the options data buffer was indeed properly length-checked
so that it is impossible to overrun the destination buffer. Thus, this
problem is at worst a read-too-far with no ability to write to unexpected
locations.
The worst possible outcome is a program crash/DoS, depending on memory
layout. Information disclosure is not an issue because this is on the
path where the consumer of the destination buffer is ndhc, not the remote
DHCP server.
