Jump to content

New Driver for Realtek RTL8111


Mieze
1,592 posts in this topic

Recommended Posts

I have this 2 P8H61 Asus board, both are on the same bios version. Using your driver,  one is detected as chipset 16 which i have bonjour working. But the other one is detected as chipset 17 and bonjour is not working. Is it possible that 2 identical boards could have a difference in ethernet chip? How so?

How could i be able to fix bonjour of chipset 17? I can do it manually via "Connect to Server" though.

 

Manufactures sometimes change components without notice and without changing the model name for technical reasons or just to save some cents. 

 

Frankly, I don't think that this is a driver related problem because:

  • Bonjour is based on multicast frames and chipset 17, like all members of the RTL8111F series, doesn't have a multicast filter which means that it receives any multicast packet it encounters.
  • Chipset 17 is the most frequently used Realtek NIC on socket 1155 boards from Asus and Gigabyte. In case there was a driver problem, someone would have reported it earlier.
  • Drivers handle packets, they don't care for specific protocols.

For further investigations you might want to send me your kernel logs created with the debug version of the driver.

 

Use Wireshark to capture packets. Don't forget put the interface in promiscuous mode for the capture (in Wiresharks settings). If Bonjour starts to work during the capture then there might be a chance of an hardware/driver issue. In case it doesn't a driver problem can be ruled out.

 

Mieze

Edited by Mieze
Link to comment
Share on other sites

Hello,

I want to report that the 1.2.2-dev3 works great under Mavericks 10.9.4 with Clover boot loader, but don't works correctly with Yosemite Beta (the public, not DPx).

With Yosemite, I have disconnection.

 

You see that it is unstable, and finish to be at 100Mbits...

Whereas with Mavericks, no problems, it lock at 1-Gigabit and stay at it. No connection lost.

 

I have no idea how this should be related to Yosemite in any way as the low level code is completely OS independent and you are the first user to report an issue with the 10.10 beta. It might be pure coincidence that it started to happen with the new OS because it looks more like a problem with EEE. Try to disable it in the drivers Info.plist or try to select the connection speed manually.

 

Mieze

Link to comment
Share on other sites

Manufactures sometimes change components without notice and without changing the model name for technical reasons or just to save some cents. 

 

Frankly, I don't think that this is a driver related problem because:

  • Bonjour is based on multicast frames and chipset 17, like all members of the RTL8111F series, doesn't have a multicast filter which means that it receives any multicast packet it encounters.
  • Chipset 17 is the most frequently used Realtek NIC on socket 1155 boards from Asus and Gigabyte. In case there was a driver problem, someone would have reported it earlier.
  • Drivers handle packets, they don't care for specific protocols.

For further investigations you might want to send me your kernel logs created with the debug version of the driver.

 

Use Wireshark to capture packets. Don't forget put the interface in promiscuous mode for the capture (in Wiresharks settings). If Bonjour starts to work during the capture then there might be a chance of an hardware/driver issue. In case it doesn't a driver problem can be ruled out.

 

Mieze

UPDATE : Upon opening and did some testing on wireshark, bonjour suddenly appeared 

Here is my 2 logs with & without wireshark.

Onixs.zip

Link to comment
Share on other sites

@Onixs: It looks like my assumption that it's not a driver issue is true. mDNSResponder, which implements Bonjour, isn't running because I found not a single log message of it in your file.

 

Mieze

Link to comment
Share on other sites

@Onixs: It looks like my assumption that it's not a driver issue is true. mDNSResponder, which implements Bonjour, isn't running because I found not a single log message of it in your file.

 

Mieze

Hmm, how to enable it then?

Link to comment
Share on other sites

@Onixs: Still no log messages of mDNSResponder in your updated log files. I'm sorry, but I don't have time to dig deeper into your problem. I've spent the last 10 days working full-time for my new Atheros driver and now I have to return to projects I'm getting paid for.

 

Mieze

Link to comment
Share on other sites

I have no idea how this should be related to Yosemite in any way as the low level code is completely OS independent and you are the first user to report an issue with the 10.10 beta. It might be pure coincidence that it started to happen with the new OS because it looks more like a problem with EEE. Try to disable it in the drivers Info.plist or try to select the connection speed manually.

 

Mieze

Ok, thanks.

Where can I find the info.plist of the driver ?

 

I may try again to install Yosemite.

Link to comment
Share on other sites

@Onixs: Still no log messages of mDNSResponder in your updated log files. I'm sorry, but I don't have time to dig deeper into your problem. I've spent the last 10 days working full-time for my new Atheros driver and now I have to return to projects I'm getting paid for.

 

Mieze

Got it working using ifconfig compiled with promisc flag.

ifconfig en0 promisc
Link to comment
Share on other sites

 

Got it working using ifconfig compiled with promisc flag.

 

Still doesn't explain why mDNSResponder didn't start because it even starts when the cable is disconnected.

 

Mieze

Link to comment
Share on other sites

yeah, its weird actually lol. In my 1st post about this matter, i said 2 identical boards, but the truth is i have 8 of them. 5 are chipset 16 and 3 are 17. All of the 17 are having this issue since day 1.

Link to comment
Share on other sites

yeah, its weird actually lol. In my 1st post about this matter, i said 2 identical boards, but the truth is i have 8 of them. 5 are chipset 16 and 3 are 17. All of the 17 are having this issue since day 1.

