dhcpcd-discuss

On 6/15/20 4:29 AM, Roy Marples wrote:
> On 14/06/2020 22:57, Bruce Ferrell wrote:
> > > > As I said, there are a LOT on non-rfc3442 compliant dhcp clients in the world and accommodating dhcpcd breaks them without doing fiddly things to assure compliant messages are 
> > > > ONLY sent to dhcpcd and any other rfc3442 conformant dhcp client (are there any?).
> > >
> > > And this is just bogus.
> > Declare it bogus if you like, but the evidence says otherwise...
>
> What evidence? So me some logs. Here's mine.
>
> # ./dhcpcd -dB4
> dhcpcd-8.1.2 starting
> bridge0: ignoring due to interface type and no config
> re0: executing `/libexec/dhcpcd-run-hooks' PREINIT
> re0: executing `/libexec/dhcpcd-run-hooks' CARRIER
> DUID 00:04:03:2e:02:b4:04:99:05:c8:d8:06:2a:07:00:08:00:09
> re0: IAID 99:c8:d8:2a
> re0: IA type 25 IAID 00:00:00:01
> re0: delaying IPv4 for 0.1 seconds
> re0: reading lease `/var/db/dhcpcd/re0.lease'
> re0: rebinding lease of 10.73.0.61
> re0: ARP announcing 10.73.0.61 (1 of 2), next in 2.0 seconds
> re0: sending REQUEST (xid 0xe1033794), next in 4.4 seconds
> re0: acknowledged 10.73.0.61 from 10.73.0.1
> re0: leased 10.73.0.61 for 3600 seconds
> re0: renew in 1800 seconds, rebind in 3150 seconds
> re0: writing lease `/var/db/dhcpcd/re0.lease'
> re0: IP address 10.73.0.61/16 already exists
> re0: using Classless Static Routes
> re0: adding route to 10.73.0.0/16
> re0: adding default route via 10.73.0.1
> re0: adding route to 192.168.22.0/24 via 192.0.2.135
> re0: executing `/libexec/dhcpcd-run-hooks' REBOOT
> re0: bound, ignoring 10.73.0.61 from 10.73.0.1
> re0: ARP announcing 10.73.0.61 (2 of 2)
> ^Creceived SIGINT, stopping
> re0: removing interface
> re0: executing `/libexec/dhcpcd-run-hooks' STOPPED
> dhcpcd exited
>
> # ./dhcpcd -U4 re0
> broadcast_address=10.73.255.255
> classless_static_routes='0.0.0.0/0 10.73.0.1 10.73.0.0/16 0.0.0.0 192.168.22.0/24 192.0.2.135'
> dhcp_lease_time=3600
> dhcp_message_type=5
> dhcp_rebinding_time=3150
> dhcp_renewal_time=1800
> dhcp_server_identifier=10.73.0.1
> domain_name=marples.name
> domain_name_servers=10.73.0.1
> domain_search=marples.name
> host_name=cube
> ip_address=10.73.0.61
> network_number=10.73.0.0
> routers=10.73.0.1
> subnet_cidr=16
> subnet_mask=255.255.0.0
>
> # netstat -nrf inet
> Routing tables
>
> Internet:
> Destination        Gateway            Flags    Refs      Use Mtu Interface
> default            10.73.0.1          UGS         -        - -  re0
> 10.73/16           link#1             UC          -        - -  re0
> 10.73.0.61         link#1             UHl         -        - -  lo0
> 127/8              127.0.0.1          UGRS        -        - 33624  lo0
> 127.0.0.1          lo0                UHl         -        - 33624  lo0
> 192.168.22/24      192.0.2.135        UGS         -        - -  re0
>
> Default route option? check
> CSR option with default route? check
> Routes actually applied? check
> Same version as you? check
> Other devices still working? check
>
> > When I got the Raspberry PI to set proper routes, Windows and the Amazon devices all lost connection.  As I say, I didn't take time to check the OS X clients.  The PI version 
> > information is below. It's the 64 bit version. The regular 32 bit ones do this too.  I think we can agree the ISC dhcpd configuration WAS correct as the proper default route and 
> > static route was set on the PI.
>
> You know your Amazon Fire OS devices likely run dhcpcd as well?
>
> Roy
Roy,

You keep missing it.  I can make dcpcd work on the PI. That is NOT the issue... Well, it is, but it's in a different class.

When the configuration for ISC dhcpd makes the PI  work, Windows 10 (two different instances, both completely patched), a Samsung Note 8, a Kindle Fire 10 (2019) and several Amazon 
smart plugs are ALL unable to connect to the default gateway.

Does the Amazon Fire OS device run dhcpcd in client mode?  I don't know.  If it does, why does the PI work and the Fire OS device fail? Are you speculating the Fire OS device is 
running a bad version of dhcpcd or an incompatible configuration?   I think it's safe to say that Windows 10 does NOT run dhcpcd in any manner.  I have NO idea what the smart plugs 
run... I presume android in some form only becase it's so common, but they could be some form of ESP32 too.

I am NOT saying dhcpcd is bad.  I AM saying that the dhcp clients in the devices I listed behave VERY oddly when ISC dhcpd is configured in a manner that makes dhcpcd on the PI 
accept both a static route and a default gateway.

As I have more time, I do plan to look more deeply at this, including packet traces.  Logs are only so useful as they say what the code thinks it's doing. Packet traces are an 
absolute measure of the code is telling the device to put on the wire.

With your very kind assistance, I AM now able to unwind this in one way... It's not the way I want and is troubling, but I have a string to tug and track back.

Thank you for the assistance you've provided.