I think ROS Hardware is the appropriate place for this given that it's a fairly low-level thing but happy for it to get moved if needs be.
I recently bought a second hand RB1100AH which having only 64MB of flash onboard can't upgrade between ROS7 versions directly (not enough space to download the package) so I was forced to use Netinstall to upgrade it instead.
I was having issues whereby it would netboot fine but then it would say "Waiting for installation server" and go no further.
After a great deal of back-and-forth trying various things I found the solution.
Boot the device with the netinstall machine (I've used both Windows and Linux) connected to the "Boot" port of the RB in this case Port 13.
Wait for the console to say "Waiting for installation server".
As they note in that thread MOST RB devices netboot from Port 1, whereas the CCR they are using and the RB1100 I'm using both netboot from a port OTHER than Port 1.
I'm wondering if the initial boot image which is getting transferred to the RB just uses Port 1 for communicating to the boot server regardless of what platform it's running on and this is why moving the cable to Port 1 resolved the issue in both my case and theirs?
I've also validated this behaviour on an RB1100AHx2 and an RB1100AHx4.
Since most (if not all) newer (than the RB1100) Mikrotik devices use ether1 as boot port for netinstall, I wouldn't be surprised if in a newer version of netinstall the ether1 became accidentally and somehow hardcoded and noone noticed.
It sounds a lot like a "regression bug", very likely the netinstall corresponding to the Ros V6.x versions originally installed works just fine, BUT (at least some of) the newer versions corresponding to Ros v7.x have ether1 hardcoded.
Try to Netinstall another router to confirm that Netinstall is properly configured. If the issue persists, please create a support ticket. Attach the serial console output, screenshots, a Wireshark packet capture of the process, and a step-by-step description. The more information you provide, the easier it will be to identify the issue.
Try to Netinstall another router to confirm that Netinstall is properly configured. If the issue persists, please create a support ticket. Attach the serial console output, screenshots, a Wireshark packet capture of the process, and a step-by-step description. The more information you provide, the easier it will be to identify the issue.
Hmmm.
Maybe also a video documenting the connection between the PC and the Mikrotik device, both ethernet and serial, and the exact make and model of the USB to serial converter used would be useful.
Per my post, I've done the same test on one of each of the three generations of RB1100 (AH, AHx2 and AHx4) routers and they all behave the same.
But for the sake of argument I've just Netinstalled an RB2011 (which uses Port 1 for boot) and it worked 100% without issue and no cable swapping required.
When I have time I'll do a video documenting the issue, the step by step is in my original post.
EDIT: I've also just re-done the tests using Netinstall 6.49.18 (current long-term), this does NOT exhibit the issue, so this appears to be a regression in the ROS7 Netinstall stager specifically.
The ROS6 stager appears to broadcast the discovery packets out ALL ports, if I'm sitting at "waiting for installation server" and I move the cable between ports, each individual port's MAC address appears separately in the Netinstall UI.
@arandomadmin
It seems to me like you have provided ALL the info needed to verify and reproduce the bug, thanks for that.
@STMT
As always I may well be wrong, but asking for serial console output, screenshots, Wireshark poacket capture seems to me way excessive (unless you hire arandomadmin as consultant ), the description of the behaviour, which versions are affected, how to reproduce and which hardware devices are affected are clearly stated and can be reproduced by Mikrotik just fine (if they want to).
Yeah, that was the main reason I posted about it here, to save "the next guy" the headache of trying to figure it out (and when I forget and try to do this in another 6 months and have to search for the solution it'll be here)
), the description of the behaviour, which versions are affected, how to reproduce and which hardware devices are affected are clearly stated and can be reproduced by Mikrotik just fine (if they want to).