Jump to content
About Just Joined group Read more... ×
Mieze

New Driver for Realtek RTL8111

1,517 posts in this topic

Recommended Posts

On 10/10/2020 at 2:09 PM, Mieze said:

I discovered a small bug in 2.3.0d3 and will publish version 2.4.0d4 in a few moments. In case I'll get a few more positive results, I'll also post a release version here in this thread during the weekend.

 

Mieze :cat:

Good morning @Mieze thanks for your upcoming updated version, should we expect a release on your Git repository a package of Debug/Release kexts? Am I correct to assume that 2.4.0 will work with Mojave 10.14 as minimum? Thank you.

Share this post


Link to post
Share on other sites
Advertisement

Here is version 2.4.0d5 in which I fixed an issue with EEE support. The archive contains a debug and a release build and was built for Mojave and above. Provided nothing unexpected happens, I think we are pretty close to an official release 2.4.0. I'll continue to support Mojave and, in case there is a demand, High Sierra too. Let's see what users have to say about High Sierra?

 

Mieze :cat:

RealtekRTL8111-V2.4.0d5.zip

Edited by Mieze

Share this post


Link to post
Share on other sites

2.4.0d5 works fine here on 10.15.7 with FD+FC+EEE.

 

I think maybe another year for 10.13? Because a lot of people still stay with it.

Or some of them would upgrade to Mojave next year once Apple releases the last security update for it.

Edited by Henry2010

Share this post


Link to post
Share on other sites

Version 2.4.0d5 no issues on 10.14.6, 10.15.7, also shortly tested on my “emergency” High Sierra no problems either(all OSes need manual set medium). I also think it’s a good idea to continue to support High Sierra too.

Edited by hardcorehenry

Share this post


Link to post
Share on other sites

A possible bug:

with 2.4.0d5 installed, all of Firefox, Safari, MS Edge cannot open OpenWrt's http://192.168.1.1/cgi-bin/luci/ :surprised:

but it works with 2.3.0.

 

Edited by Henry2010

Share this post


Link to post
Share on other sites

I'm using OpenWRT on my Netgear R7800 router too but I can't confirm the issue. See screenshot below. Keep in mind that in case you are using jumbo frames, all devices involved with communication must support them. It might also be a problem with your router?

 

Does it work when you disable jumbo frames?

 2097141870_Bildschirmfoto2020-10-17um16_58_30.thumb.png.48b3cf4a945124d7aa4c6b0e8ac68ef2.png

Edited by Mieze

Share this post


Link to post
Share on other sites

/targets/ramips/mt7620/ here.

 

Do you mean trying FD+EEE only? BRB.

 

No, that doesn't work either. Maybe related to the 100baseTX mode. The router only offers that speed.

 

Plus, SSH-ing into the router always gets "client_loop: send disconnect: Broken pipe" and breaks up the connection.

Edited by Henry2010

Share this post


Link to post
Share on other sites

Duplex and EEE shouldn't have any effect. Try disabling jumbo frames (MTU 1500) first and see if it works. I case of yes, increase MTU step by step, e.g. 2000, 4500, 9000, and check the result. By the way, which Realtek chipset do you use?

 

Mieze 

Share this post


Link to post
Share on other sites
1 hour ago, Mieze said:

Duplex and EEE shouldn't have any effect. Try disabling jumbo frames (MTU 1500) first and see if it works. I case of yes, increase MTU step by step, e.g. 2000, 4500, 9000, and check the result. By the way, which Realtek chipset do you use?

 

Mieze 

 

Thanks.

Gigabyte's website says 8111F.

And here only 1280 to 1500 is allowed...

The router only offers 100Mbps.

If possible, you probably need to limit jumbo frames for 1000Mbps only.

Edited by Henry2010

Share this post


Link to post
Share on other sites

@Henry2010 Please send me you kernel logs, or take a look at the driver's entry in IORegistry in order to identify the exact chipset. Unfortunately it's not possible to limit jumbo frames to gigabit connections because of the way the configuration interface works.

 

Am I right to assume that everything is working fine with MTU 1500 in your network? Have you tried jumbo frames with a gigabit connection to another device in your network which is known to support jumbo frames?

 

Mieze

Share this post


Link to post
Share on other sites

Yes 2.4.0d5 works fine with MTU=1500 and all speed modes (except this thing with OpenWrt).

And unfortunately I don't have 1000Mbps here. :(

RTL8111.jpg

 

MTU's max value is still 1500 when I force it to 1000Mbps

 

Screenshot.jpg

Edited by Henry2010

Share this post


Link to post
Share on other sites

@Henry2010 Thanks for the test. Looks like the router is causing the problem because many Fast Ethernet devices don't support jumbo frames at all and simply treat them as bad packets.

 

