Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: Patch: Fix renewals, releases sent from wrong source
(Thor Simon)
----------------------------------------------------------------------
Message: 1
Date: Thu, 30 Apr 2020 15:40:18 +0000
From: Thor Simon <thor.si...@twosigma.com>
To: "dhcp-users@lists.isc.org" <dhcp-users@lists.isc.org>,
"j...@tla.org" <j...@tla.org>
Subject: Re: Patch: Fix renewals, releases sent from wrong source
Message-ID:
<95eca5a30210469a93413a9461a35...@exmbdft10.ad.twosigma.com>
Content-Type: text/plain; charset="us-ascii"
Apologies if I broke the threading, Outlook burped hard when handling the list
digest.
>Couple of things on this patch:
>
>1. does the faulty behavior you are trying to fix happen if you have
>explicitly set a more-specific route with a default src address for the
>traffic in question, thus using the >kernel's proper mechanism for setting the
>source address rather than replicating in the dhclient code?
The dhclient code doesn't conform to the documentation of when to use, or not
use, the fallback send API. The documentation says to use it if a message must
be routed. Any message with a recipient on the local network plainly need not
be routed and thus ought not use fallback.
Since there are even cases where we might be operating with _no_ working IP
address as far as the system's IP stack and routing table know (after all, this
is one of the reasons to ever send via the packet filter at all!), we clearly
should not use the socket-based fallback mechanism when we don't need to, and
in violation of its API contract as well. Consequently I believe this bug will
continue to cause issues and should be fixed so we obey the documented API,
such as it is.
In practice, since multiple successive mechanisms may be involved in the
selection of a source address by the system's networking stack (the VPN case on
Linux where *all of* the legacy routing table, policy routing, IPsec bypass
policy, and iptables may be and sometimes are _even simultaneously_ involved is
illustrative) if we want to be sure not just "a packet" but "a valid packet" is
emitted onto the local link we should make the "does it go on the local link or
get punted to the system stack" decision ourselves, which is what my patch (now
also bug #101 in the tracker) does.
>2. Fix your formatting, it's inconsistent with the surrounding code, and Vixie
>will probably be annoyed :)
I gave it my best, but the formatting was considerably inconsistent even
between the two sections of dhclient.c which I looked at while making the
change -- particularly with regard to spaces around unary operators and between
names and parentheses, so I was not (and am not) 100% sure what to do.
Thor
------------------------------
Subject: Digest Footer
_______________________________________________
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 139, Issue 1
******************************************
