Jump to content

jrgieojvnviiwwi

Members
  • Content Count

    5
  • Joined

  • Last visited

About jrgieojvnviiwwi

  • Rank
    InsanelyMac Protégé
  1. jrgieojvnviiwwi

    IntelMausiEthernet.kext for Intel onboard LAN

    Oh. God. I just resolved it. You were right all along, it was my networking equipment. Reason was: I installed this new hardware, needed a longer ethernet cable and thus used a different switch port to plug it in, that switch port had the VLAN set to tagged instead of untagged. While Windows was able to handle this - or rather, Windows ignored it - macOS was obviously not happy. ...immediately after I set that switch port from tagged to untagged, DHCP received the address and it's resolved. So now I am one of those people "my stuff is fine, i know my stuff, it can't be my stuff... oh it was my stuff..." Thanks for making the time. I might not have found the issue without your hint.
  2. jrgieojvnviiwwi

    IntelMausiEthernet.kext for Intel onboard LAN

    That crossover cable hasn't been required anymore for years, NICs automatically switch it over nowadays. In any case, you are correct, Mieze, there are actually dhcp discover packets reaching the pfsense firewall/router, and it responds with a dhcp offer packet in return. Then this starts over, DHCP never completes. I was checking the wrong log before, sorry about that. I see a curious behaviour with a static configuration: When I ping the static IP address, the received packets count in the statistics counts up for each ping that I send. So apparently the NIC receives packets. But on the host I send the pings from, I get a timeout, so the reply packet for my ping is not being sent out. To sum this up: The NIC seems to be receiving packets but not sending out packets, other than that initial request for DHCP when it's enabled. At least that describes the problem enough for searching for it on google...
  3. jrgieojvnviiwwi

    IntelMausiEthernet.kext for Intel onboard LAN

    Thank you - I will check on the ACPI errors, I saw those too. It might be due to me simply installing a fresh system with Clover and not installing any DSDT patches or what is sometimes done afterwards since the system works just fine as it is (except for the NIC). I just intalled vanilla High Sierra with nvidia web drivers and then made it bootable with Clover, that worked on my other (older) hackintosh just fine. Unfortunately there isn't anything with the network config that I can check, I use good quality managed switches and have dozens of computers in the network including the other hackintosh and several real Macs, and all work well. I just tried attaching another computer NIC <-> NIC with a static IPv4 address config and tried pings, but unsuccessfully. I can try to further check with Wireshark to see what happens, but I see no DHCP discovery packet received on my pfsense firewall/router, so not even the initial DHCP packet makes it out of the NIC. I agree that there are no errors related to your driver visible in the log, so it should be working just fine. But since 0 packets make it across the wire, the NIC obviously isn't working properly, for whatever reason...
  4. jrgieojvnviiwwi

    IntelMausiEthernet.kext for Intel onboard LAN

    Thank you for the quick reply. Here is the log for "log show --predicate "processID == 0" --debug" The ethernet cable was plugged in from the beginning, at around time 23:24:49 I unplugged it and at around 23:25:10 I plugged it in again. I will look through the log now myself, but unless it's something trivial and especially if the driver itself needs a change, I'll surely need help. Thanks for your time! logoneboot.txt
  5. jrgieojvnviiwwi

    IntelMausiEthernet.kext for Intel onboard LAN

    Hello Mieze and greetings from Austria :-) Thank you for developing your driver, I appreciate that I can just download drivers such as your kexts for free when you surely put quite some time into it. Now I have a new mainboard with the new 300 coffee lake series, the Supero C7Z370-CG-L. It uses the i219 (v2) with device ID 0x15b8. Neither your 2.3.0 version nor your newest 2.4.0d0 works, unfortunately. With both versions, the kext enables the NIC and recognizes when I plug in the network cable. But there is no actual connection, it does not receive an IP address via DHCP and when I configure the IP address settings manually, no connection can be established. With Windows 10 on a second drive, the NIC works just fine. I tried unplugging and plugging in the cable several times. Furthermore I also tried the E1000 driver and the exact same behaviour occurs. Cable is recognized when connected, but no actual connection is established. macOS autoconfigures to: 1000baseT, full-duplex, energy-efficient-ethernet, MTU Standard 1500. Playing around with those settings and reverting to 100Mbit/s does not change the behaviour. Now I will try to figure out how to get the log files you asked for in your previous post about the 2.4.0d0 version and I'll write another post with the logs attached. I haven't checked them yet and I am not sure how to get them, yet. Since the kext seems to respond to the device ID and macOS tries to use your kext for the NIC, I am afraid that maybe your driver just does not contain the code to run this NIC properly It's a very new mainboard and even though the i219v2 isn't such a new NIC, perhaps my mainboard has a new version of this NIC that isn't known yet? I disabled the NIC in the UEFI, but the UEFI is a mess compared to Asus and Gigabyte, settings aren't explained at all (the user guide that comes with it does not contain them either, and that's supposed to be a professional supermicro product...) and so I am not sure if that is all done correctly. Perhaps I am missing a UEFI setting? Thanks!
×