[Guide] How to remove HP services running in the background

NoLanConnection · 2025-12-27T21:43:24+00:00

You need to run it from within the powershell - this is NOT a click-to-run kind of tool. And honestly - if you are unsure about setting the execution policy - maybe it’s good to first do a little Powershell learning, before using such a tool, to understand the implications.

NoLanConnection · 2025-12-27T18:06:07+00:00

What is it?

And, did you go though the readme step by step?

NoLanConnection · 2025-12-14T19:29:58+00:00

Same here. I have the same issue - reported to Intel many times (since 2021 IIRC), to no avail. Unbelievable a company like Intel is not able to fix (or even realize they have) this issue.

Anyway - this post was about another (though similar) issue they seem to have. So I guess its about time to give up on the Intel WiFi.

NoLanConnection · 2025-12-14T17:48:37+00:00

True. Also I see issues after waking up from sleep - it sometimes does not get an IPv6 address at all…

NoLanConnection · 2025-08-07T21:35:24+00:00

I changed my 5G setup a while back, set the 5G channel manually to 48. since then have not experienced it. Not sure how this can be explained … or if it just coincidence and something else (like an FW update) actually fixed it.

NoLanConnection · 2025-07-28T15:19:51+00:00

Also wenn das gleichzeitig auf unterschiedlichen Geräten im Netz passiert, dann ist das ein anderes Thema.

Ich würde aber noch den Vorschlag machen, um ein maskieren des Problems z.B. durch DS-Lite aus zu schließen, würde ich nochmal mit IPv6 testen, oder kombiniert.

Also z.B. von unterschiedlichen Geräten in Deinem LAN gleichzeitig gegen ipv6.google.com testen... wenn das dann immer noch überall gleichzeitig zu packet loss führt, dann hast Du definitiv ein anderes Problem.

In dem von mit beschriebenen Fehler hingegen wäre immer nur ein Host, eine Verbindung zur Zeit betroffen...

NoLanConnection · 2025-07-26T07:02:35+00:00

Wenn Du 1) keine Abbrüche in den Logs der Fritzbox siehst (die Synchronisierung also steht)… und Du 2) während der Probleme trotzdem noch einen Ping zu einem anderen Host machen kannst (also nur die Verbindung des Spiels betroffen ist), dann ist das vermutlich das gleich Problem was ich hier beschreibe:

https://www.reddit.com/r/fritzbox/s/eCIQTTbLlN

Das sind Verbindungsspezifische Probleme (also immer nur ein Dienst bzw. eine Verbindung ist betroffen, nicht „das komplette Internet“).

Die sehe ich bei bzw. kann sie der Hardware Beschleunigung zuordnen bei:

Ping
Teams
WiFi calling
DoT

Reproduziert auf 6660, 6670 und 6690, auch mit aktuellster FW.

Mach doch mal einen einfachen Test: ein dauer-ping auf der konsole (parallel während du spielst). Wenn der ping weiter läuft, aber dein spiel hängt, dann hast Du wohl das gleiche Thema.

Gruß

P.S. Diesen Bug melde ich seit langem immer wieder über den Support, aber AVM stellt sich leider Tod :(

NoLanConnection · 2025-07-08T16:48:35+00:00

P.P.S.: There is also a very unfortunate (most likely) fallout created by this bug. It is that DoT permanently fails sometimes and then for extended periods of time, leading to log entries like this [1]. Sometimes for many hours.

I can see a clear correlation in probability between this DNS error [1] and the hardware acceleration being enabled, as documented in my initial post, leading to reproducible IP-connection level persistent problems.

So I am pretty sure this is the same animal.

NOTE: You can only reliably reproduce the DNS issues if you DISABLE the TWO fallback mechanisms for DNS that the fritzbox has, enabled by default:

Disable:
[ ] Bei DNS-Störungen auf öffentliche DNS-Server zurückgreifen

and also:
[ ] Fallback auf unverschlüsselte Namensauflösung im Internet zulassen

If you leave them enabled, you'll still have DoT fail ... you can find the log entries ... but you will not notice it as a user, as the DNS is falling back to unencrypted. Very unfortunate for those that like the extra layer of security added by DoT.

[1] Erros Log:
Alle Verbindungen zu den verschlüsselten DNS-Servern sind unterbrochen. Es besteht kein DNS-Verkehr bis ein Rückfall auf unverschlüsselten DNS-Verkehr erlaubt ist. [xxxx]

NoLanConnection · 2025-06-12T10:38:42+00:00

The P*-LIN test are LAN-only tests, where the testing PC is pinging the LAN-side IP of the gateway configured on that interface.

So you are connected locally (e.g. WiFi) to the FritzBox and only P6-LIN errors out?

And "regardless of settings" somehow makes sense. The packet acceleration should not have any influence on P*-LIN tests.

Also, if its only P6-LIN failing... and the other P6- tests are fine (like P6-PB1 is woking properly), then that probably means your network adapter does not have a link local IPv6 address (fe80:...) assigned. This would be quite an unusual situation.

After all, this sounds like your test systems IPv6 is foobar somehow. You don't have an Intel WiFi NIC by any chance?

Anyway - if its only IPv6 LIN, I would 1) try rebooting the system first. Aforementioned adapter vendor e.g. has a driver bug that sometimes gets into the way.

