dhcpcd-discuss

On Sat, 18 Jan 2014 15:20:56 +0000
Roy Marples <roy@xxxxxxxxxxxx> wrote:

> > 
> > Again, thanks for helping me figure it out, and sorry for lack of basic
> > knowledge in the area, leading to all that confusion.
> 
> Great! So you're all up and running fine now?
> 
> Also, can you think of any extra improvements that could be made on top 
> of the fixes I've just made?
> 

Yeah, it kinda works...

Resulting configuration (/etc/dhcpcd.myisp.conf) I have is:

  duid
  persistent
  option rapid_commit, classless_static_routes
  require dhcp_server_identifier
  nohook resolv.conf, lookup-hostname, hostname, ntp.conf, yp.conf
  noipv4ll
  
  vendorclassid dhcpcd:Linux-3.X.X:x86_64
  vendclass 40712 dhcpcd:Linux-3.X.X:x86_64
  
  noipv6rs

  waitip 46
  timeout 10
  
  #debug
  
  interface ext1
   iaid b9:86:f4:39
   ia_pd b9:86:f4:39 enp1s0/0/56
  
  interface enp1s0
   noipv4
   noipv6

And running dhcpcd as:

  dhcpcd -f /etc/dhcpcd.myisp.conf --nogateway ext1 enp1s0

Works nicely with two existing IPv6 and IPv4 on enp1s0 - didn't think
about these "noipv4" options in that context before seeing you add these
to docs for similar example case.


dhcpcd waits for both IPv4 and IPv6, assigning delegated range to
enp1s0, but with some extra interesting output:

  dhcpcd[3394]: DUID 00:01:00:01:1a:17:60:58:1c:bd:b9:86:f4:39
  dhcpcd[3394]: enp1s0: IAID bc:dc:af:42
  dhcpcd[3394]: ext1: IAID b9:86:f4:39
  dhcpcd[3394]: ext1: soliciting an IPv6 router
  dhcpcd[3394]: ext1: ipv6nd_sendrsprobe: sendmsg: Cannot assign requested address
  dhcpcd[3394]: ext1: confirming Prefix Delegation
  ...

I thought "noipv6rs" (which I have in the config globally) was supposed
to disable whole router solicitation mechanism?

It is explicitly mentioned as "to disable" thing for ia_pd (and I guess
it's also an obvious thing related to RFCs which I just don't know), so
assume that hint is there so that RS requests won't get sent anywhere
but on ia_pd-context interface, where they get implicitly (and
forcefully) enabled.

If so, maybe that's the thing worth mentioning that reasoning and
implicit RS being always enabled where IA_PD is?


And the "ipv6nd_sendrsprobe: sendmsg: Cannot assign requested address"
seem to be common to everywhere I use dhcpcd (e.g. also in wicd logs,
which runs dhcpcd on wifi links) and easily googleable elsewhere.

Not sure why it happens, but adding a long-enough delay between "ip link
set ext1 up" (from "down" state) and running dhcpcd by "sleep 3" (1
second doesn't do it) seem to fix the issue:

  dhcpcd[5787]: DUID 00:01:00:01:1a:17:60:58:1c:bd:b9:86:f4:39
  dhcpcd[5787]: enp1s0: IAID bc:dc:af:42
  dhcpcd[5787]: ext1: IAID b9:86:f4:39
  dhcpcd[5787]: ext1: soliciting an IPv6 router
  dhcpcd[5787]: ext1: rebinding lease of 188.226.62.174
  dhcpcd[5787]: ext1: Router Advertisement from fe80::201:c9ff:fee5:6000
  dhcpcd[5787]: ext1: confirming Prefix Delegation

(and I see RS/RA exchange in tcpdump here)

So I wonder if there should be some link-status hook in dhcpcd not
trying to send RS before interface is (somehow) ready for them, or
maybe try a few times with intervals and either suppress this error
until giving up on trying or document and phrase it better (i.e.
"waiting for RS mechanism to work (attempt 1)").

ipv6ra_own parameter doesn't seem to have effect on the thing, except
added "dhcpcd[6102]:  <ifname>: disabling Kernel IPv6 RA support"
messages.

