bb-qq
The RTL8157 chipset works with 2.18-1-1.
The RTL8157 chipset works with 2.18-1-1. 2.18-1.1 package shows the RTL8157 chipset in action.
I actually confirmed that data transfer at 5GbE speed is possible. However, I can't check the link speed connected to 5000Mbps (5GbE) in Synology's ethtool or Synology network information, and I can't modify the MTU.
This problem is unlikely to be fixed right away, but I'll leave it here for reference.
The product used is WisdPi WT-UT5.
- RTL8152/RTL8153 driver [2.18-1-1]
- Synology DS920+ [DSM 7.2.2-72803]
|__2-2 0bda:8157:3000 00 3.20 5000MBit/s 544mA 1IF (WisdPi USB 5G Ethernet 000334C******10017)
eth2 Link encap:Ethernet HWaddr 34:::B1::17
inet addr:10.1.0.* Bcast:********* Mask:255.255.255.0
inet6 addr: fd3b::bee2::36c8:d6ff:feb1:17/64 Scope:Global
inet6 addr: fe80:::d6ff:*:17/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:141772521 errors:0 dropped:0 overruns:0 frame:0
TX packets:390506389 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:198520946899 (184.8 GiB) TX bytes:552978638476 (515.0 GiB)
Settings for eth2: Supported ports: [ MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full 2500baseX/Full Supported pause frame use: No Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full 2500baseX/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: Unknown! Duplex: Full Port: MII PHYAD: 32 Transceiver: internal Auto-negotiation: on Cannot get wake-on-lan settings: Operation not permitted Current message level: 0x00007fff (32767) drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol Link detected: yes
WP-UT5 is now available for purchase on : Amazon: https://www.amazon.com/dp/B0DF2TTT9H Aliexpress: https://s.click.aliexpress.com/e/_oBoAd9v WisdPi.com: https://www.wisdpi.com/sc240602
Same here, the MTU cannot be set either via Synology tool or the shell
The ifconfig returned: TNETLINK answers: Invalid argument
The ip tool returned: RTNETLINK answers: Invalid argument
This is lack of Link Speed is also an issue for Active/Standby on bonding. The below eth2 is the wisdpi r8157-based adapter, connected to 10G switch. However, it seems the bonding driver still decides not to use this adapter even though the primary slave is set to it. After digging a while it seems like the bonding driver doesn't like the Unknown speed and duplex. From dmesg, the link speed is 0 Mbps for some reason. [ 1227.088463] bond0: link status definitely up for interface eth2, 0 Mbps full duplex
user@synology:/$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: eth2 (primary_reselect always)
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 100
Down Delay (ms): 0
Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: REDACTED
Slave queue ID: 0
Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: REDACTED
Slave queue ID: 0
Slave Interface: eth2
MII Status: up
Speed: Unknown
Duplex: Unknown
Link Failure Count: 0
Permanent HW addr: REDACTED
Slave queue ID: 0
This is lack of Link Speed is also an issue for Active/Standby on bonding. The below
eth2is the wisdpi r8157-based adapter, connected to 10G switch. However, it seems the bonding driver still decides not to use this adapter even though the primary slave is set to it. After digging a while it seems like the bonding driver doesn't like the Unknown speed and duplex. From dmesg, the link speed is 0 Mbps for some reason.[ 1227.088463] bond0: link status definitely up for interface eth2, 0 Mbps full duplexuser@synology:/$ cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Bonding Mode: fault-tolerance (active-backup) Primary Slave: eth2 (primary_reselect always) Currently Active Slave: eth0 MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 100 Down Delay (ms): 0 Slave Interface: eth0 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: REDACTED Slave queue ID: 0 Slave Interface: eth1 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: REDACTED Slave queue ID: 0 Slave Interface: eth2 MII Status: up Speed: Unknown Duplex: Unknown Link Failure Count: 0 Permanent HW addr: REDACTED Slave queue ID: 0
@yunhao-jiang Many 10Gbps SFP modules do not negotiate the 5Gbps speed correctly, although they may function normally. You need to use an SFP module that supports the 5Gbps speed for testing. We will investigate this issue.
I have the same problem
=============================== The RTL8157 chipset works with 2.18-1-1. 2.18-1.1 package shows the RTL8157 chipset in action.
I actually confirmed that data transfer at 5GbE speed is possible. However, I can't check the link speed connected to 5000Mbps (5GbE) in Synology's ethtool or Synology network information, and I can't modify the MTU.
The product used is WisdPi WT-UT5.
RTL8152/RTL8153 driver [2.18-1-1] Synology DS920+ [DSM 7.2.1-69057 Update 5]
==========================================
I am also having issues with WP-UT5 RTL8157 connected to a DS1513+ running DSM 7.1.1-42962 Update 6 running driver 2.18.1-1.
My main issue is that no matter what I try on the Synology, speeds are always capped at 1Gbps max even when I force the speed to 2.5 or 5.
Test environment: WP-UT5 with USB A to USB C cable Switch: Unifi USW-Aggregation firmware 7.0.50 SFP+ RJ45 Trancievers tested: Unifi UACC-CM-RJ45-MG Supported data rates: 10 / 5 / 2.5 / 1 Gbps up to 100m Wiitek 10Gb SFP+ to RJ45 IEEE 802.3az Compliant Module that is listed to support 1.25G/2.5G/5G/10GBase-T 6COM 10GBase-T SFP+ Transceiver listed to support 1.25Gb/2.5Gb/5Gb/10Gb/s data rate new 1 meter CAT 6A cables
Client side used to test speeds: Windows 11 with Intel X540-AT2 connected at 10Gbps
Tested on both USB 3 ports on the Synology; hardware reports correct USB speed required: |__8-1 0bda:8157:3000 00 3.20 5000MBit/s 544mA 1IF (WisdPi USB 5G Ethernet 000334C8D6B10415)
4901.972688] usb 8-1: reset SuperSpeed USB device number 2 using etxhci_hcd-170202 [ 4902.685006] r8152 8-1:1.0 eth4: v2.18.1 (2024/05/20) [ 4902.690073] r8152 8-1:1.0 eth4: This product is covered by one or more of the following patents: US6,570,884, US6,115,776, and US6,327,625. [ 4902.705821] r8152 8-1:1.0 eth4: chip rev 19 [ 4902.710125] usbcore: registered new interface driver r8152
Each Tranciever was tested with the same results below. Note that on the switch, the port shown as expected on the SFP+ side ad connecting at 10Gbps and the RJ-45 side speed is not able to be forced to a specific speed.
sudo ethtool eth4 | grep Speed
Speed: Unknown!
sudo ethtool eth4
Supported ports: [ MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseX/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseX/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00007fff (32767)
drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol
Link detected: yes
- sudo ethtool -s eth4 speed 5000 duplex full
Return message is:
Cannot advertise speed 5000 duplex full
However, if you just wait 5 seconds after the error you now see this:
and you even get it to try to act like a team player and state its link speed; buts its not true. Settings for eth4: Supported ports: [ MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full 2500baseX/Full Supported pause frame use: No Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full 2500baseX/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 2500Mb/s Duplex: Full Port: MII PHYAD: 32 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: d Current message level: 0x00007fff (32767) drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol Link detected: yes
but there really is no actual change. I assume that the driver needs a bit more work to fully support this NIC.
@bb-qq and @wisdpi may have a few comments of what to try next.
Happy times on the bleeding edge train flying close to the sun.
@rsockanc The speed you are seeing does indeed seem abnormal. We have identified the reason why Synology cannot negotiate speeds exceeding 2500Mbps and are working on resolving it. However, we may release a WisdPi version of the driver, which is still under testing.
Glad to hear that @wisdpi . One possibly related issue I just tested: When the WisdPi WT-UT5 is connected to a Windows 11 PC with the USB-C to USB-C cable, link speeds negotiate and transmit/receive correctly as expected at 1, 2.5, and 5Gbps. However, when connected with the USB- A to USB- C supplied cable, the link negotiates correctly to 5, 2.5, or 1 but is only able to transmit reliably when set to 1 or 2.5 Gbps. When set to 5 Gbps with the with the USB- A to USB- C, the nic will ramp up a download up to 2.1Gbps for 3-8 seconds then will start slowing down until it fails to transmit any more packets without a reset.
Same here, seems like 5Gbps is not quite enough for this adapter? The USBC is connected through 10Gbps USBC channel while USB-A is at most 5Gbps I think. I have better experience when I use a thunderbolt cable for some reason.
I noticed a few things and will leave a comment.
- Realtek devices require a special command to fix the link speed.
- Please check the Readme: by Realtek https://github.com/bb-qq/r8152/blob/master/ReadMe.txt#L19-L32
- The Type-C to A conversion connector may have two sides. Also, poor quality ones exist.
- If it does not work properly even in Windows, reverse the orientation, or try another shielded conversion cable.
Please check the Readme: by Realtek https://github.com/bb-qq/r8152/blob/master/ReadMe.txt#L19-L32
Looks like the reason why DS920 won't show 5Gbps is the kernel version too low. On my end the most up-to-date system shows 4.4.302, which is still lower than 4.10 where 5G link negotiation is supported.
Glad to hear that @wisdpi . One possibly related issue I just tested: When the WisdPi WT-UT5 is connected to a Windows 11 PC with the USB-C to USB-C cable, link speeds negotiate and transmit/receive correctly as expected at 1, 2.5, and 5Gbps. However, when connected with the USB- A to USB- C supplied cable, the link negotiates correctly to 5, 2.5, or 1 but is only able to transmit reliably when set to 1 or 2.5 Gbps. When set to 5 Gbps with the with the USB- A to USB- C, the nic will ramp up a download up to 2.1Gbps for 3-8 seconds then will start slowing down until it fails to transmit any more packets without a reset.
@rsockanc @yunhao-jiang USB A-C can also provide a speed of 10Gbps, so it requires the USB 3.2 standard. The instability issue we suspect is due to many USB A ports not being able to provide sufficient power. All cables are tested for 10Gbps speed when they leave the factory. Both A-C and C-C cables undergo speed testing.
Please check the Readme: by Realtek https://github.com/bb-qq/r8152/blob/master/ReadMe.txt#L19-L32
Looks like the reason why DS920 won't show 5Gbps is the kernel version too low. On my end the most up-to-date system shows 4.4.302, which is still lower than 4.10 where 5G link negotiation is supported.
That's right. The Realtek driver need kernel 4.10 +. Only SA6400 is fine.
Please check the Readme: by Realtek https://github.com/bb-qq/r8152/blob/master/ReadMe.txt#L19-L32
Looks like the reason why DS920 won't show 5Gbps is the kernel version too low. On my end the most up-to-date system shows 4.4.302, which is still lower than 4.10 where 5G link negotiation is supported.
That's right. The Realtek RTL8157 driver need kernel 4.10 +. Only SA6400 is OK.
I noticed a few things and will leave a comment.
* Realtek devices require a special command to fix the link speed. * Please check the Readme: by Realtek https://github.com/bb-qq/r8152/blob/master/ReadMe.txt#L19-L32 * The Type-C to A conversion connector may have two sides. Also, poor quality ones exist. * If it does not work properly even in Windows, reverse the orientation, or try another shielded conversion cable.
The WP-UT5 uses a 10Gbps USB flipping chip, and the effect is the same whether inserted forwards or backwards. We have tested each data cable, but not for an extended period. There is indeed a quality risk with this.
Please check the Readme: by Realtek https://github.com/bb-qq/r8152/blob/master/ReadMe.txt#L19-L32
Looks like the reason why DS920 won't show 5Gbps is the kernel version too low. On my end the most up-to-date system shows 4.4.302, which is still lower than 4.10 where 5G link negotiation is supported.
That's right. The Realtek driver need kernel 4.10 +. Only SA6400 is fine.
That's a bit confusing. So you're saying right now only SA6400 has kernel >=4.10 and everyone else has to wait for a major DSM update to get a new kernel (?) But the OP states it's working on his DS920+, including speed tests. Also is it mandatory to set the "ethtool -s eth0 autoneg on advertise 0x180000000002f" setting? I didn't set anything on my 2.5G Adapter and it's definitely working...
What am I missing?
I noticed a few things and will leave a comment.我注意到了一些事情，并将发表评论。
* Realtek devices require a special command to fix the link speed. Realtek 设备需要一个特殊的命令来修复链接速度。 * Please check the Readme: by Realtek https://github.com/bb-qq/r8152/blob/master/ReadMe.txt#L19-L32请查看 Realtek 的自述文件 https://github.com/bb-qq/r8152/blob/master/ReadMe.txt#L19-L32 * The Type-C to A conversion connector may have two sides. Also, poor quality ones exist. Type-C 转 A 转换连接器可能有两侧。此外，存在质量差的。 * If it does not work properly even in Windows, reverse the orientation, or try another shielded conversion cable.如果即使在 Windows 中也无法正常工作，请反转方向，或尝试使用其他屏蔽转换电缆。
@bb-qq @RieGo I just wrote a tutorial on using the WP-UT5 on Ubuntu and tested this specific command. I believe there is an error in the readme provided by Realtek. After compiling the Linux driver, the WP-UT5 works perfectly and negotiates correctly. However, when I used the command (ethtool -s eth0 autoneg on advertise 0x180000000002f) to set the speed to 5Gbps, the network card speed changed from 5Gbps to 2.5Gbps.
Do we have a workaround on the mtu problem yet? It seems this is a bug in the Realtek driver.
Do we have a workaround on the mtu problem yet? It seems this is a bug in the Realtek driver.
@RieGo @bb-qq @i0ntempest @rsockanc @nogcha234
We have optimized the Realtek Linux driver, which now supports up to a 16K MTU. This has been synchronized with our Linux driver codebase (https://github.com/wisdpi/wp-ut5_linux), and we will soon apply to merge the code into the bb-qq code repository.
Thank you @wisdpi. I have checked the patch and it looks like this is a simple mistake by Realtek.
I have not confirmed that it works on my end, but I think the risk of a fix is low, so I have released a package with the above patch applied. https://github.com/bb-qq/r8152/releases/tag/2.18-2
Thank you @wisdpi. I have checked the patch and it looks like this is a simple mistake by Realtek.
I have not confirmed that it works on my end, but I think the risk of a fix is low, so I have released a package with the above patch applied. https://github.com/bb-qq/r8152/releases/tag/2.18-2
That's fine. I will check DSM later. I'm sure that it will be work.
I updated driver to 2.18.1-2 on my DS 718+ (newest DSM 7.2.2-72806). The DSM GUI still does not show option to select MTU higher than 1500.
UPDATE: MTU can be set to jumbo frame via command line (verify device name, and substitute as necessary):
sudo ifconfig eth2 mtu 9000
Just to confirm: The only Synology model that can use the RTL8157 at 5Gbe is the SA6400. Because all the rest have Linux Kernel below 4.10, and the max speed would be 2.5Gbe.
Is that correct?
I am seeing about 3 Gbps NAS-to-NAS (both DS718+) through 10 Gbps switch using 9K MTU running test with iperf3. I am guessing that USB 3.0 ports may be limitation.
Just to confirm: The only Synology model that can use the RTL8157 at 5Gbe is the SA6400. Because all the rest have Linux Kernel below 4.10, and the max speed would be 2.5Gbe.
Is that correct?
@joshuacant WisdPi RTL8157 WP-UT5 test result on DS1819+（Kernel 4.4） with USB 5Gbps. About 3.15Gbps MTU 1500. DS1819+ only have USB 3.0 5Gbps.
Thank you for your replies! I must be doing something wrong. I have a 920 and here's what I see after first plugging the device in.
The speeds are limited to 1Gbe and the "network status" is missing from the Synology Network GUI. If I run the command ethtool -s eth0 autoneg on advertise 0x802f the speeds increase to 2.5Gbe and the Synology Network GUI shows the appropriate network status.
I know my network cables and switch are capable of 5Gbe because I have been using the aqc111 device for many months.
Thank you for your replies! I must be doing something wrong. I have a 920 and here's what I see after first plugging the device in.
The speeds are limited to 1Gbe and the "network status" is missing from the Synology Network GUI. If I run the command
ethtool -s eth0 autoneg on advertise 0x802fthe speeds increase to 2.5Gbe and the Synology Network GUI shows the appropriate network status.
I know my network cables and switch are capable of 5Gbe because I have been using the aqc111 device for many months. @joshuacant Here, due to a restriction in the original Realtek code, when a kernel version lower than 4.10 is detected, it won't broadcast the 5GbE mode. We will submit a code request to bb-qq to see if it's possible to modify this original logic.
@wisdpi @bb-qq I received my WisdPi WT-UT5 today. Here’s what I found out:
I initially had version 2.18-1-1 of the package installed. After a reboot, I had a network connection via the front USB (back didn't seem to work). I did not have any options like Jumbo Frames enabled, and the web interface didn't properly display the negotiation speed. But I noticed that my data transfer speed was significantly faster than before (280MB/s -> 370MB/s), which is probably the maximum this USB port can achieve.
When I updated the driver to version 2.18-1-2, the speed suddenly dropped considerably (~40MB/s - USB2.0??). After downgrading, I'm back at ~370MB/s.
By the way, I also have the 920+, so I'm on an older kernel version. My findings seem to align with the experiences of @nogcha234 and @joshuacant.
Hi, I am wondering if there has been any progress toward getting the 8157 chipset working with both large MTU and broadcasting 5GbE link mode with older kernels, or is this even possible? Thank you.