Wd sentinel dx4000 Network Adabpter are not working

if you just have 2 drives you should be able to see your data in a usb dock. If you have more than 2 drives you will need that many usb docks and a 3rd party raid recovery software.

Or if you can find a working box, inserting your drives in it should also work.

I have a spare box and I put the drives in booted up and installed a usb nic. I then put the drives and the nic back in the old box and I am still using it.

Thanks for your replies. Just ordered an used WD4000 without disks, and the StarTech USB-ethernet. Plan is to put the disks in the second NAS, configure the USB-eth, move disks back to the old one and sell the spare NAS.

Let us know how it turns out
thanks

Got the second DX4000 today and the operation was a success.

So I changed the HDDs from my old NIC-malfunctioned DX4000 to this new one I had ordered without HDDs. Original NAS model is 16TB and the new one is 8TB but this didn’t matter as I expected. Box booted on the very first try. The static IP I had configured didn’t work but saw the DHCP lease and could connect to that IP with RDP. From there I saw the NICs of the new box were now numbers #3 and #4 where the “WDTeam” interface with my original network settings clearly is using NICs #1 and #2 that arent there anymore. Didn’t bother checking how to fix the teaming interface as it’s a lousy fallback setup which doesn’t even work when the controller chip breaks as we have seen.

Then plugged the StarTech USB-ethernet adapter. Installed the drivers for that. Setup a static IP for the interface. Tested RDP with that IP. Tested that the adapter can be removed and re-plugged without loosing the connectivity. So my DX4000 is now back in business.

Thanks for all help on this thread.

NOTE! If you have a DX4000 and you’re reading this, do at least the following: Download and install the driver from https://sgcdn.startech.com/005329/media/sets/ASIX_AX88179/[ASIX88179]%20Windows%20USB%20Network%20Adapter.zip - now when day comes that your NICs fail, you can order that USB-ethernet adapter, plug it in and connect to the DHCP IP gotten

Thanks for the report and pre-load idea !!

Excellent report back and advice

:grinning:

I came here looking for information on how I could save my WD4000DX in a pinch. Ie. Not waiting for a used one to ship from somewhere. The post in the thread referring to using USB tethering works! I managed to connect a Google Pixel 2 to the NAS via USB (USB-A to USB-C) and provide a working network via USB tethering. Once you’ve connected the cable and enabled tethering the device should automatically pick up an IP , as mentioned previously, because RNDIS is built in to Windows Server 2008. The tricky part is finding the IP address of the device, without a screen. You could try to connect, one at a time however I found a app on the Play Store which can find the address. The app is “PingTools”. In PingTools , click the hamburger menu (top left) and select “Subnet Scanner”. Once the scan is complete, you should see one result with the address of the NAS. You can then proceed to use RD Client (also on the Play Store) to start a remote connection. Find the drivers for the Startech adapter mentioned above, and install the corresponding version. Once that is done, you can plug in the Startech ethernet adapter into the usb port on the back. Be patient, as it takes a minute or two for the device to be ‘setup’ by this beast of a machine /S. Now you can plug it back into your network and it should connect.

1 Like

what actual rd client did you get?
playing with a win 10 first, have all the ip’s, can ping tough it only showed port 135 open> The Microsoft client says no network

Thanks,
Gramps

btw the usb c to a cable is the charging cable :slight_smile:

NIC’s died on me after a windows update today. Fortunately I had just installed a usb-ethernet adapter, and a usb-vga adapter. Both nics are completely gone from the system, and all that remains is a western digital Teaming adapter. The teaming adapter combines the two physical adapters, which were killed by windows update.

Going to see if I can get them back somehow.

For the VGA adapter, I had to install an intel video controller driver for an Intel Atom D525 processor. I’m guessing I will have to do something like that for the NIC’s, but not certain. Going to try and backout the windows update and see what happens first.

Update


Seems to be no way of getting the NIC’s back. And there’s no way to uninstall the default Teaming NIC adapter. I believe the double NIC failure is most likely caused by a blown driver. The physical NIC’s are bound to the Virtual Teaming adapter somehow. Probably some sort of command line magic. That bridge probably gets broken, taking the NIC’s with it. It’s some sort of weird proprietary hardware configuration using intel chipsets. It’s not worth my time any longer trying to sort it out.

My unit is working fine with the USB-Ethernet adapter. It’s also been really nice connecting a monitor to it. I actually have mine integrated with a KVM switch, and it works like any other server in the rack.
I can access my DX4000 directly like any other computer, or remotely through RDP.