Furthermore, removing delay between "ip link set ext1 up" and running
dhcpcd completely sometimes causes this:

  dhcpcd[6034]: version 6.2.0 starting
  dhcpcd[6034]: dev: loaded udev
  dhcpcd[6034]: DUID 00:01:00:01:1a:17:60:58:1c:bd:b9:86:f4:39
  dhcpcd[6034]: enp1s0: IAID bc:dc:af:42
  dhcpcd[6034]: ext1: IAID b9:86:f4:39
  dhcpcd[6034]: ext1: soliciting an IPv6 router
  dhcpcd[6034]: ext1: ipv6nd_sendrsprobe: sendmsg: Cannot assign requested address
  dhcpcd[6034]: ext1: confirming Prefix Delegation
  dhcpcd[6034]: ext1: rebinding lease of 188.226.62.174
  dhcpcd[6034]: ext1: dhcp6_sendmessage: sendmsg: Cannot assign requested address
  dhcpcd[6034]: ext1: leased 188.226.62.174 for 3600 seconds
  dhcpcd[6034]: ext1: adding route to 188.226.62.0/24
  dhcpcd[6034]: timed out
  dhcpcd[6034]: forked to background, child pid 6049

Looks like same issue of "interface not ready for IPv6 just yet" -
guess checking for duplicate link-locals or something.

Letting dhcpcd change link state from "down" to "up" by itself seem to
resolve the issue, but seem to preclude some manual configuration (or
whatever tinkering with) of interfaces before dhcpcd startup.

I imagine it might be extra-surprising when i.e. you do set ipv4, do
"link up" and have dhcpcd with "noipv4" start afterwards for just ipv6,
which doesn't work due to these "Cannot assign requested address".

"--nolink" option doesn't seem to resolve the problem, and sounds very
counter-intuitive anyway - I'd think solution should be dhcpcd expecting
and processing some "link ready" message, not disabling that.

So I wonder, maybe it should be documented that dhcpcd expects link to
be down - i.e.:

  If you use IPv6, you really should run it on links in DOWN state,
  otherwise delay running for whatever number of seconds or expect
  'Cannot assign requested address' messages otherwise.

Would also be helpful if error messages would say something like:

  dhcp6_sendmessage: sendmsg: Cannot assign requested address
  (link is not ready yet?)

Though I assume such random "hopefully it will work then" delays are
bad anyway, so maybe something can be done about these?


Also, looking at tcpdump, I see that when such "sendmsg" error happens
and dhcpcd doesn't send RS packet, ISP sends RA packets occasionally
anyway (which I believe it should, according to standards) on ext1
interface, but dhcpcd doesn't seem to acknowledge or process these in
any way.

Which is surprising, given that it wanted to do RS when it started.
It's not obvious what happens as a result of that error, and given its
ubiquity, I always treated it as a harmless warning.

Maybe when that mechanism gets disabled due to error, add a helpful log
error-level message like "Disabling Route Solicitation mechanism due to
errors"?


And then also the whole thing with IA_PD doesn't actually work -
assigned IPv6 on enp1s0 is "2a02:17d0:3b0:a500:7271:bcff:fedc:af42/56"
and doing "ping6 google.com", tcpdump sees icmp6 packets going towards
google from ext1 (so forwarding works, egress not blocked here), but no
replies seen on ext1.

IA_NA used to give me 2a02:17d0:200:d518::1/128, and assigning that to
ext1 manually gets linux using it to send pings from instead (by
default), and ISP replies to that just fine.

ISP also actually routes packets from Hurricane Electric (6to4 broker)
IPv6, when they exit from ext1, and I see replies to these on SIT
tunnel... looks like the only thing they don't route is IA_PD they hand
out here ;)

Fairly sure it has nothing to do with dhcpcd and either my fault or ISP
issue, which I'll probably figure out with them.

Just wanted to mention to be completely honest wrt that "So you're all
up and running fine now?" question ;)


Apologies for such ultra-long message - got carried away a bit, can
probably do tl;dr, if necessary/incomprehensive/too-much-rambling.


-- 
Mike Kazantsev // fraggod.net

Attachment: signature.asc
Description: PGP signature