-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patch applied, with a comment to explain the logging stuff.
Cheers, Simon. On 19/04/15 22:16, Vladislav Grishenko wrote: > Simon, thanks As for reasons, I guess, Steven thought it departs > from ordinal meaning of RFC and prevents his odhcp6c to work > normally. > > p.s in my previous mail was a typo, RFC 2119, of course, not 2219. > sorry > > Best Regards, Vladislav Grishenko > >> -----Original Message----- From: Simon Kelley >> [mailto:si...@thekelleys.org.uk] Sent: Monday, April 20, 2015 >> 1:21 AM To: Vladislav Grishenko; 'Win King Wan' Cc: >> dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: >> [Dnsmasq-discuss] Don't reply to requests for DHCPv6 > addresses >> when M flag is off >> > > My feeling is that this is a better solution, and I'm inclined to > apply >> the patch. > Does anyone know what caused openWRT to revert the patc h? > > > Cheers, > > Simon. > > > > On 17/04/15 12:51, Vladislav Grishenko wrote: >>>> Hi, >>>> >>>> Per RFC 3315 17.2.1 the server MAY discard the Solicit >>>> message, but per 17.2.2, if the server will not assign any >>>> addresses to any IAs in a subsequent Request from the client, >>>> the server MUST send an Advertise message to client. Also, >>>> per RFC 2219 MAY is truly optional item, and MUST be prepared >>>> to interoperate with another inverse option existence >>>> implementation. So, interpreting that dnsmasq may not respond >>>> at all in stateless mode into RFC 3315 17.2.1 seems a bit >>>> farfetched. >>>> >>>> In real world, absence of Advertise message with NoAddrsAvail >>>> Status Code may lead to client misbehavior and prevent it >>>> from fallback to DHCPv6 Stateless mode, because RFC 3315 >>>> doesn't state any non-zero MRC & MRD non-zero values by >>>> default for Solicit messages transmission. Example of such >>>> client is https://github.com/sbyx/odhcp6c Also, openwrt has >>>> already reverted this change, refer >>>> > https://dev.openwrt.org/browser/trunk/package/network/services/dnsmas > > q > /patch >>>> >>>> > es/200-fix-dhcpv6-solicit-handling.patch >>>> >>>> Since the original issue was in log flooding, log error only >>>> for non-stateless contexts and threat it as false-positive >>>> error if it's expected due the configuration. Please refer >>>> patch attached. >>>> >>>> Best Regards, Vladislav Grishenko >>>> >>>>> -----Original Message----- From: Dnsmasq-discuss >>>>> [mailto:dnsmasq-discuss- boun...@lists.thekelleys.org.uk] >>>>> On Behalf Of Simon Kelley Sent: Thursday, January 22, 2015 >>>>> 2:02 AM To: dnsmasq-discuss@lists.thekelleys.org.uk >>>>> Subject: Re: [Dnsmasq-discuss] Don't reply to requests for >>>>> DHCPv6 >>>> addresses >>>>> when M flag is off >>>>> >>>> My first reaction to this was to apply it, but then I went >>>> and looked at RFC3315, and found this: >>>> >>>> If the server will not assign any addresses to any IAs in a >>>> subsequent Request from the client, the server MUST send an >>>> Advertise message to the client that includes only a Status >>>> Code option with code NoAddrsAvail and a status message for >>>> the user, a Server Identifier option with the server's DUID, >>>> and a Client Identifier option with the client's DUID. >>>> >>>> Which seems to indicate that the patch would violate the >>>> RFC. >>>> >>>> But then I looked some more, and found this: >>>> >>>> 17.2.1. Receipt of Solicit Messages >>>> >>>> >>>> The server determines the information about the client and >>>> its location as described in section 11 and checks its >>>> administrative policy about responding to the client. If the >>>> server is not permitted to respond to the client, the server >>>> discards the Solicit message. For example, if the >>>> administrative policy for the server is that it may only >>>> respond to a client that is willing to accept a Reconfigure >>>> message, if the client indicates with a Reconfigure Accept >>>> option in the Solicit message that it will not accept a >>>> Reconfigure message, the servers discard the Solicit >>>> message. >>>> >>>> >>>> So I think we can define "DHCPv6 address allocation not >>>> configured" as administrative policy and chose to discard the >>>> solict message in this >>>>> case. >>>> >>>> Patch applied, with some style changes, thanks. >>>> >>>> >>>> Cheers, >>>> >>>> Simon. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 19/01/15 21:30, Win King Wan wrote: >>>>>>> Hi, >>>>>>> >>>>>>> In https://github.com/RMerl/asuswrt-merlin/pull/854 I >>>>>>> patched the dnsmasq version of my router's firmware to >>>>>>> not send out replies to DHCPv6 queries when dhcp-range >>>>>>> mode is ra-stateless. >>>>>>> >>>>>>> Even though the M flag is off in the router >>>>>>> advertisement, Windows 8 (and newer) clients will still >>>>>>> request an address via DHCPv6. When it receives a reply >>>>>>> that no addresses are available, it tries a few more >>>>>>> time before giving up for several minutes. After >>>>>>> several minutes however it retries. This causes the >>>>>>> syslog to be filled up with noise stating that there >>>>>>> are no DHCPv6 addresses available for a specific MAC >>>>>>> address. (--quiet-dhcp6 does not help much as the "no >>>>>>> addresses available" message is always logged.) >>>>>>> >>>>>>> My changes basically stops dnsmasq from sending this >>>>>>> reply. Since the O flag is on, Windows 8 will try to >>>>>>> get other information from the DHCPv6 server if it does >>>>>>> not get an reply for its initial request for an address >>>>>>> (which seems to still work, as it is able to get the >>>>>>> IPv6 DNS server). >>>>>>> >>>>>>> After running Wireshark for quite some time, it appears >>>>>>> that Windows 8 will not send out subsequent requests >>>>>>> for an IPv6 address to the DHCPv6 server (after my >>>>>>> patch), at least not within several minutes. >>>>>>> >>>>>>> I have included the patch for completeness sake. Would >>>>>>> it be possible to apply it? Or perhaps there is a >>>>>>> better or more elegant solution to this problem? >>>>>>> >>>>>>> diff --git a/src/rfc3315.c b/src/rfc3315.c index >>>>>>> ddb390b..1f3646a 100644 --- a/src/rfc3315.c +++ >>>>>>> b/src/rfc3315.c @@ -824,6 +824,19 @@ static int >>>>>>> dhcp6_no_relay(struct state *state, int msg_type, void >>>>>>> *inbuff, size_ } else { + int all_stateless = 1; + >>>>>>> for (c = state->context; c; c = c->current) + if >> (!(c->flags >>>>>>> & CONTEXT_RA_STATELESS)) + { + >> all_stateless > = >>>>> 0; + >>>>>>> break; + } + if (all_stateless) + >>>>>>> /* >>>>> Windows 8 >>>> always >>>>>>> requests an address even if the Managed bit + in RA >>>>>>> is >>>>> 0 and >>>> it >>>>>>> keeps retrying if it receives a reply + stating >>>>>>> that no addresses are available */ + return 0; + /* no >>>>>>> address, >>>>> return >>>>>>> error */ o1 = new_opt6(OPTION6_STATUS_CODE); >>>>>>> put_opt6_short(DHCP6NOADDRS); >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ > Dnsmasq- >>>> discuss >>>>>>> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk >>>>>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >>>>>>> >>>>> >>>>> >>>>>>> > >>>>>>> _______________________________________________ >>>>> Dnsmasq-discuss mailing list >>>>> Dnsmasq-discuss@lists.thekelleys.org.uk >>>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > >>>>> > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlU1ZA8ACgkQKPyGmiibgreepQCgl7y0zOlL7MsMsat587kpUb6Q qpoAoIdsiTDZZFBK9Gs+qSYUpO1wjo7I =dQuu -----END PGP SIGNATURE----- _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss