| Summary: | <=net-misc/dhcpcd-6.9.1 resets mtu erroneously | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Matthew Thode ( prometheanfire ) <prometheanfire> |
| Component: | Current packages | Assignee: | William Hubbs <williamh> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | base-system, roy |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://github.com/prometheanfire/gentoo-cloud-prep/issues/15 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Matthew Thode ( prometheanfire )
2015-07-26 20:21:13 UTC
I think this is the same as bug #554422. I'll test that patch then at first glance this seems to work, I'm gonna keep the machine up til the VM asks for a renewed lease to be sure. it was just reset again, ran 6.9.1 with this patch http://roy.marples.name/projects/dhcpcd/vpatch?from=bba0ca7ae99aeae9&to=2a1546e5869468f1 9999 resets itself as well, so this effects master :( Here's some more debug info # command to generate debug info (interface is the VMs interface): tshark -i tapcd6b2718-7f -Y "icmpv6.type == 133 or icmpv6.type == 134 or icmpv6.type == 135" -T fields -e frame.number -e icmpv6.type -e ipv6.src -e ipv6.dst -e icmpv6.mtu -e icmpv6.opt.mtu -E header=y -E separator=\; # command output upon radvd restart 1;134;fe80::26a4:3cff:fe06:d8fe;ff02::1;;1450 4;134;fe80::26a4:3cff:fe06:d8fe;ff02::1;;1450 # dhcpcd debug log upon radvd restart Jul 26 22:51:27 test-hostname2 dhcpcd[3300]: eth0: Router Advertisement from fe80::26a4:3cff:fe06:d8fe Jul 26 22:51:27 test-hostname2 dhcpcd[3300]: eth0: adding address 2001:470:e1cc:1:f816:3eff:fed6:21ea/64 Jul 26 22:51:27 test-hostname2 dhcpcd[3300]: eth0: pltime 604800 seconds, vltime 2592000 seconds Jul 26 22:51:27 test-hostname2 dhcpcd[3300]: eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT Jul 26 22:51:27 test-hostname2 dhcpcd-run-hooks[3771]: eth0: MTU restored to 1500 To me it seems like dhcpcd is simply ignoring the ipv6 MTU (specifically the 'icmpv6.opt.mtu' option), so it's being reset. The only reason it's set correctly at all is because MTU is also advertised via ipv4. Perhaps dhcpcd only sets the MTU based on the 'icmpv6.mtu' option and not the 'icmpv6.opt.mtu' option (they could be different ways of saying the same thing for all I know)? just for more docs... https://gist.github.com/prometheanfire/22bb0b6f77c904ca8c1d Hopefully fixed here: http://roy.marples.name/projects/dhcpcd/ci/5e375e2d3180d184?sbs=0 @prometheanfire: Can you test master again please and let me know if the issue is resolved? It's tested good for me. Could you test again using a new 9999 ebuild please? I have taken a different tack by removing the 10-mtu hook script and directly applying the MTU to each route generated by the DHCP message, which is similar to IPv6. This is probably a more robust method of doing this as it has the side effect of avoiding a PHY reset on some hardware/drivers when changing the MTU which can cause an infinite loop. seems to work just fine. I assume that if the interface mtu is lower then the route MTU that'll be obeyed, thanks for the quick work (In reply to Matthew Thode ( prometheanfire ) from comment #12) > seems to work just fine. I assume that if the interface mtu is lower then > the route MTU that'll be obeyed, thanks for the quick work The lowest MTU of the two will be used. right, and that's an in kernel thing, :D Exactly dhcpcd-6.9.2 has been released which fixes this issue dhcpcd-6.9.2 is now in the tree. |