It is a well-known issue for two devices with Gigabit Ethernet ports, when connected through a 2-pair cable (or a non-gigabit PoE injector in between) sometimes works properly (downgrades speed to 100Mbps) and sometimes not (auto-negotiates gigabit which then doesn't link because it requires 4 pairs, while auto-negotiation itself works over 2 pairs).

I'm seeing mixed results between different combinations of MT devices, for example:
- CRS328-24P-4S+ to wAP 60G AP - working (takes a few seconds longer than usual, but finally link is negotiated and up at 100Mbps-Full)
- CSS610-1Gi-7R-2S+OUT to L41G-2axD - NOT working (no link even after a long wait, link works only after setting to forced 100Mbps-Half)

Would it be possible for MT to handle this case properly in ALL devices with gigabit ethernet ports, or are some of them limited by hardware (switch chip features) that make this difficult? Basically, if there is no link for a long time, periodically retry auto-negotiation with >=1 gigabit advertised speeds disabled, so it has a chance to link at 100Mbps without manual configuration. My basic understanding is that it should be sufficient to support this on one end only, so it only doesn't work when both ends don't support it. CSS610 + L41G + 2-pair only PoE injector happens to be a common combination for us when upgrading existing radio installations (multiple separate radios like SXTsq Lite5 or LHG5, with their 2-pair PoE injectors) to a common 60GHz radio shared (out of necessity, due to the unforuntate 8-stations-per-AP limit) between a few customers with a CSS610.

Would it be possible for MT to handle this case properly in ALL devices with gigabit ethernet ports

There is no "proper" way to handle this. Real-world ideal would be to drop down to 100 mbps but that isn't a proper solution, that is a work-around.

The proper solution is to fix your local network/install.

You could perhaps script it with some sort of netwatch or similar script, that if can't connect, after a while it removes the 1G advertisements.
(Ideally on the nearest to management end, though unfortunately it looks like you would have to do it on the remote end routers)

Though if you are putting these new units in, could you not just turn off the 1G advertisement manually, if it doesn't connect?

You would need a router set up for 100M when upgrading, plug in to that, connect to remote end reconfigure remotes ethernet port...
(or add script to remote end to auto downgrade ethernet when no link would likely be better long term)

The CSS610 where it's not working is running SwOS Lite and there is no option to disable 1G advertising but keep autonegotation enabled otherwise - it's just autonegotiation or forced speed/duplex (which needs to be half-duplex if the other side has auto-negotiation and is not forced to full-duplex, otherwise we get a duplex mismatch with high packet loss). And it's on the edge between my network (I'm a small local ISP) and customer's home network which I don't have full control over. Some hardware combinations work, so there is certainly a way to do it, but I suspect it's not implemented in all devices (it may depend on a specific ethernet chip driver - Broadcom for example calls this "Ethernet@Wirespeed(TM)" and their drivers have an option to enable/disable it). It's a bit like Auto-MDIX where one could also say "fix your network and use a cross-over cable where necessary" but it's more convenient if things are just "plug and play", slower connection is better than no connection at all.

it's just autonegotiation or forced speed/duplex (which needs to be half-duplex if the other side has auto-negotiation and is not forced to full-duplex, otherwise we get a duplex mismatch with high packet loss)

Why?

I wonder if Mikrotik extender "GePR" at the remote end with small patch cord would help?
i.e. maybe it has higher sensitivity or/and it's negotiation works better than the remote devices chipset in this case.

IDK, just an idea.

it's just autonegotiation or forced speed/duplex (which needs to be half-duplex if the other side has auto-negotiation and is not forced to full-duplex, otherwise we get a duplex mismatch with high packet loss)

Why?

Because autonegotiation defaults to the lowest common denominator when the other end doesn't support it. Speed can be parallel detected, but duplex can't, so it will fall back to half duplex.

Because autonegotiation defaults to the lowest common denominator when the other end doesn't support it. Speed can be parallel detected, but duplex can't, so it will fall back to half duplex.

Full and half duplex is detected and negotiated..

Full and half duplex is detected and negotiated..

Not if forced at one end, SwOS Lite on the CSS610 lacks options to control advertised speeds, it is either auto 1G/100M/10M or forced 100M-Full/100M-Half/10M-Full/10M-Half and the forced settings disables auto-negotiation.

The situation here is that there are a few customers in one building, each one with their own separate LHG5 or SXTsq5 on the roof, powered by the supplied 100Mb PoE injector, and connected to the WAN port of the customer's home router (some of them may have gigabit ports). Now we upgrade all of them by replacing the bunch of 5GHz radios with a shared reverse-PoE switch (Netpower Lite 7R) powering a shared LHG60 or Cube60. It's a difference between visiting just one customer for access to the roof, vs visiting all of them (some may be at work with no one at home etc.) to replace their PoE injectors with gigabit ones (otherwise 100Mb injector may cause link between two gigabit ports to fail, link down when it could be 100Mb).

and the forced settings disables auto-negotiation.

But it shouldn't.. The remote end should still autodetect what the local side it forced to.

Another Mikrotik switch bug?

I thought auto-negotiation issues where left in the 90s.. It has been a very long time since I've had to force both sides of a link, literally the 90s..

Could simply be a missing feature in SwOS Lite, I wouldn't be surprised if the switch chip had support for it but it was simply not exposed in the GUI like it is in RouterOS (autonegotiation enabled - choose any set of advertised speed/duplex options; disabled - choose only one forced speed/duplex).

I wish there was a Netpower Heavy 7R with proper RouterOS, but there isn't. There is Netpower 15FR with RouterOS (good) and 16 ports (good) but 10/100Mbps only (including the PoE-out uplink, which needs ugly hacks such as using that port for PoE-out only + S-RJ01 for gigabit data).

and the forced settings disables auto-negotiation.

But it shouldn't.. The remote end should still autodetect what the local side it forced to.

But it doesn't, at least not in my experience. Forcing speed and/or duplex disables autonegotiation. At least it does on any box I have ever handled (and there have been many). Forcing half duplex at one end and leaving the other end in auto is a surefire way of getting a duplex mismatch.

But it doesn't, at least not in my experience. Forcing speed and/or duplex disables autonegotiation. At least it does on any box I have ever handled (and there have been many). Forcing half duplex at one end and leaving the other end in auto is a surefire way of getting a duplex mismatch.

Actually... Forcing half-duplex makes a fine working connection, with both end working at half-duplex (which enables CSMA/CD, google it..)
Trouble starts if you force one end to full-duplex while the other is on autonegotiation.

What some here describe as a bug is actually mandatory behaviour! forcing speed/duplex always (should) disables autonegotiation.