Does this mean that you have 8 hacintoshs running?

 

Mieze

Link to comment
Share on other sites

Basically the problem splits up into two parts:

  • First there is the fact that mDNSResponder doesn't start and that issue is definitely independent of the driver.
  • Second there might be eventually a problem with the multicast filter but this remains uncertain. I took the code to initialize it from Realtek's linux driver. Although it's not very probable but it can't be ruled out that it contains a bug. It is also possible that chipset 17 has a hardware bug.

In any case, the most important question is what prevents mDNSResponder from starting?

 

By the way, did you try all the boards in your office with OS X or are you trying to tell me that Bonjour doesn't work on them even under Windows?

 

Mieze

Link to comment
Share on other sites

We are on dual boot with windows. Bonjour in windows is working fine on 16 & 17

I will post a new log tomorrow with "ifconfig en0 promisc". Im sure i saw mdnsresponder started when i invoked that command.

BTW, "ifconfig en0 promisc" bad?

Link to comment
Share on other sites

We are on dual boot with windows. Bonjour in windows is working fine on 16 & 17

I will post a new log tomorrow with "ifconfig en0 promisc". Im sure i saw mdnsresponder started when i invoked that command.

BTW, "ifconfig en0 promisc" bad?

 

Well, putting the NIC into promiscuous mode will make it capture all frames on the wire which will increase CPU load because the network stack has to handle these packets only to find out that it can drop them.

 

Try to enable file sharing on the machine so that it will advertise this service via Bonjour. I hope this helps to force the start of mDNSResponder (please verify it using the log messages). Once mDNSResponder is running check if the machine can see other Bonjour servers. In case it does, the driver is alright, but in case you still can't see any Bonjour service, I will check if there is any special configuration needed for chipset 17.

 

Mieze

Link to comment
Share on other sites

Well, putting the NIC into promiscuous mode will make it capture all frames on the wire which will increase CPU load because the network stack has to handle these packets only to find out that it can drop them.

 

Try to enable file sharing on the machine so that it will advertise this service via Bonjour. I hope this helps to force the start of mDNSResponder (please verify it using the log messages). Once mDNSResponder is running check if the machine can see other Bonjour servers. In case it does, the driver is alright, but in case you still can't see any Bonjour service, I will check if there is any special configuration needed for chipset 17.

 

Mieze

I have enablle file sharing on all computers (including windows) and heres the result. (mDNSResponder still wont start)

 

Running OSX:

All 16 and windows machines can see all machine including 17, but 17 cannot see them.

 

Running Windows:

No issue. everybody can see all machine and so does 17

Link to comment
Share on other sites

I have enablle file sharing on all computers (including windows) and heres the result. (mDNSResponder still wont start)

 

Running OSX:

All 16 and windows machines can see all machine including 17, but 17 cannot see them.

 

Running Windows:

No issue. everybody can see all machine and so does 17

 

Ok, I try to find out if there is anything special for chipset 17. In case I find something, I'll let you know.

 

Mieze

Link to comment
Share on other sites

Thanks Mieze. i really appreciate it .  :)

 

Ok, I found this https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/net/ethernet/realtek/r8169.c?id=0481776b7a70f09acf7d9d97c288c3a8403fbfe4 which applies to chipset 17. I integrated the suggested patch. Please try the attached version and report back.

 

Good luck!

 

Mieze

RTL8111- V1.2.2-dev4.zip

  • Like 1
Link to comment
Share on other sites

Ok, I found this https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/net/ethernet/realtek/r8169.c?id=0481776b7a70f09acf7d9d97c288c3a8403fbfe4 which applies to chipset 17. I integrated the suggested patch. Please try the attached version and report back.

 

Good luck!

 

Mieze

 

You nailed it Mieze! Dead center :)

 

Thank You Mieze

  • Like 1
Link to comment
Share on other sites

Hello,

My problems may append because the ethernet card is breaking. On Maverick, now, I can't connect anymore...

The network card may be dead for now.

I'll try to install windows to see if it works there...

 

I'm about to order a TP-Link TG-3468. Does it function with your drivers ?

 

thanks

Miles

Link to comment
Share on other sites

MilesTEG1

check if your bios has the "test" (forgot the name) for the ethernet. Try and check again

Yes it has. I'll go take a photo of it.

 

Windows 8.1 is restored, and guess what it says for the connexion... 10 Mbits  :ninja:  :no:  :blink:  :shock:  :shock:  :wallbash: (yes ten megabits !)

 

I'm pretty sure now the card has some problems... And the motherboard is off guaranty by many years now...

 

I'll check the bios test.

Link to comment
Share on other sites

I'm about to order a TP-Link TG-3468. Does it function with your drivers ?

 

Try to get an add-in card with a RTL8111E because these chips work best and are well tested. I'm using this chip in my server with the driver since march 2013 and never lost connection. I'd recommend the Delock 89357 which I tested myself.

 

Avoid the old RTL8111B which is still found on many ultra cheap cards as these chips have more bugs and less offload functions.

 

In case the manufacturer doesn't mention the chip used, have a look at the PCIe compatibility spec of the card which is a good hint to distinguish old and new chips. In case it's PCIe 1.1 compatible, it's equipped with a RTL8111C or newer (probably RTL8111E), but in case it's only PCIe 1.0 compatible you'll get one of the outdated RTL8111B chips.

 

Mieze

Link to comment
Share on other sites

×
×
  • Create New...