missed or didn't notice the notification when this came in...
I had a similar problem in the Mountain Lion days. My board has an Intel ethernet controller and I was using whatever version of hnak's driver was current at the time. In my quest to eliminate possible causes I went back from a slightly overclocked BCLK and I added an SSDT to describe my CPU overclock correctly. That stoped the crashes for me. Any chance you have overclocked your system?
Another idea: if your board has Thunderbolt, you could buy a Thunderbolt-Ethernet dongle from Apple to try to figure out whether the problem is with the OS or the driver. Then again, for the price you can probably buy a supported ethernet PCI card...
Definitely not overlocking my system. Also no thunderbolt. I did try a Realtek 8111 card, with Mieze's driver, and had same symptoms; therefore reverted back to the internal intel card so I could get the slot back for a Radeon (this is a mini-itx board).
Have considered buying a USB3 ethernet adapter for a test of a similar colour, that avoids hackintosh drivers, though they come with, and apparently need, their own. They're cheap enough I may consider it again. If there's commonality between hnak's and mieze's drivers though, it may be that they were both ports from Linux drivers?
Might as well add some more obs in the time since my last post. :-)
It's *definitely* nothing to do with IPv6. I eventually disabled that all the way up at the router, so it's off for the whole LAN. It did not prevent this problem occurring. I should turn it on again, to see if it affects severity or likelihood though. I wanted to be sure of this because, if it *is* an OS X network stack bug, there had to be some reason why it wasn't affecting so many people, including high profile content creators, that there would be uproar about it actually hitting the non-tech news! If it was IPv6 only, that would help explain its rarity. But it doesn't seem to be.
Also eventually confirmed this specific problem *does* also still happen if VMWare's running, so whatever it does that helped with the separate IPv6 issue reported earlier in this thread, isn't relevant here. I think I expressed some hope that it was a few posts ago.
I have been able to get by and complete transfers by trying harder not to do too much other stuff while the transfer is taking place; generally now I actually quit everything else and walk away from the computer! There would still be bonjour chatter I'm sure, but it's presumably below the threshold, or I've just been lucky. But the fact that works supports another commenter's theory that it's related to multiple threads competing for the network.
(It's possible before when I said otherwise, it was enough that I might have had a finder window open on the destination, trying to create previews, or other ssh sessions open to the same server. ie: so other threads had traffic to the same server, even if not very much, and no other large file transfers going on.)
rsync over ssh to the remote server seems the most successful: The issue can and does still *happen*, but rsync promptly exits with an error, which can make recovery easier. If the transfer is done over a mounted filesystem (SMB & NFS tested), either through rsync or Finder or whatever, the process just hangs.
using --bwlimit on rsync to limit the throughput rate doesn't prevent it.
Observed continuous flashing of the activity indicator light on the ethernet interface and on the switch after the problem occurs. On one occasion at least it was flashing the activity indicators on *all* the connected ports on the switch; on others, just the ones connecting to this and the destination server. Thinking this may indicate any particular thread might deadlock when this problem occurs; in at least one case, probably some bonjour operation. This carried on perpetually after the connection had failed on the mac, and no further transfers were (apparently) taking place. Unplugging and plugging back in didn't resolve it, it just resumed on plugging back in.
I *can* reset by taking the interface down and up again from command line, ie:
sudo ifconfig en0 down
sudo ifconfig en0 up
After doing this, the connection works normally again. Wondering if this may be useful for debugging, as presumably what happens during down/up is understood by someone. :-) This is better than having to hard-reset the computer! And of course I should have tried it *much* earlier. It's also possible this only works in combination with using rsync over ssh, as that exits rather than hangs when the problem occurs. I was previously doing a hard reset rather than an orderly reboot because the orderly reboot was hanging.