Re: dhcpcd -U6 /var/db/dhcpcd/alc0.lease6 incorrectly returns "dhcpcd is not running"

[Zack Newman]

> On Jul 2, 2021, at 2:15 PM, Zack Newman  wrote:
> 
> According to DHCPCD(8):
> 
> -U, --dumplease [interface]
>  Dumps the current lease for the interface to stdout.  If no
>  interface is given then all interfaces are dumped.  Use the -4 or
>  -6 flags to specify an address family.  If a lease is piped in
>  via standard input then that is dumped.  In this case, specifying
>  an address family is mandatory.
> 
> So piping in the actual lease should work. Having said that, dhcpcd -U6 alc0, 
> dhcpcd -U alc0, dhcpcd -U6, and dhcpcd -U all timeout:
> 
> beta# dhcpcd -U6 alc0
> dhcpcd_readdumptimeout
> beta# dhcpcd -U alc0
> dhcpcd_readdumptimeout
> beta# dhcpcd -U6 
> dhcpcd_readdumptimeout
> beta# dhcpcd -U  
> dhcpcd_readdumptimeout
> 
> I understand not backporting it. I will live without being able to dump the 
> lease until then.

Please ignore my last reply^. I am an idiot and tested those commands before 
properly digesting what you said Stuart about passing an invalid interface 
first. I rebooted my computer, and sure enough dhcpcd -U alc0 outputted my 
lease information. Clearly the man page said “piped in” not "pass as an 
argument". Doh!

Sorry for my carelessness and haste, and thanks again for the informative reply 
about Linux vs. OpenBSD vis-à-vis SECCOMP vs. pledge and most importantly the 
easy edit to /etc/rc that allows my “unique” configuration to work.

Thanks,
Zack

Re: dhcpcd -U6 /var/db/dhcpcd/alc0.lease6 incorrectly returns "dhcpcd is not running"

[Zack Newman]

According to DHCPCD(8):

-U, --dumplease [interface]
 Dumps the current lease for the interface to stdout.  If no
 interface is given then all interfaces are dumped.  Use the -4 or
 -6 flags to specify an address family.  If a lease is piped in
 via standard input then that is dumped.  In this case, specifying
 an address family is mandatory.

So piping in the actual lease should work. Having said that, dhcpcd -U6 alc0, 
dhcpcd -U alc0, dhcpcd -U6, and dhcpcd -U all timeout:

beta# dhcpcd -U6 alc0
dhcpcd_readdumptimeout
beta# dhcpcd -U alc0
dhcpcd_readdumptimeout
beta# dhcpcd -U6 
dhcpcd_readdumptimeout
beta# dhcpcd -U  
dhcpcd_readdumptimeout

I understand not backporting it. I will live without being able to dump the 
lease until then.

Re: dhcpcd -U6 /var/db/dhcpcd/alc0.lease6 incorrectly returns "dhcpcd is not running"

[Stuart Henderson]

On 2021-07-02, Zack Newman  wrote:
> Excellent reply. Thank you Stuart. Unfortunately, changing "rm -rf -- *” to 
> “rm -rf — !(dhcpcd)” and rebooting now causes the command to timeout:
>
> beta# dhcpcd -U6 /var/db/dhcpcd/alc0.lease6
> dhcpcd_readdumptimeout

I believe that should just be "alc0" not the path. Additionally I did
run into a problem when I was testing that to reply to your previous
mail, if an invalid interface was used with -U, the main dhcpcd process
would stop responding to further control connections (with a log message
in /var/log/daemon, "ps_ctl_dispatch: cannot handle another client").

I was about to report it upstream but had a look at the few post-7.4.0
commits and wondered about one of them; testing with git head it looks
like that did indeed fix it, so I've updated the version in ports to
include that. (I think it's not all that common a case so I'm not
planning on backporting to -stable for that, however it seems that
just avoiding using an invalid interface name avoids that issue
anyway).

Re: dhcpcd -U6 /var/db/dhcpcd/alc0.lease6 incorrectly returns "dhcpcd is not running"

[Zack Newman]

> On Jul 2, 2021, at 8:22 AM, jslee  wrote:
> 
> On Fri, 2 Jul 2021, at 10:29, Zack Newman wrote:
>> When I start dhcpcd during booting the “normal” way (i.e., rcctl enable 
>> dhcpcd), I am able to successfully dump the lease information 
>> associated with the alc0 interface (which is connected directly to my 
>> bridge modem); however when I start the command inside of 
>> /etc/hostname.alc0 during booting, I am unable to get lease information 
>> after. When the computer boots up, I successfully acquire a DHCPv6 
>> lease as well as have a /60 routed to me. My IPv6 connectivity runs 
>> just fine too.
> 
> Something that's not entirely clear to me here: why? if you are using
> prefix delegation, dhcpcd is interested in more of your interfaces than
> just your ISP-side... no?
> 
> I also use dhcpcd to handle v6 prefix delegation on my gateway
> and just start it in the normal way, no !foo in /etc/hostname.em0, or
> in fact on any other interfaces. Yet it all works quite reliably every
> boot
> 
> What am I missing here?
> 
> John

Your assumption that “dhcpcd is interested in more of your interfaces than just 
your ISP-side” is incorrect. It is only configured for alc0:

beta# cat /etc/dhcpcd.conf  
  
ipv6only
noipv6rs
nooption domain_name_servers
nooption domain_name
nooption host_name
nooption ntp_servers
nooption time_servers
leasetime -1
duid
persistent
option rapid_commit
require dhcp_server_identifier
slaac private
script ""
denyinterfaces lo0 em0 enc0 vlan0 vlan1 vlan2 vlan3 wg0 pflog0
allowinterfaces alc0
interface alc0
ipv6rs
iaid 0
ia_na 0
ia_pd 0/::/60