As I also have an RTL8111E-VL, I will run some additional tests with this chip accessing my OpenWRT router just to be sure.

 

EDIT: Accessing my OpenWRT router with the RTL8111E-VL and Jumbo frames (MTU 9000) enabled works fine for me.

 

Mieze :cat: 

Edited by Mieze
Added test result

Share this post


Link to post
Share on other sites
12 hours ago, Mieze said:

@Henry2010 According to your IOReg screenshot you are running version 2.3.0 which doesn't support jumbo frames.

 

Mieze :cat:

 

Before I took the pic, I changed it from 2.4.0.d5 back to 2.3.0 in order to fix my router, because when it was 2.4.0.d5, I thought it was broken and flashed 19.07.4 and several snapshots. And as I said, even SSH-ing did not work.

 

Also, 1000Mbps does NOT work. I set it to show you MTU cannot be more than 1500 here. The router only offers 100Mbps.

Edited by Henry2010

Share this post


Link to post
Share on other sites

Hello, Laura. I'd like to report a bug with the latest version of your kext (maybe other versions are affected as well). I've been sharing wifi connection through ethernet that's powered by your kext and the problem is that it shares only if the cable is connected prior to ticking the checkbox of "internet sharing". If the receiving computer restarts or powers off, it then obtains ipv4 and v6 from from the sharing hack, but nothing pings even locally. I've had a usb Gbe AX88179 lying around and decided to give that a try - and it does not produce that behaviour, the other side connects normally to the internet after restar or cable disconnection. I'd be happy to provide the details if you cannot reproduce the bug such as the exact controller name and whatsoever. Currently writing from another machine.

 

P.S.

the problem is definetly on Realtek side, as I've tried connecting and keeping that connection alive from different controllers. 

Share this post


Link to post
Share on other sites
3 hours ago, rotoyouoio said:

the problem is definetly on Realtek side, as I've tried connecting and keeping that connection alive from different controllers. 

 

No way because a driver handles packets, nothing more and nothing less. What your are describing falls into the realm of the network stack and is far beyond the scope of the driver. Therefore I can rule out a driver issue.

 

Mieze :cat:

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

