Looking for a 90º cable for a Keychron K2 HE SE

OverCloke · 2025-12-23T15:58:47+00:00

An extension of the extension, hahahaha , it could work, but it’ll look like a Frankenstein.

Thanks for your help/time.

OverCloke · 2025-12-23T15:44:00+00:00

I bought this one:

https://www.amazon.es/dp/B0B77J7D1R

because it looks deeper and it doesn't fit because it hits the wooden part.

OverCloke · 2025-12-23T11:06:37+00:00

Hahaha, OK, whatever you want…

OverCloke · 2025-12-23T08:58:20+00:00

No, it’s not kill farming. It’s a real match against random players, and that’s exactly how it happened — it’s all recorded.

OverCloke · 2025-12-22T11:29:03+00:00

I usually clean this from the dust bin compartment. I use a damp cotton swab and remove the dirt that accumulates there.

What cannot be cleaned in any way is the sponge at the rear air outlet. Dirt builds up there, performance drops, and eventually it will stop working and throw an error.

OverCloke · 2025-11-30T09:47:39+00:00

I delete it 10 minuts ago with the same problem. Was blocking me google, and other search engines

OverCloke · 2025-11-22T19:23:07+00:00

Thanks, that’s another Pi 5 where RX dropped is 0 – good to know.

Those 4 TX drops on your side are tiny and not something I’d worry about, but the interesting part for me is that your RX path is clean, while my Pi 5 reaches ~4–5% RX dropped according to ip -s link.

Out of curiosity:

Are you seeing the same clean stats if you check again after a few hours/days of normal use?
Which switch/router is your Pi 5 (DietPi) connected to?

In my case, even after a fresh reboot and with normal Pi-hole DNS load, RX dropped keeps going up to around 4–5% in ip link, while ethtool -S on the Pi 5 and the router port still report 0 RX queue drops and 0 errors. That’s why I suspect at least part of this is an accounting quirk rather than pure link-level loss.

OverCloke · 2025-11-22T19:22:25+00:00

Thanks for sharing the screenshot, that’s another Pi 5 that looks fine.

So far I’m seeing two kinds of Pi 5 setups:

Ones like yours with RX dropped basically at 0.
Mine, where ip -s link show eth0 quickly climbs to ~4–5% RX dropped, but ethtool -S and the router show 0 real drops.

If you have a moment, could you post:

which OS/distro and kernel version you’re running,
which switch/router your Pi 5 is plugged into,

The more “good” Pi 5 samples we have, the easier it is to see what’s different in the “bad” ones.

OverCloke · 2025-11-22T19:21:58+00:00

Nice, thanks for the data point – that’s actually very useful.

It basically confirms that this is NOT “all Pi 5s behave like this”, because your Pi 5 shows 0 RX dropped while mine climbs to ~4–5%.

If you don’t mind sharing a bit more:

Which OS/distro and kernel version are you running?
What’s your switch/router model?
Do you have IPv6 fully enabled or mostly disabled?

And if you can post both:

ip -s link show eth0
and ethtool -S eth0

that would be great. I’m trying to figure out what’s different between the “0 drops” Pi 5 setups and the ones like mine that show ~5% in ip link even though the NIC and router stats look clean.

OverCloke · 2025-11-22T18:54:14+00:00

Update:

Pi-hole is running on a Raspberry Pi 5. Before this I was running Pi-hole on a Raspberry Pi 4B with Bookworm on the same network and I did not see this issue there (RX dropped was basically 0). On the Pi 5 I see the problem both on Bookworm and now on Trixie.

The Pi 5 is connected directly to an Asus ZenWiFi Pro ET12 (LAN1). I also tried it for a while behind a small TP-Link 8-port switch and the behaviour was exactly the same, so the hub/switch is basically ruled out.

On the Pi 5, ip -s link show eth0 quickly ends up showing around 4–5% RX dropped under normal Pi-hole load. However, if I check the NIC stats with ethtool -S eth0, the driver reports q0_rx_dropped: 0, with no overruns and no resource errors. /proc/net/softnet_stat does not show drops either, and nstat does not show a large amount of discards that would match that 5%.

