This seems to be fixed in master, but I'm not sure by which commit (or I'd pull it out).
This is specifically effecting my dual stack setup, both v4 and v6 advertise a 1450 MTU but it gets reset to 1500.
Jul 26 20:10:32 test-hostname2 dhcpcd-run-hooks: eth0: MTU set to 1450
Jul 26 20:10:32 test-hostname2 dhcpcd-run-hooks: eth0: MTU restored to 1500
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
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
# dhcpcd debug log upon radvd restart
Jul 26 22:51:27 test-hostname2 dhcpcd: eth0: Router Advertisement from fe80::26a4:3cff:fe06:d8fe
Jul 26 22:51:27 test-hostname2 dhcpcd: eth0: adding address 2001:470:e1cc:1:f816:3eff:fed6:21ea/64
Jul 26 22:51:27 test-hostname2 dhcpcd: eth0: pltime 604800 seconds, vltime 2592000 seconds
Jul 26 22:51:27 test-hostname2 dhcpcd: eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT
Jul 26 22:51:27 test-hostname2 dhcpcd-run-hooks: 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...
Hopefully fixed here:
Can you test master again please and let me know if the issue is
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
dhcpcd-6.9.2 has been released which fixes this issue
dhcpcd-6.9.2 is now in the tree.