I just find it hard to believe both NIC’s would die at the exact same time, which is why I consider this more likely to be a software/driver issue.

Good luck all.

Kudos to serpet and to mjovanovic!!!

Such a simple solution and so difficult to find it on the Internet. The NIC failure (or user disabling it by mistake) is such a frequent occurrence and WD is absolutely no help. I am not going to rant, but I just wanted to applaud you for a simple solution to a “disaster” grade issue. I assume that most of the people use the DX4000 to store valuable files like family (or clients) pictures, video clips, documents, etc. To offer no help and to direct your customers to high priced data recovery services (WD I am talking to you
), it’s just plain wrong.

I can confirm, that connecting an Android device (a mini tablet in my case) to one of the USB ports on the back of the DX4000, using a micro-USB (charging) cable, did the trick. I had to enable “USB Tethering” on the Android device and then I’ve used the two recommended apps: “Ping Tool by ManageEngine” and “Remote Desktop by Microsoft” from the Play store (both free). It may take a few minutes for the DX4000 to recognize the new “network adapter” and to get an IP. In my case the IP was in the 192.168.42.0 subnet. I found the IP address of the DX4000 using the “IP Scanner” option in the “Ping Tool” app and the connected to that IP using the “Remote Desktop” app. Piece of cake.

Again, thanks a million serpet and mjovanovic!

Cheers,

Got both NIC’s fail about a week ago on my DX4000. Pulled apart the box and found failed step-down voltage controller IC U17 (can visually see it, got charcoal) which supplies power to both NIC controllers (redundancy.lol). When one NIC goes bad, it pulls the other one down with it because the controllers are running from the same supply. That would explain why both NIC’s go down at the same time. Waiting for parts to arrive. Will find out soon enough if replacing a $1.80 part will fix the issue.

Thanks for this post space _monkey if this is the problem it may be the root cause of many failures reported by users. Feedback on your further experience much appreciated.

Hi, for the Intel D525 VGA video controller did you download and install the “Intel Graphics Media Accelerator 3150 Driver for Windows”? Was it the W7 version?

thanks and regards

That sounds right. Won’t hurt to install it.

I have finally managed to repair my DX4000 unit with both onboard NIC’s working.
Here is what i have done:
I have replaced both gigabit controllers (WG82574L) marked with pcb designators U23, U22.
These you can get from RS Components.


There are three power inputs which go into U23 and U22.
These are 3.3V, 1.9V and 1.05V.
The 3.3V is there to power the controller and the other two are logic supplies (I think)
The IC that i have charcoaled on the board (U17) ended up being a step down converter which had an output of 1.9V (which i worked out by using continuity test on DMM).

When i got the replacement U17 (RT8259) step down converter delivered, it didnt output 1.9V but 11V instead which lead me to believe that the resistor network which decided what voltage output is going to be was damaged.
So i used a custom power supply board which i wired in manually onto the PCB to give me the desired 1.9V supply for the gigabit controllers.

After putting everything together, i connected i the power supply, network cable and powered upo the unit.
Shortly after the powerup i have seen the very thing i was waiting for " an IP adress pop up on the DX4000 LCD screen given by my router".

Once again i have to remind everyone that the powersupplies that provide 3.3V, 1.9V and 1.05V are shared between both controllers.
If one controller goes bad for an unknow reason than it shorts out the power supply that is used by the otherne aswell. I still think that that if NIC’s fail one should be able to access the data via one of the two USB ports provided.
Well, here is my 5 cents worth of experience, hopefully this information will help others that are still holding on to their unit hoping that one day they will be able to retrieve their precious data.

Great, but way too hard for me LOL
You need to offer a repair service !!

I think it’s great that you have sorted this out and also exposed the clear design weakness. Much appreciated. Thaniks

Thank you, SpaceMonkey. Your post was very informative and convinced me to fix the ethernet on my board as well.

Although, unlike yours, my buck regulator section did not show any physical signs of being a bad chip–I had to test it out thoroughly. Basically, it seemed like the feedback section got busted after it failed, so it was outputting around 1V (after I desoldered the dead GbE ICs).

I also didn’t bother soldering in two GbE ICs, since the single point of failure is the buck regulator section anyway.

Also, I successfully replaced the RT8259 buck IC with an AOZ1280, since they have the same feedback voltages and similar switching speeds and specifications.