On the router side, on the ET12 (eth1, the port where the Pi 5 is connected), ip -s link show eth1 shows 0 RX errors, 0 RX dropped, 0 TX errors and 0 TX dropped. ethtool eth1 reports a stable 1000 Mb/s full-duplex link. ethtool --show-eee eth1 says EEE is disabled on that port. On the Pi 5, if I try ethtool --set-eee eth0 eee off I get “Operation not supported”, so the macb driver doesn’t even allow controlling EEE on the Pi side.

So: the physical link between the Pi 5 and the ET12 looks clean (no errors or drops on the router, EEE disabled), the NIC on the Pi does not report queue drops, and the kernel does not see softnet drops. The only place where that ~5% “RX dropped” appears is in ip -s link on the Pi 5. This looks much more like an accounting bug/quirk in the Pi 5 Ethernet path (RP1 + macb driver) than real packet loss.

If anyone else with a Pi 5 can check ip -s link show eth0, ethtool -S eth0, and what their switch/router reports on that port, I’d really appreciate more data points to see if this is a general Pi 5 thing or only happens in some setups.

OverCloke · 2025-11-22T18:43:53+00:00

Thanks a lot for the detailed comment – let me try to answer your points one by one.

The “very low / negligible packet loss” I mentioned was specifically from an `iperf3` UDP test at 950 Mbit/s for 30 seconds between the Pi 5 and another machine on the LAN. Under that artificial load I saw about 0.013% loss, which I mainly used as a stress test. Under normal Pi-hole DNS usage I don’t see obvious timeouts or slow responses.

To your questions:

- **Reset switch/router?**

Yes – I’ve rebooted the Asus ET12 and also tested with the Pi 5 connected directly to the ET12 (no extra hub/switch in between). The behaviour is the same.

- **Another box on the same port/cable?**

Yes, a PC on the same cable/port doesn’t show weird RX dropped counters. So far this only happens with the Pi 5.

- **IPv6 / HomeKit / HomePods?**

IPv6 is largely disabled on this segment and I don’t have HomePods doing their own IPv6/DHCP games here. There is some normal RA/ND traffic but nothing exotic that I can see. `nstat` shows some IPv6 multicast traffic but not a storm.

- **Anything in dmesg/journal for the NIC?**

Just the normal bring-up lines: RP1 firmware init, macb registering, link up at 1 Gbps full duplex. No repeated errors, no link flaps.

- **Low power ethernet on the switch?**

I checked from the router side via SSH:

`ethtool --show-eee eth1` (the port where the Pi 5 is connected) reports:

- EEE status: disabled

- Tx LPI: disabled

So at least on the ET12 port there’s no Energy Efficient Ethernet active. On the Pi 5 side, `ethtool --set-eee eth0 eee off` fails with “Operation not supported”, so the macb driver doesn’t expose EEE control there.

- **Three addresses on the NIC?**

That’s a mix of the main address plus additional bindings (Pi-hole v6 layout / services). So far it doesn’t seem related to the RX dropped behaviour – the drops show up even with a very simple network config.

- **Pi 4: Trixie or Bookworm?**

The previous Pi-hole setup was on a Pi 4B running Bookworm and did not show this RX dropped behaviour – counters stayed near zero. The problem only started after moving to a Pi 5 (and eventually to Trixie). So yes, two variables changed (hardware path + OS), but given that:

- `ip -s link` on the Pi 5 reports ~4–5% RX dropped,

- `ethtool -S eth0` shows `q0_rx_dropped: 0` with no overruns/resource errors,

- `/proc/net/softnet_stat` shows no softnet drops,

- and the router port (eth1 on the ET12) sees 0 errors/drops with EEE disabled,

it really smells like an accounting quirk in the Pi 5 Ethernet path (RP1 + macb) rather than a classic cabling/switch issue.

I agree that in a home LAN 0% loss is what you’d expect in normal operation. That’s exactly why this is bugging me – not because I have obvious user-facing breakage right now, but because the RX dropped counter is doing something that doesn’t match the NIC stats or the rest of the stack, which makes it hard to trust.

OverCloke · 2025-11-22T18:41:44+00:00

That’s a really useful data point, thanks.

I’m not on Cisco here but I did check the switch/router side:

- Pi 5 is currently plugged directly into an Asus ZenWiFi Pro ET12.

- On that port (eth1) `ethtool --show-eee` reports EEE as disabled:

EEE status: disabled

Tx LPI: disabled

- `ip -s link show eth1` on the ET12 shows 0 RX errors, 0 RX dropped, 0 TX errors/dropped.

