{"action":"created","issue":{"url":"https://api.github.com/repos/sbyx/odhcp6c/issues/39","labels_url":"https://api.github.com/repos/sbyx/odhcp6c/issues/39/labels{/name}","comments_url":"https://api.github.com/repos/sbyx/odhcp6c/issues/39/comments","events_url":"https://api.github.com/repos/sbyx/odhcp6c/issues/39/events","html_url":"https://github.com/sbyx/odhcp6c/pull/39","id":115828777,"number":39,"title":"Handle NoAddrsAvail/NoPrefixAvail errors during Solicits.","user":{"login":"timonvo","id":364229,"avatar_url":"https://avatars.githubusercontent.com/u/364229?v=3","gravatar_id":"","url":"https://api.github.com/users/timonvo","html_url":"https://github.com/timonvo","followers_url":"https://api.github.com/users/timonvo/followers","following_url":"https://api.github.com/users/timonvo/following{/other_user}","gists_url":"https://api.github.com/users/timonvo/gists{/gist_id}","starred_url":"https://api.github.com/users/timonvo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/timonvo/subscriptions","organizations_url":"https://api.github.com/users/timonvo/orgs","repos_url":"https://api.github.com/users/timonvo/repos","events_url":"https://api.github.com/users/timonvo/events{/privacy}","received_events_url":"https://api.github.com/users/timonvo/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-11-09T08:18:05Z","updated_at":"2015-11-10T08:26:36Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/sbyx/odhcp6c/pulls/39","html_url":"https://github.com/sbyx/odhcp6c/pull/39","diff_url":"https://github.com/sbyx/odhcp6c/pull/39.diff","patch_url":"https://github.com/sbyx/odhcp6c/pull/39.patch"},"body":"According to RFC3315, Sec 17.2.2, if a \"server will not assign any\r\naddresses ... it MUST send an Advertise message ... with code\r\nNoAddrsAvail\". RFC3633 Sec 11.1 specifies the same about\r\n\"NoPrefixAvail\" errors.\r\n\r\nHence, if a client specifies *both* an IA_NA *and* an IA_PD option\r\nin a Solicit request from a server that is configured to only handle\r\nprefix delegations, or vice versa, that server will return an error.\r\n\r\nPreviously, in that case the client would get stuck retrying the\r\nexact same Solicit request. However, if the user specified that\r\neither address assignments or prefix delegations are optional, then\r\nthe client can instead retry the Solicit request just an IA_NA or\r\nIA_PD option (instead of both). That way it would still be able to\r\nsuccessfully receive a prefix delegation from a server that does not\r\nserve address assignments, or an address assignment from a server\r\nthat does not serve prefix delegations.\r\n\r\nAdditionally, if a client receives an UnspecFail error, it should\r\nnot try to handle the response, and instead retry later. RFC7083 Sec\r\n7 specifies that:\r\n\r\n    If a DHCPv6 client receives a message containing a SOL_MAX_RT\r\n    option that has a valid value for SOL_MAX_RT, the client MUST\r\n    set its internal SOL_MAX_RT parameter\r\n\r\nSo I've assumed that SOL_MAX_RT/INF_MAX_RT options should still be\r\nhandled even in the case of UnspecFail errors.\r\n\r\nI hit upon this issue after I tried to use the Asus RT-AC87U router with ISP\r\nWave G, whose DHCP server only support prefix delegation. Using a clean\r\nand up-to-date odhcp6c build I hit the same proble, but after this fix\r\nDHCPv6 does work properly."},"comment":{"url":"https://api.github.com/repos/sbyx/odhcp6c/issues/comments/155356547","html_url":"https://github.com/sbyx/odhcp6c/pull/39#issuecomment-155356547","issue_url":"https://api.github.com/repos/sbyx/odhcp6c/issues/39","id":155356547,"user":{"login":"timonvo","id":364229,"avatar_url":"https://avatars.githubusercontent.com/u/364229?v=3","gravatar_id":"","url":"https://api.github.com/users/timonvo","html_url":"https://github.com/timonvo","followers_url":"https://api.github.com/users/timonvo/followers","following_url":"https://api.github.com/users/timonvo/following{/other_user}","gists_url":"https://api.github.com/users/timonvo/gists{/gist_id}","starred_url":"https://api.github.com/users/timonvo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/timonvo/subscriptions","organizations_url":"https://api.github.com/users/timonvo/orgs","repos_url":"https://api.github.com/users/timonvo/repos","events_url":"https://api.github.com/users/timonvo/events{/privacy}","received_events_url":"https://api.github.com/users/timonvo/received_events","type":"User","site_admin":false},"created_at":"2015-11-10T08:26:36Z","updated_at":"2015-11-10T08:26:36Z","body":"The problem is that if you use `-N try -FP` then the logic for downgrading won't work if the server only support prefix delegations. At https://github.com/sbyx/odhcp6c/blob/master/src/dhcpv6.c#L836 `(!have_pd && pd_mode == IA_MODE_FORCE)` will evaluate to true, causing `dhcpv6_handle_advert` to return `-1`. This in turn causes `dhcpv6_promote_server_cand` to bail early, because no candidates will have been recorded at all.\r\n\r\nAdditionally, there's no logic for downgrading for pd_mode at all right now, while I think the concerns there are symmetrical to `na_mode`.\r\n\r\nI've now written up another way to do this, keeping the retry logic within `dhcpv6_promote_server_cand`. Take a look at https://github.com/sbyx/odhcp6c/compare/master...timonvo:handle-noaddrsavail-noprefixavail-2. It still fixes my issue, and stays closer to the current code structure. If you like that approach better I'll move it over to this pull request and clean it up a little more.\r\n\r\nNote, however, that at least in my case, during the initial SOLICIT/ADVERT exchange my client would go through only one round of the for-loop at https://github.com/sbyx/odhcp6c/blob/master/src/dhcpv6.c#L577 (due to round_start > round_end breaking the loop condition). Hence, it would only ever find one candidate before calling `dhcp6_promote_server_cand`, and hence, there would only ever be zero or one candidate available at that time. That's why I originally concluded that the server-ranking behavior wasn't really valuable."}}