| Commit message (Collapse) | Author | Age |
| | |
|
| |
|
|
|
|
|
|
|
| |
Just have the one callback, but return an abstracted event mask
to work out if we can read/write have something else.
Log diagnostics if the event mask is unexpected.
While here add more logging if we fail to register an event to
monitor.
|
| | |
|
| |
|
|
|
|
|
|
| |
kqueue allows for O(1) processing of active fd's an a more
robust signal handling method without the need to use global
variables to avoid calling functions during signal delivery.
The problems with the prior implemenation have now been fixed.
|
| | |
|
| |
|
|
| |
A 3rd party might want to control the randomisation.
|
| |
|
|
| |
We can now remove the NOCARRIER_PRESERVE_IP define.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is given when the OS supports the concept of wireless roaming
or the IP setup can be persisted when the carrier drops.
When this happens, routes are moved to a higher metric (if supported)
to support non preferred but non roaming routes.
The `interface_order` hook variable will now order the interfaces
according to priority and move roaming interfaces to the back of the
list.
If resolvconf is present then it is called with the -C option
to deprecate DNS and if carrier comes back it is called again with the
-c option to activate it once more.
As part of this change, default route metrics have been changed to
support a larger number of interfaces.
base metric 1000 (was 200)
wireless offset 2000 (was 100)
IPv4LL offset 1000000 (was 10000)
roaming offset 2000000
|
| |
|
|
|
|
|
|
|
|
|
| |
Since version 9.3.3 and commit a5348dd02c86fa940cd93f203d0aa974cae0563c,
build without fork or signals fails on:
dhcpcd.c: In function ‘main’:
dhcpcd.c:2261:3: error: label ‘start_master’ used but not defined
goto start_master;
^~~~
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is achieved by checking that the interface is wireless,
IFF_UP and IFF_LOWER_UP are present, but IFF_RUNNING is missing.
This gives exactly the same support as modern NetBSD when carrier
loss is detected, but without the address verifications when the
carrier comes back as that needs to be handled in the kernel.
While IP setup is maintained, other configuration data is discarded.
Note that this should be improved in the future.
Thanks to Boris Krasnovskiy <borkra@gmail.com> for helping with this.
|
| | |
|
| |
|
|
| |
If a value is given, it overrides /var/db/dhcpcd/duid.
|
| |
|
|
| |
This only works for non master mode.
|
| | |
|
| |
|
|
| |
There is little point.
|
| |
|
|
| |
This allows `dhcpcd -U4 eth0` to work once more.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
logclose is meant to free resources.
On Linux this means that _log_prog is also free'd and once in the
chroot we cannot work it out again.
As such allow logopen to close what it needs to so that reopening
works.
|
| |
|
|
|
|
| |
Now that only the privileged actioneer does the actual logging
we can safely reopen the file we are logging to.
This also closes and re-opens the syslog connection.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If dhcpcd starts and no syslogd implementation is running then
various syscall filters could be triggered when dhcpcd wants to syslog
and it's already in a chroot.
Not all libc openlog implementations support LOG_NDELAY and
openlog does not return an error code and can also mask errno back to 0.
So we have no way of knowing if we have a syslog connection or not.
This means we cannot cache the connection at startup because syslog itself
will try and open if no connection.
As such, all logging is now directed to the dhcpcd privileged actioneer
process which will handle all the syslog and log file writing actions.
The only downside of this approach (other than an extra fd per process)
is that we no longer know which PID raised the message. While we could
put the correct PID in the logfile as we control the API, we cannot
put it into syslog as we cannot control that API.
As all privsep errors should log which function they came from this
will hopefully not be an issue as on the happy path only the master
process will log stuff.
|
| | |
|
| |
|
|
|
| |
The two could be different!
envp is NOT C or POSIX standard, but does appear to be a UNIX standard.
|
| |
|
|
|
|
|
|
|
| |
Linux PRCTL variant, although more light weight, doesn't work on
some kernels.
This weighs in around 1k more, but always works.
It does play around with environ and args but unlike other
similar variants doesn't appear to stamp on what you actually
use in the program.
|
| | |
|
| |
|
|
|
|
| |
And the sandbox tech as well.
Rework stop_interface so we can reuse an option for marking
a process as the launcher.
|
| |
|
|
|
|
|
| |
Move the IS_LINK_UP macro to if_is_link_up function to reduce
binary size.
Rather than DHCPCD_LINK option controlling the carrier state,
use it in if_is_link_up to determine the outcome.
|
| |
|
|
|
|
| |
Removes the need for the LINK_DOWN_IFFUP state.
While here, remove the check for IFF_RUNNING when LINK_UNKNOWN
because that is OS specific.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Vastly improve and simplify link detection on BSD.
dhcpcd either examines the whole system via getifaddrs(3) or
reacts to events via route(4).
In both cases we have struct if_data which has ifi_link_state.
Armed with this knowledge, we no longer need SIOCGIFDATA or
SIOCGIFMEDIA.
To solve the issue of newly attached interfaces having
LINK_STATE_UNKNOWN or some interfaces not even changing it,
we only change the local knowledge of interface flags when
reports them by getifaddrs(3) or route(4) when we change them.
For example, if we set IFF_UP and it succeeds we don't set this
internally until reported by the kernel as above.
This keeps flags and link state in sync with each other.
The hope is that the kernel can set the real link state before
it reports IFF_UP.
As such, we no longer require the poll option or need to enter a
tight loop for old interfaces.
|
| | |
|
| | |
|
| |
|
|
| |
the interface or not.
|
| |
|
|
| |
The privileged actioneer will remove it.
|
| |
|
|
|
| |
rather than using kill which is not permitted in capsicum.
This also allows us to drop the proc pledge.
|
| | |
|
| |
|
|
| |
Also add os_init incase other os need similar in the future.
|
| |
|
|
|
|
|
|
|
| |
UNIX application expect these to exist even if pointed at /dev/null.
We cannot change which fd they use, it's always 0, 1 and 2.
But if these fd's are not open when dhcpcd is called, they could
be assigned to dhcpcd internals.
In this instance we should not use the streams in anyway or form.
|
| |
|
|
|
| |
Should not happen on the happy path, but if it does, tidy the
resultant errors.
|
| | |
|
| |
|
|
| |
When the process exits which is normal.
|
| | |
|
| |
|
|
|
| |
Otherwise some utils in scripts will error with insufficient
capabilities.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This actually make life really simple!
We no longer need to redirect stdout/stderr to /dev/null for privsep
and any script output is now captured again - and it all goes to stderr
as it should even if a script wants it to go to stdout.
On the happy path, only the master process will actually log anything
to stderr so we turn that off after we "fork".
On the unhappy path, logging to stderr/stdout *may* fail because
the launcher process *may* have exited.
We *could* have the master process as an intermediary but that's
just excess code to avoid errors which *should* not happen.
Regardless, any errror should still hit syslog.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Rather than duping stderr down to the processes.
This allows us to reopen stdout and stderr onto /dev/null right
away and means only the launcher process writes to stderr.
The downside is that any stdout from the script is now lost.
If that's needed, we could setup a stdout socketpair as well.
|
| | |
|