Even though my ISP dynamically assigns IPv4 and IPv6 addresses, for the 4+ 
years that I have been a customer it has never changed. If this becomes no 
longer true, then I will adjust my setup accordingly.

By having dhcpcd run via /etc/netstart, it becomes consistent with how dhclient 
works. This is not only an optics thing either. Since /etc/rc loads a temporary 
pf ruleset that allows the necessary DHCP and DHCPv6 traffic, I don’t have to 
add such rules in /etc/pf.conf as my “pass out quick” rule is sufficient for 
DHCP and DHCPv6 renewal (since that is sent unicast to the appropriate DHCP and 
DHCPv6 servers and the statefulness of pf allows the response traffic). By not 
having to have something like “pass in quick on alc0 inet6 proto udp from 
fe80::/10 port 547 to fe80::/10 port 546 no state”, I close a very small hole 
in my firewall allowing a rogue DHCPv6 server attempting to lease my interface 
IPs. After all, I don’t have “pass in quick on alc0 inet proto udp from any 
port 67 to any port 68 no state” just to handle that one-time multicast DHCP 
traffic.

Another benefit of having the appropriate IPv6 addresses assigned earlier is 
for daemons that get started before packaging daemons. For example, 
/var/unbound/etc/unbound.conf has a few options based on IP (e.g., 
outgoing-interface). If dhcpcd gets started “normally”, then alc0 will not have 
a globally-routable IPv6 address assigned to it by the time unbound starts 
leading to an error if you have specified any interface options.

Re: dhcpcd -U6 /var/db/dhcpcd/alc0.lease6 incorrectly returns "dhcpcd is not running"

[Zack Newman]

Excellent reply. Thank you Stuart. Unfortunately, changing "rm -rf -- *” to “rm 
-rf — !(dhcpcd)” and rebooting now causes the command to timeout:

beta# dhcpcd -U6 /var/db/dhcpcd/alc0.lease6
dhcpcd_readdumptimeout

Like before, IPv6 seems to be working fine otherwise. Any further insight?

Re: dhcpcd -U6 /var/db/dhcpcd/alc0.lease6 incorrectly returns "dhcpcd is not running"

[jslee]

On Fri, 2 Jul 2021, at 10:29, Zack Newman wrote:
> When I start dhcpcd during booting the “normal” way (i.e., rcctl enable 
> dhcpcd), I am able to successfully dump the lease information 
> associated with the alc0 interface (which is connected directly to my 
> bridge modem); however when I start the command inside of 
> /etc/hostname.alc0 during booting, I am unable to get lease information 
> after. When the computer boots up, I successfully acquire a DHCPv6 
> lease as well as have a /60 routed to me. My IPv6 connectivity runs 
> just fine too.

Something that's not entirely clear to me here: why? if you are using
prefix delegation, dhcpcd is interested in more of your interfaces than
just your ISP-side... no?

I also use dhcpcd to handle v6 prefix delegation on my gateway
and just start it in the normal way, no !foo in /etc/hostname.em0, or
in fact on any other interfaces. Yet it all works quite reliably every
boot

What am I missing here?

John

Re: dhcpcd -U6 /var/db/dhcpcd/alc0.lease6 incorrectly returns "dhcpcd is not running"

[Stuart Henderson]

On 2021-07-02, Zack Newman  wrote:
> When I start dhcpcd during booting the \xe2\x80\x9cnormal\xe2\x80\x9d
> way (i.e., rcctl enable dhcpcd), I am able to successfully dump the
> lease information associated with the alc0 interface (which is connected
> directly to my bridge modem); however when I start the command inside of
> /etc/hostname.alc0 during booting, I am unable to get lease information
> after. When the computer boots up, I successfully acquire a DHCPv6 lease
> as well as have a /60 routed to me. My IPv6 connectivity runs just fine
> too.

This is not a bug.

/etc/rc clears /var/run after starting the network (it can't do it earlier
because /var may be mounted over NFS). dhcpcd places its control socket
in /var/run/dhcpcd, so it is cleared as part of that.

You might get away with mv'ing the directory out of the way after starting
dhcpcd, and back again e.g. in rc.local, obviously it's a kludge.
Alternatively you'll need to either build your own copy of dhcpcd that
uses a different directory (set --rundir when you run configure), or
modify /etc/rc to skip that directory, e.g. by changing "rm -rf -- *"
to "rm -rf -- !(dhcpcd)". In both cases you will need to deal with
reinstating it after an OS update; if you use a custom dhcpcd then that
will need to be rebuilt from time to time; if you edited /etc/rc then
that will need to be reinstated after every update.

> I found a discussion on the blog
> (https://roy.marples.name/archives/dhcpcd-discuss/0003312.html
> )
> belonging to the creator but now former maintainer, Roy
> Marples, of dhcpcd where a similar issue was had by someone
> running dhcpcd on their ARM32 server running a custom Linux
> 4.9 kernel. After much back-and-forth, it was discovered
> to be an issue with privsep not having the system calls
> fcntl64, fstat64, and TCGETS available. Those calls were added
> (https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/privsep-
> linux.c
>  linux.c>) for Linux, and that fixed the issue. I realize that OpenBSD
> has pledge, so this may not be relevant at all and just a coincidence.

That is unrelated and is because Linux's closest equivalent to pledge
(SECCOMP) is too fine-grained to be usable without major pain in many
cases. So rather than saying "allow system calls that permit write
access to files" you must individually list the calls that currently
or might in the future be used for that - and they can vary depending
on machine architecture, also different libc's may use different calls
for the same basic operation, etc.