Announcements

  • Similar Content

    • By Mieze
      This project is dedicated to Lucy, my lovely little Tyrannofelis Rex. 
       

       
      LucyRTL8125Ethernet is an open source driver for the Realtek RTL8125 family of 2.5GBit Ethernet controllers.
       
      Key Features of the Driver
      Supports all versions of Realtek's RTL8125 2.5GBit Ethernet Controllers found on recent boards. Support for multisegment packets relieving the network stack of unnecessary copy operations when assembling packets for transmission. No-copy receive and transmit. Only small packets are copied on reception because creating a copy is more efficient than allocating a new buffer. TCP, UDP and IPv4 checksum offload (receive and transmit). TCP segmentation offload over IPv4 and IPv6. Support for TCP/IPv4, UDP/IPv4, TCP/IPv6 and UDP/IPv6 checksum offload. Supports jumbo frames up to 9000 bytes (strongly recommended for 2.5GBit operation). Fully optimized for Mojave and above. Note that older versions of macOS might not support 2.5GB Ethernet. Supports Wake on LAN (untested). Supports VLAN (untested). Support for Energy Efficient Ethernet (EEE) which can be disabled by setting enableEEE to NO in the drivers Info.plist without rebuild. The default is YES. The driver is published under GPLv2.  
      Current Status
      The driver has been tested successfully under Catalina (10.15.4 and above) and, according to first tests, is working stable. I haven't experienced any Kernel Panics during my tests and is working stable on my primary work machine. The driver has been designed to work with Catalina but might also work with Mojave, provided you build from source with Xcode 10.. Please keep in mind that support for 2.5GBit Ethernet was introduced in Mojave (or maybe High Sierra?) so that there is no way to make it work with Sierra or below.  
      Known Issues
      Using autoselect medium it seems to prefer negotiating a connection speed of 1Gbit with my switch so that I had to select 2.5GBit/s manually in order to achieve this speed but it might be different with other switches.   Installation
      You might want to install the driver to /L/E as usual but it's also ok to use Clover's injection function (installation in the EFI folder). Use your favorite kext installation tool for installation or perform the installation manually (for Clover injection). It's your call!  
      Help - I'm getting kernel panics!
      Well, before you start complaining about bugs after you upgraded macOS and ask me to publish a driver update, you should first try to resolve the issue on your own by cleaning the system caches.
      As the driver uses macOS's private network driver interface, which is supposed to be used by Apple provided drivers only, you might run into problems after an OS update because the linker may fail to recognize that IONetworking.kext has been updated and that the driver needs to be linked against the new version (Apple provided drivers avoid this problem because they are always updated together with IONetworking.kext). As a result, the linking process produces garbage and the driver may call arbitrary code when trying to call functions from IONetworking.kext. This usually results in unpredicted behavior or a kernel panic. In order to recover from such a situation, you should clean the System Caches forcing the linker to recreate it's caches:
      Delete all the files in /System/Library/Caches and it's subdirectories but leave the directories and the symbolic links intact. This is very important! Reboot. Recreate the kernel cache. Reboot again.  
      Troubleshooting
      Make sure you have followed the installation instructions especially when you have issues with certain domains while the others are working fine. Use the debug version to collect log data when trying to track down problems. The kernel log messages can be retrieved with "log show --predicate "processID == 0" --debug" in order to retrieve kernel logs. Include the log data when asking for support or giving feedback. I'm an engineer, not a clairvoyant. Don't copy and paste large amounts of log data to your post. Create an archive with the log data and attach it to your post. In case you don't want to make your log data publicly accessible, contact me via PM and I will provide you a mail address to send it directly to me.  Delete the following files: /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist /Library/Preferences/SystemConfiguration/preferences.plist In Terminal run netstat -s in order to display network statistics. Carefully examine the data for any unusual activity like a high number of packets with bad IP header checksums, etc. In case auto-configuration of the link layer connection doesn't work it might be necessary to select the medium manually in System Preferences under Network for the interface. Use Wireshark to create a packet dump in order to collect diagnostic information. Keep in mind that there are many manufacturers of network equipment. Although Ethernet is an IEEE standard, different implementations may show different behavior causing incompatibilities. In case you are having trouble try a different switch or a different cable.  
      Changelog
      Version 1.0.0 (2020-08-14) Changed version number to make this the first official release. Version 1.0.0d6 (2020-06-14) Fixed chip recognition. Version 1.0.0d3 (2020-04-20) First working development release.  
      Getting the driver
      Source code can be found on GitHub: https://github.com/Mieze/LucyRTL8125Ethernet You'll find the lastest prebuilt binary in the download section: https://www.insanelymac.com/forum/files/file/1004-lucyrtl8125ethernet/  
       
    • By Mieze
      Key Features of the Driver
      Supports all versions of Realtek's RTL8125 2.5GBit Ethernet Controllers found on recent boards. Support for multisegment packets relieving the network stack of unnecessary copy operations when assembling packets for transmission. No-copy receive and transmit. Only small packets are copied on reception because creating a copy is more efficient than allocating a new buffer. TCP, UDP and IPv4 checksum offload (receive and transmit). TCP segmentation offload over IPv4 and IPv6. Support for TCP/IPv4, UDP/IPv4, TCP/IPv6 and UDP/IPv6 checksum offload. Supports jumbo frames up to 9000 bytes (strongly recommended for 2.5GBit operation). Fully optimized for Mojave and above. Note that older versions of macOS might not support 2.5GB Ethernet. Supports Wake on LAN (untested). Supports VLAN (untested). Support for Energy Efficient Ethernet (EEE) which can be disabled by setting enableEEE to NO in the drivers Info.plist without rebuild. The default is YES. The driver is published under GPLv2.
    • By Yosa Tristian
      Can someone help me?
      When I turn on the USB Wireless Adapter (Wifi Dongle), my mouse is lagging (like quick ejecting & rejecting).
      When I turn off the Wifi Dongle, my mouse runs smooth again.
       
      Mouse: Fantech G13 Rhasta II
      Wifi Dongle: TPLink TL-WN725N
      Wifi Dongle Driver : https://github.com/chris1111/Wireless-USB-Adapter
       
      And if you don't mind, can you check my hackintosh configuration? maybe something isn't right yet
      Send me Yosas-MacBook-Pro.zip
    • By Mieze
      Key Features of the Driver
      Supports Qualcomm Atheros AR816x, AR817x, Killer E220x, Killer E2400 and Killer E2500. Support for multisegment packets relieving the network stack of unnecessary copy operations when assembling packets for transmission. No-copy receive and transmit. Only small packets are copied on reception because creating a copy is more efficient than allocating a new buffer. TCP, UDP and IPv4 checksum offload (receive and transmit). Support for TCP/IPv6 and UDP/IPv6 checksum offload. Makes use of the chip's TCP Segmentation Offload (TSO) feature with IPv4 and IPv6 in order to reduce CPU load while sending large amounts of data. Fully optimized for Mountain Lion, Mavericks and Yosemite (64bit architecture) but should work with Lion (only 64bit) too, provided you build from source with the 10.7 SDK. Wake on LAN support. VLAN support used to be broken in older versions but is working since version 2.3.2. The driver is published under GPLv2.
×