Adjustment in case ethernet connection fails

[moritzj29]

Hi, I'm running two MBusino Nanos over wired ethernet connections. Recently I introduced a 4-port PoE extender into the setup. This prevented the MBusinos to establish an ethernet connection. It was quite easy to trace it back to the presence of this extender but the MBusino was the only device having issues. So I started looking into this.

Failure symptoms:

• green LED lights up, yellow LED flashes, both LEDs turn off -> repeats continously, ethernet link restarting every ~2 seconds
• no ethernet connection, no IP gets assigned

With some help of Claude and the like I finally managed to identify the root cause and also to fix the issue:

The W5500's PHY implementation does not fully comply with IEEE 802.3u auto-negotiation. Specifically it does not correctly send FLP (Fast Link Pulse) bursts during link establishment, which causes strict gigabit switch chips to time out and drop the port after ~2 seconds.

The fix is to disable auto-negotiation using ETH.setAutoNegotiation(false) and force 10M half or full duplex. With these settings the W5500 and the extender agree on link parameters without any negotiation exchange, and the connection is stable.

At 10M the incorrect FLP implementation does not matter because 10BASE-T uses simple NLP (Normal Link Pulses) that every switch handles identically regardless of PHY quality.

At 100M the extender's gigabit PHY requires proper parallel detection signaling (continuous MLT-3 idle symbols at precise timing) which the W5500 does not deliver correctly. (other PHYs like the LAN8720 on the WT32-ETH01 do apparently)

Modificiation to the code need to be made directly before each ETH.begin(...) statement:

void setup(): {
...
  delay(100);
  //ETH.setLinkSpeed(10);
  ETH.setAutoNegotiation(false); // <----- add this
  ETH.setFullDuplex(true); // <----- add this
  ETH.setLinkSpeed(10); // <----- add this
  ETH.begin(...);
  //ETH.setLinkSpeed(10);
  delay(2000);

void loop(): {
...
ETH.end();
delay(200);
//SPI.end();
ETH.setAutoNegotiation(false); // <----- add this
ETH.setFullDuplex(true); // <----- add this
ETH.setLinkSpeed(10); // <----- add this
delay(200);
ETH.begin(...);

I thought I share this here for anyone else facing similar issues.

I think it does not make sense to apply this generally, since apparently no one else is facing this issue. Apparently more sophisticated (=standard) network equipment can handle the W5500 shortcomings well enough and establishes 100M connection nevertheless.

PS: since there are ETH.setLinkSpeed(10) statements commented out in the code, did you also experimented with this? From what I found, they definitely need to be before ETH.begin(), otherwise they have no effect.

[Zeppelin500]

Thank you for investigating!
Yes, I know the problem, but it's very rare. Only one user reports this issue and I have a spare Fritzbox 7590 with this kind of connection trouble.(But other Fritzboxes, also 7590 work well)
As you seen in my code, I've tried a lot, but without effort. My solution was a 5€ unmanaged switch between the MBusino and the Fritzbox.

I will try your solution and come back. The question is, is 10Base-T fast enough for a high workload?

[moritzj29]

Ah ok, I'm not alone :) I have no long-term test yet, but in principle 10Mbit should be more than enough for a little MBus over MQTT

[Zeppelin500]

I had my bot implement and compile your suggestion. It will be tested this evening.

https://github.com/ZeppelinsBot/MBusino/tree/fix/ethernet-auto-negotiation/src/MBusinoNano5S

[Zeppelin500]

It works now with my problem Fritzbox flawless! Thank you!

Why should this solution not be the standard code if traffic is no problem? I will try to program a MQTT machine gun to test it.
Is there anything else that speaks against it?

[moritzj29]

thats great to hear! From my point of view it could also be implemented permanently, I just was not pushing for it based on my single occurrence with some chinese PoE extender. Forcing everyone from 100M to 10M did not seem justified. But if even something like a FritzBox has trouble with it, I think it is justified. Performance-wise I think it should be fine. But its a good idea to test it.

Have you tried if the FritzBox also accepts 100M with setAutoNegotiation(false)? Chances are small, I had no success with that.

[Zeppelin500]

I do a MQTT stress test. 420 records per second are possible. The limit should be the ESP, not the Ethernet.
Next release is in work.

[Zeppelin500]

New release 1.0.2, please test it.

https://github.com/Zeppelin500/MBusino/releases/tag/v1.0.2

Fix: W5500 Auto-Negotiation

The W5500 PHY does not correctly send FLP bursts during link establishment, causing strict gigabit equipment (Fritzbox 7590, PoE extenders, managed switches) to time out and drop the port every ~2 seconds.

Solution

Disable auto-negotiation and force 10BASE-T full-duplex before each ETH.begin() call:

ETH.setAutoNegotiation(false);
ETH.setFullDuplex(true);
ETH.setLinkSpeed(10);

Files changed

• src/MBusinoNano/MBusinoNano.ino — setup() + loop() reconnect
• src/MBusinoNano5S/MBusinoNano5S.ino — setup() + loop() reconnect
• README.md — version badge 1.0.2
• CHANGELOG.md — v1.0.2 entry

Tested

• Fritzbox 7590: stable connection at 10M full-duplex
• MQTT stress test: ~420 msg/s sustained throughput (no drops)
• Binary files included (bootloader, partitions, ino, merged)

Also included

• playground/mqttTest/ — standalone MQTT stress test sketch (not for production)

[Zeppelin500]

https://www.photovoltaikforum.com/thread/245741-mbusino-m-bus-mqtt-gateway/?postID=4705540#post4705540