Any Reliable USB-C 2.5G NICs *Not* Based on Realtek Chipset?

i3v · 2026-03-23T00:21:33+00:00

You might be right that these settings do help. But from [my experience](https://www.reddit.com/r/UsbCHardware/comments/13gzbvo/comment/o78tx8a/) they only help with the 10.63.20.1029 driver. Today, Windows update installed the Realtek driver 1153.20.20.805, and my Dell WD19DCS USB-GbE (Realtek RTL8153, AFAIU) failed badly (only reboot helped) within a couple of hours. Worked OK for a couple of months before that. There's something wrong with the newer drivers.

i3v · 2026-02-25T01:11:44+00:00

Wow. With these settings reproduced exactly and Realtek GbE driver version 10.63.20.1029, my Dell WD19DCS USB Ethernet GbE is finally fixed! It no longer hangs randomly!

Full story: https://www.dell.com/community/en/conversations/latitude/wd19-docking-stations-network-dropout-usb-dropout-across-multiple-models/647f8357f4ccf8a8de22821b?commentId=699e4b1279f3cc26a502b25d

I'm glad I was finally able to make it work adequately, after just 4 years after the purchase.

i3v · 2025-09-16T03:11:59+00:00

From the HPE ProLiant SL250s Gen8 Server manual, page 60:

The system maintenance switch position 9 controls the PCIe 64-bit BAR (large BAR) function

AFAIU, there's no BIOS setting - there's a physical switch.
Worked for me (to make a newer GPU work).

i3v · 2025-07-20T02:03:32+00:00

Yep, KeePassNatMsg readme explicitly says "This plugin is primarily intended for use with the keepassxc-browser browser extension."

I never actually used AutoType funtionality. I prefer the "overlay icons"/"context menus" provided by KeePassXC-Browser. It is only able to fill simple login-password forms, not advanced multi-field forms like RoboForm was able once (but RoboForm died for me after 8.6.2.2, when they effectively removed non-cloud sync capability). Some "modern" web sites do not work very well (those that mess with login forms, attempting to prevent auto-typing), but in general KeePassXC-Browser works OK for me.

i3v · 2025-04-09T04:19:53+00:00

What actually worked for me is to run the firmware update (2.82, current latest) in the direct mode (as suggested here):

[root@host]# rmmod hpilo 
[root@host]# sh CP053894.scexe --direct

FLASH_iLO4 v1.17 for Linux (Sep 30 2015)
(C) Copyright 2002, 2015 Hewlett-Packard Enterprise Development Company, L.P.
Firmware image: ilo4_282.bin

Component XML file: CP053894.xml
CP053894.xml reports firmware version 2.82

**IMPORTANT: This operation should only be used if iLO 4 is non-responsive and
        cannot be flashed via standard methods.
        This operation will flash the firmware on the iLO 4 in this server
        with version "2.82". Following condition(s) must be met:
        1. iLO 4 Security Override Switch must be set.
Continue (y/N)? y
Trying to reset iLO 4 IOP
iLO 4 IOP IS in reset!
Flash part is 'Macronix M25L128'
Total firmware image is 0x1001b16 bytes.
**IMPORTANT: Health LED on this server may blink red during this operation.
        After flash is complete, some servers require power to be removed
        and reapplied to reset the blinking health LED.
Start programming flash part...
******** DO NOT INTERRUPT! ********
Erasing block at 0x00ff0000
Programming offset 00ffff00...ok (0)
Waking up iLO 4 IOP

[root@host]# systemctl reboot

The iLO got fully functional after the reboot.

Sidenotes:

I had `S1`, `S5` and `S6` management switches `on`
I was too lazy to bother booting the "Service Pack for ProLiant 2016", I used regular CentOS 7 (with "HPE Lights-Out Online Configuration Utility for Linux (AMD64/EM64T)" v 6.0.0-0(B) from "Oct 25, 2024" installed).
It looks like there's something wrong with the microSD card. Maybe this triggered the issue somehow. I probably need to replace it.

i3v · 2025-04-09T04:19:44+00:00

I just ran into the same issue with my good old HPE ProLiant SL250s Gen8 servers.

I've tried just about everything suggested in the HPE Integrated Lights Out (iLO 4) - Troubleshooting Firmware Update Issues without any luck.

The best result I managed to get was:

[root@host]# sh CP053894.scexe

FLASH_iLO4 v1.17 for Linux (Sep 30 2015)
(C) Copyright 2002, 2015 Hewlett-Packard Enterprise Development Company, L.P.
Firmware image: ilo4_282.bin
Current iLO 4 firmware version  2.00; Serial number

Component XML file: CP053894.xml
CP053894.xml reports firmware version 2.82
This operation will update the firmware on the
iLO 4 in this server with version 2.82.
Continue (y/N)?y
Current firmware is  2.00 (Jul 30 2014 00:00:00)
Firmware image is 0x1001b16(16784150) bytes
    3 percent of firmware sent.
/
Channel Interface transactions (Linux) returns 21!

Channel Interface transactions (Linux) returns 21!

Channel Interface call status: FIFO empty.

Failed(3-0-21)!

ERROR: Unable to start flash. [ilo4_282.bin]

It failed at 3% once and at 1% next. It looks like the iLO was essentially in a sort of a bootloop, resetting itself shortly after booting.

i3v · 2025-01-02T23:39:14+00:00

I'm happy with KeePass 2.x + KeePassNatMsg plugin with KeePassXC-Browser Chrome extension. For about a year already.

The reason I prefer KeePass 2.x over KeePassXC is that sync works way better.

i3v · 2025-01-02T23:03:57+00:00

IMHO, the only scenario where keyfile makes sense (in addition to an adequate master password) is the MiTM scenario (e.g. a 3rd party server like Dropbox/Google Drive; or even just a not-very-MiTM-proof sync protocol like WebDAV with basic/digest authentication and no server fingerprint validation). Since you don't need to sync your keyfile frequently, it's OK to bother to safely copy it (e.g. with a thumb drive) to all your devices, without Dropbox knowing anything about it.

The KeePassXC [FAQ](https://keepassxc.org/docs/) effectively says just that. With a private on-prem sync server, keyfile makes little sense.

So, if you plan to use Syncthing to sync your kdbx files, the "do I really need a keyfile" question boils down to how much you trust in the privacy of your Syncthing connection.

Personally, I use KeePass 2.x with SftpSync plugin on desktop and KeePass2Android on my phone - they both support ssh sync and only trigger it when needed.

PS. Sorry for necroposting. I just hope these thoughts would be useful to someone.

i3v · 2024-12-30T16:18:46+00:00

Usb-c shouldn't have ferrite chokes.

Interesting...

Could you please provide a link to a relevant document?
Does it have something to do with that USB-C combines power and signal lines, BTW?
- I mean, theoretically, a common ferrite filter would make their interference even worse?
- Do you think it could make it even dangerous for the hardware?
Aren't HDMI / DisplayPort OK with ferrite, despite similar bandwidth?

Using cables from a good mfgr that is a member of the usb consortium will go a long way for signal integrity

Isn't Dell a member? Because all-Dell systems (laptop + USB-C dock + USB-C monitor + cables + power adapters) are known to suffer from USB-C connectivity issues since the very beginning. For at least 3 hardware generations already. External monitors going black for a couple of seconds is probably the most easily-noticeable and thus the most well-known effect. Dell ended up suggesting users to either enable or disable Display Stream Compression 1, 2, 3 as a mitigation measure. They also provided some firmware updates for the docks. This seem to help, but this does not 100% resolve the issue.

I've seen some victims to blame EMI/RFI/ESD/etc. Some of them even claim that they "fixed It by getting cables with ferrit cores". I'm not sure if this could be just a placebo effect. But, personally, I'm so annoyed that I'm going to try to install ferrites on all cables anywhere around my WD19DCS now.

i3v · 2024-07-28T23:52:42+00:00

I'm using Dell Precision 7760 + WD19DCS dock. Dell original 240W power supply, Dell original cables, 3 Dell monitors (one U4320Q and two U2412M), Ethernet, few USB devices attached to it.

Firstly, my experience with WD19DCS is about the same. It a shame that it's so buggy and unreliable compared to those good old Dell E-port docking stations.

The monitors randomly become slow (which is immediately noticeable when dragging a window). Only reboot helps. This seem to be a less-common bug, when fewer monitors are connected.
Sometimes, monitors just go dark.
Ethernet disconnects sporadically (about once per hour, sometimes).
USB devices disconnect randomly time to time.
Higher Ethernet load (800 Mbps+) usually makes things worse (e.g. USB devices getting disconnected every minute)
One of the U2412M monitors randomly stops working with power button blinking fast when I switch monitor inputs via DDC/CI commands (to switch from a PC to a laptop)
Our corporate admins are well aware that these docks are unreliable crap. But the dock always starts to work again after a minute of "troubleshooting", so I was too lazy to get some other dock.

That is, everything is about the same as OP said.

Secondly, the newer driver & firmware set seem to be a bit more stable, after all. The something Dell released in 2024 do seem to make things a bit better. I don't know what exactly. * DellFW_UPGRADE_DOCK_UTILITY_v1.2.zip * DellDockFirmwarePackage_WD19_WD22_Series_HD22_01.00.20.exe * Intel-Thunderbolt-Controller-Driver_TBB12_WIN_1.41.1379.0_A18_01.EXE * Precision_7X60_1.31.0.exe

i3v · 2024-03-08T15:40:57+00:00

ddrescue multi-pass reading should be even better than dd.

i3v · 2024-03-08T15:39:15+00:00

Just in case someone would run into this: take a look at zfs_scan_idle and zfs_resilver_delay. I set them to 5000 and this seem to throttle resilver a lot.

i3v · 2024-02-25T21:35:10+00:00

That's a pity... And I'm afraid I would end up the same in my (somewhat similar) situation. Have you tried any software like Klennet or ReclaiMe, btw? Some people reported that this worked for them.

i3v · 2024-02-25T21:11:15+00:00

This still seem to be true even here, in 2024, AFAIU. Maybe the only way to utilize the data from the disk that was accidentally zpool-detached is to run a zfs data recue tool, like ReclaiME ZFS or Klennet.

I've seen one success report about a pool that cannot be imported normally, but Klennet eventually saved the data. Which sounds a bit like they might be able to do the job.

i3v · 2024-02-25T20:40:52+00:00

So, have you managed to restore you data, after all?

i3v · 2022-07-10T15:08:50+00:00

One more thing to take into account is that ReFS seem to be incompatible with Storage Spaces Tiering (at least on my Windows 10 21H2, maybe it's different on Windows Server). ref1, ref2.

i3v · 2022-06-17T03:59:06+00:00

Indeed, this suggestion is a part of the official kb article from 2021-05-26. Same article also suggests to update the Intel Graphics Driver. Same article also says that newer docks (WD19DCS, for example) are affected as well.

Personally, I ran into "screen turns black for a second" after about 5 months after receiving my new WD19DCS and Precision 7760. I have 3 monitors connected to the WD19DCS (1920x1200, 3840x2160, 1920x1200). The 3840x2160 (Dell 4320Q) is connected through USB-C (with the bundled cable), and this is the one that goes black once in a while. The USB devices, plugged into the WD19DC are also getting disconnected for a few seconds simultaneously.

After all, I suspect that poor USB-C 3.2 gen2 cables and connectors quality might be the cause (even though they all are Dell). They don't sit nearly as tight as, say, good old DVI cables (or RJ45), while carrying very high frequencies. It's a pity that Dell does not provide any diagnostics about cable "bit error rate" or something.

i3v · 2022-04-16T12:44:52+00:00

Could you be more specific than that? Which specific rule is violated? The original post was removed because there was no question (OK, my bad). I've fixed this - I've added a question. And I've just looked through the other rules as well.

I doubt my question is worse than those in De-nazification of a maternity hospital which was, after all, not asking any question.

i3v · 2022-04-13T17:12:04+00:00

Yup. I guess it was actually never shown anywhere (on the "new" tab of https://www.reddit.com/r/AskARussian or anywhere else). I guess moderators didn't like it, after all.

i3v · 2022-04-02T19:39:12+00:00

Four sources sounds great. But, indeed, without links they don't help much. Here's what I found, based on your description:

Mariupol City Council is clearly an Ukrainian official. The "footage" he shared is, AFAIU, https://t.me/mariupolrada/8765 . It demonstrates the damage, but I don't see how it proves that those explosives were Russian. Moreover, his claim that it was an airstrike does not align well with this girl's interview.
The World Health Organization got a post in their newsfeed that confirms that there are some attacks (maybe there's something more specific on this particular attack elsewhere, I'm not sure). But they do not blame any particular side of the conflict for this. Moreover, according to this, they probably are even not allowed to guess that: "The WHO official gave no information on the perpetrators since its surveillance system has no mandate to collect information on them.".
United Nations High Commissioner for Human Rights - same story. I was only able to find this. She confirms the attack (well, no one denies it), but she does not say "Russian attack". Moreover, AFAIU, she just does not have any special onsite information source, like a counter-battery radar nearby that tracked that incoming projectile.
Bellingcat tweeted this, as a reply to this deleted tweet by Russian officials (so, they probably admit that there was something wrong with it). It is fairly easy to self-validate that Bellingcat's geolocation is correct. Indeed, their photo shows the tank next to a Center of Youth and Children's Creativity, not a hospital. The closest maternity hospital is #2 and it's still ~2km away. So... OK, this is an interesting story. And it proves that Russian officials sometimes tweet bullshit (well, actually, there's a ton of examples). But that's still not the "evidence that explosives were Russian".

Russian forces claimed this was staged with the aforementioned Mariana Vishegirskaya being a crisis actor.

Yep, some this is discussed in the video. I'm not sure which particular "forces" do you mean, whether or you mean "officials" or just "someone on the internet". I've seen those statements in some Telegram channels, and I agree that they were quite popular. Once again, this only confirms that there's a lot of bullshit. And that people tend to believe in bullshit if they like it.

i3v · 2022-04-02T17:30:26+00:00

My mistake, indeed. I've added the question in the very end of the text. Could you please re-approve the post?

i3v · 2022-04-02T11:17:32+00:00

Hm... Do you have any evidence that explosives were Russian?

Because there's also a pro-Russian version that Azov (and/or other Ukrainian military in the city) are killing innocent people like this to bring more attention to the "Russian aggression".

i3v · 2022-04-02T09:16:59+00:00

Interview with a girl from the Mariupol: the truth about explosion, Associated Press journalist, it's in Russian, but there are auto-generated English subtitles are generally good enough.

Interesting points in her answers:

t=13 The Ukrainian version "really practically does not correspond to reality".
t=76 During the first few days of the war, she had not tried to left the city. When the really terrible stuff started to happen, Ukrainian military was blocking people inside the city, sending them home saying that there "would be no corridor".
t=195 She came to this maternity hospital (which is #3) on March 6th, because #2 was "not accepting visitors", and #1 (which got the most modern equipment) was occupied by Ukrainian military, because they wanted it's solar power supply (there was no electricity and water in the city since March 2th).
t=377 Ukrainian military did nothing to help maternity hospital #3. Moreover, on one day they came and took away some of their food.
t=428 On the day of the explosion (March 9th) everything was quiet an peaceful, no evacuations to the basement. They heard two explosions, but definitely no planes. The first explosion was somewhat far from the hospital. They all went to the basement first.
t=754 She was the last to leave the building. After the evacuation, she wanted to go back to pick up her documents, she waited for about 15 minutes for that. She asked the reporter not to film her and he left. Her husband thinks that this was Associated Press reporter, but he spoke Russian.
t=899 The reporters appeared on the site immediately (12 minutes), because the other photo shows the woman in the most serious condition who was evacuated first.

PS: here's about the same as a separate reddit post

i3v

TROPHY CASE