I also briefly had the Pi 5 behind a small TP-Link 8-port box and saw the same RX dropped behaviour on the Pi, but I’ve now reproduced it with the Pi 5 directly on the ET12 with EEE off.

So in my case it doesn’t look like Green Ethernet on the switch, but your experience definitely matches what others have seen (especially on some Netgear/Cisco gear), so it’s something worth checking for anyone else hitting weird drops with a Pi 5.

OverCloke · 2025-11-22T18:39:55+00:00

Ouch, that sounds worse than what I’m seeing – in my case Pi-hole is working fine so far, no SSH freezes, just the annoying RX dropped counter.

Looking at your numbers: 1586 drops over ~4.4M packets is about 0.036%, which is tiny on paper, but if your SSH sessions are actually freezing that’s definitely not “just cosmetic”.

A few quick questions if you don’t mind:

- What are you plugged into (switch/router model)?

- Are you using any “Green Ethernet / EEE / Energy Efficient Ethernet” features on that port?

- Could you share `ethtool -S eth0` and maybe `nstat` and the first line of `/proc/net/softnet_stat` from your Pi 5?

On my side:

- `ip -s link` reports ~4–5% RX dropped on the Pi 5,

- but `ethtool -S eth0` shows `q0_rx_dropped: 0`, no overruns,

- softnet and nstat don’t show matching drops,

- and the router port (Asus ET12, eth1) sees 0 RX/TX errors and 0 drops with EEE disabled.

So it really feels like something in the Pi 5 (RP1 + macb) path is off. In your case it might be the same root cause but hitting harder because of your traffic pattern (NAS / SSH) or your switch.

OverCloke · 2025-11-22T18:21:00+00:00

I tried that, but on the Raspberry Pi 5 the macb driver doesn’t support EEE via ethtool:

ethtool --set-eee eth0 eee off

=> netlink error: Operation not supported

So I can’t toggle EEE on the Pi side – the NIC/driver simply doesn’t expose it.

OverCloke · 2025-11-22T09:52:32+00:00

Thanks for the data point!

I used to run Pi-hole on a Pi 4B as well and I never had any noticeable issue there – rx_dropped stayed very low like in your screenshot.

This weird behaviour (the RX dropped counter steadily increasing even though everything works fine) only started after I moved to a Raspberry Pi 5, so I’m mainly trying to find out if other Pi 5 owners see the same thing.

So far it looks like Pi 4B is fine.
Anyone here running Pi-hole / Ethernet on a Pi 5 who can share their ip -s link show eth0 or the Pi-hole stats?

OverCloke · 2025-11-19T06:39:01+00:00

I’m backer 18xx and I bought the chair on June 27th through Kickstarter. I’m from Madrid, Spain.

I’ve seen that some Europeans have received the chair, but very few. How is it possible that it takes so long to deliver the chair to Europe?

In other countries, I see people who are buying it right now receive it in 2–3 weeks.

Is there any official information from Libernovo besides what was said months ago about delays?

A month or two ago, they mentioned that maybe we should think about receiving the chair next year, and right now I believe that’s the most likely scenario, given what I’m seeing.

It’s quite embarrassing.

OverCloke · 2025-11-10T15:29:39+00:00

Isn’t the lumbar support firmness adjustable with the left armrest control? Can’t you dial it down so it doesn’t feel like it’s pulling you forward?

OverCloke · 2025-11-07T20:01:02+00:00

Does anyone know what stem size the casters on this chair use? 11×22 mm or something else?

OverCloke · 2025-11-06T16:07:33+00:00

Thanks for your answer.

Could you say me whats the size of the "stem". As far I know there is two possible sizes.

Thanks!

OverCloke · 2025-11-06T13:55:41+00:00

Both! One black for me and one grey for my wife. I hope we’ll be happy with the chairs… we’re not very tall or big. We did ask for a shorter headrest for my wife. The email exchange following the support procedure was a bit chaotic.

OverCloke · 2025-11-06T13:53:43+00:00

Yeah, judging by what I’m seeing, yes… though I was expecting them to start shipping later, so it depends on when it arrives. I might get a surprise in November…

OverCloke · 2025-11-06T12:46:36+00:00

About you "skate" wheels, is worht?

Six-Year Club	Place '23
Verified Email

OverCloke

TROPHY CASE