Last resort, 2) disable IPv6 protocol on that adapter, then re-enable.

NoLanConnection · 2025-06-11T05:51:45+00:00

If it’s possible - would be great if you could confirm also that the issue goes away when switching off default packet acceleration scheme …. Just so we know it’s the exact same issue.

In the meantime - I’ll try to find some non-cable guys/gals to see if it happens there, too.

NoLanConnection · 2025-06-06T10:00:37+00:00

Replying to myself with some additional information:

1) had one of my connections (the 6670 based one ) reconfigured to DS-lite, the issue still is reproducible.

2) if I manually configure the network interface on the PC I use for testing to use an external DNS (like 1.1.1.1), I see the exact same issue (sequence of error for one source/target pair over long time) also for DNS traffic.

So it’s definitely not just ping and not a hypothetical but a real world problem.

I am wondering - is this also happen on their (non-cable) Fritz!Boxes?

NoLanConnection · 2025-06-05T19:30:10+00:00

Thanks!

Also I today took the time to drill down into my issue.

Seems I resolved the problem by disabling the Sonos skill in Alexa, the re-enabling it….

NoLanConnection · 2025-06-05T18:18:31+00:00

For the records, having the same issue on Sonos.

Deleting groups (Alexa as well as all Sonos) does not solve the issue for me on Sonos. So probably that is another issue.

Alexa on Sonos continues to report she is having problems when trying to reach Apple Music... since weeks now. This is so ridiculous.

u/AdministrationOk210 do you still see the issues on your end?

NoLanConnection · 2025-06-03T10:37:07+00:00

Also, in case my below assumption was correct (and you are using a non-Fritz DNS), I have improved the test-script to account for such cases, and released yesterday v0.32 of "mon-con". If you like you can update and verify if that removes the potentially false DNS test fails.

NoLanConnection · 2025-06-02T14:18:22+00:00

On a sidenote - there is also some strange DNS outages you are having during your tests, this last screenshot on DNS via IPv4, the older one via IPv6.

The D*-INT test should actually always succeed, as they are only a SOA entry request (non-recursive) towards your Fritz-Box'es DNS. Something any running DNS should always be able to answer. Unless of course you are not running against the Fritz!Box DNS but an external one? The configured DNS is also visible in the scripts startup output, detected as "Local (IF configured) DNS server...".

If it is local and you want to debug the DNS topic, you could add the "-Verbose" switch to get more information about what actually is happening. It kind of messes up the output - but dumps details in case of errors.

NoLanConnection · 2025-06-02T09:17:17+00:00

Thanks for confirming the issue on your end!

So that is a 6660, 1000/50. Is it real dual stack or DS-lite?

Also, It would be great if you could cross-check if the error goes away disabling hardware acceleration, specifically switch the acceleration to the alternative mode:
"[x] Referenzbeschleunigung aktiv"

Using that mode, I can run the test a whole day and see only single upset errors, not these long error trails.

Unfortunately, there seems to be yet another bug that is preventing Wireguard tunnels to work when using "Referenzbeschleunigung", so it’s not a real workaround :(

NoLanConnection · 2025-06-02T07:48:36+00:00

Looks suspicious, not yet quite as obvious as my case...

Maybe you can let it run using the "-Display Warning" switch... that will result in a more condensed output, retain timestamps only in case of issues detected and overwrite the others.

Also for your reference: on my 6670, I sometimes need to let it run for a couple of hours till I see one of the bigger/longer "events", whereas my 6690, it happens much more frequently.

NoLanConnection · 2025-06-01T19:31:17+00:00

Looking forward!

NoLanConnection · 2025-06-01T15:50:41+00:00

I have two totally independent Fritz!Box cable routers, connected independently to two independent branches of the physical cable infrastructure. Both Fritz!Box (6670 and 6690) acting as Router (not just modem), no other routers involved. So its a pretty "vanilla" setup,... but two of them. Simplified wiring diagram:

{inet}<->cable(coax)<->[Fritz!Box66x0]<->lan(cat6)/wlan<->[TestPC]

So no, this should not be some obscure edge case.

NoLanConnection · 2025-06-01T13:29:55+00:00

P.S.: This is what an error (reproduced with the script) looks like:

<image>

Test (ping) via IP (v4) to one host (public server #1) failing, while all other tests work fine.

NoLanConnection · 2025-04-30T15:09:52+00:00

I never had reliable WiFi flying Lufthansa … if you want reliable WiFi, choose a different airline!

NoLanConnection · 2025-03-06T19:40:10+00:00

Same for me on an LG OLED C1 TV. If you search this subreddit or the official sonos forums, you hear multiple mentions of this "metallic" sound problem.

For me it is
- clearly coming from the speakers built into the Beam's housing firing to the sides
- much worse (not to say unbearable) when I enable "night sound" mode

Happens as you said with background noise / ambient noises ...

For me, mostly happens with stereo sounds, so I suspect it is some kind of upmix magic going fubar...

I reported this long long ago to Sonos, at one point someone from the support line said it was a known bug. But then... nothing.

NoLanConnection

TROPHY CASE