You could actually post where the screenshots differed (CFGR register), it took me way to much time to spot it...
You know, you spend days on writing over forums about seemingly random, "suspect" issues around clocking and didn't even bother to read RM section about rcc?
IIRC on F4 the clock sources, PLL, routing and divs options should be in CR, CFGR, PLLCFGR registers (didn't check it now); have their values compared with the numbers you should calculate from RM and see if they meet your desires. The xxxENR registers are for "enabling"/"connecting" the clock to the cores hooked to given bus.
Then read some of the eth core, or search over RM/DS, find if the ETH requires some specific clocking scheme, dont rely on cube here.
Then if your schematic is ok, you measure good clock, the potential clock issues should be excluded by now. I personally had module with phy/crystal/magnetics dangling on random 15 cm wires with RMII from F4 discovery board. Shameful as it was, yet it surprisingly worked ok.
Another thing, that ST eth code afaik is still littered with bugs, I still remember how i stumbled upon plain mistake in the their init code long time before HAL came.
Another thing, that STM eth cores use to have some hardware bugs here and there too, which interfere with the cube code. Have you checked errata?
On "ST community" site there is/was a guy, iirc named "Piranha" who has made eth module work perfectly, with all the bugs handled, though afaik he didn't share the code. Yet he was helpul with insights.
One can make it work, or not, by commenting out some RTOS tasks, although currently I have it running DHCP fine on one system, with all tasks enabled, by having made them better behaved (putting osDelay(1) in various places where it doesn't matter, to yield to the RTOS).
This code will fail you in the moment of truth...
Anwway, looks like you have piled non-trivial ST driver over non-trivial eth core over non-trivial 3rd party stack over non-trivial (preempting?
) rtos and it doesn't "just work"... I would drop the rtos, maybe even the stack (though I think the stack in the most trusty piece of code here) and check if driver alone misbehave, what it outputs, or are there any error flags in eth registers.
And clock the bus for max f, for now at least, to achieve eth flawless operation. Eg. iirc the USB cores on STM have the ahb/core interface actually exposed in papers and registers, and you can see it already requires special handling with lowered bus speed. Wouldn't be surprised if eth core also was vulnerable to low f.