Erroneous reporting of failing connection

[RSirois]

Erroneous reporting of failing connection

[schorschii]

Please concretize the "connectivity issue". What exactly does the desktop notification show? (Please enable the desktop notification for debugging, if you don't have it already.)

[RSirois]

It shows output of a ping command and it says it failed and the desklet changes from green to red Best regards, Randy Sirois

…

On Fri, Jan 26, 2024 at 12:19 Georg Sieber ***@***.***> wrote: Please concretize the "connectivity issue". What exactly does the desktop notification show? (Please enable the desktop notification for debugging, if you don't have it already.) — Reply to this email directly, view it on GitHub <#1041 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKMA6GWBC5UNA356ZSPUSH3YQQFWZAVCNFSM6AAAAABCMU2226VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJSGY2DINBTGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[schorschii]

So the exact output of this ping command on the desktop notification would be interesting... As soon as this output reports a packet loss greater than 0%, the desklet says "CRIT". So I think you actually have short network dropouts since I'm not able to reproduce this behavior. It's not that unusual when using WiFi.

Have you looked what statistics your separate ping command in the terminal reports after exiting it with Ctrl+C? Surely it reports a small packet loss >0% too.

[RSirois]

0% from a running ping If it happens frequently in WiFi, which is what most people use, then it is useless Best regards, Randy Sirois

…

On Sat, Jan 27, 2024 at 04:04 Georg Sieber ***@***.***> wrote: So the exact output of this ping command on the desktop notification would be interesting... As soon as this output reports a packet loss greater than 0%, the desklet says "CRIT". So I think you actually have short network dropouts since I'm not able to reproduce this behavior. It's not that unusual using WiFi. Have you looked what your separate ping command in the terminal says after exiting it with Ctrl+C? Surely it reports a small packet loss >0% too. — Reply to this email directly, view it on GitHub <#1041 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKMA6GW5XZEKBZNW3AFEBBDYQTUMJAVCNFSM6AAAAABCMU2226VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGEZTKNBQHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[schorschii]

then it is useless

Wow, what kind words. So how would you design a ping check to be "useful"??

[RSirois]

Georg, I do like this desklet. However, it reports a different result than a running Debian ping. The Debian ping shows zero loss of response during the entire time that the desklet reports there is no response. The desklet should report accurate results. Randy From: Georg Sieber ***@***.***> Sent: Monday, January 29, 2024 6:15 AM To: linuxmint/cinnamon-spices-desklets ***@***.***> Cc: RSirois ***@***.***>; Author ***@***.***> Subject: Re: [linuxmint/cinnamon-spices-desklets] Erroneous reporting of failing connection (Issue #1041) then it is useless Wow, what kind words. So how would you design a ping check to be "useful"?? — Reply to this email directly, view it on GitHub <#1041 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKMA6GQMNUFDQHFURCLMF3TYQ6VFHAVCNFSM6AAAAABCMU2226VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJUG44DAMZRG4> . You are receiving this because you authored the thread. <https://github.com/notifications/beacon/AKMA6GVHRAHCRSW4FBXNUSDYQ6VFHA5CNFSM6AAAAABCMU2226WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTSEE5J2.gif> Message ID: ***@***.*** ***@***.***> >

[schorschii]

I don't know @RSirois . As you see in the notification output, it internally uses the normal ping command line. Since you are the only one reporting this issue and there is no idea how to improve it, I think this issue should be closed.

[RSirois]

Ok thanks Best regards, Randy Sirois

…

On Thu, Feb 8, 2024 at 10:52 Georg Sieber ***@***.***> wrote: I don't know @RSirois <https://github.com/RSirois> . As you see in the notification output, it internally uses the normal ping command line. Since you are the only one reporting this issue and there is no idea how to improve it, I think this issue should be closed. — Reply to this email directly, view it on GitHub <#1041 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKMA6GQSSUEJZWVPL2VGT5DYSUNILAVCNFSM6AAAAABCMU2226VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZUG42DGOBXGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[zhurin]

Since you are the only one reporting this issue and there is no idea how to improve it, I think this issue should be closed.

Hi @schorschii he's not alone. After encountering the same false positives running multiple versions of Linux Mint and double-checking via CLI ping, the multiple hosts of ping.pe, and external server monitoring that the server(s) are reachable, I came here and found this issue.

The similarity in my case is that my laptop is also connected via Wi-Fi. After reading the comments thus far, I took a closer look at recent false positive notifications and they all report a ping time exceeding 1000 ms. What timeout, if any, does the desklet use and can it be adjusted for testing purposes? I'd like to try a silly long timeout and see if it makes any difference.

[schorschii]

I took a closer look at recent false positive notifications and they all report a ping time exceeding 1000 ms.

@zhurin OK, that's an indication. You can adjust the timeout in

cinnamon-spices-desklets/hostcheck@schorschii/files/hostcheck@schorschii/desklet.js

Line 103 in 8abfa49

['/bin/ping', this.host, '-c1', '-w2'], /*argv*/

for testing purposes. It's currently set to 2 seconds which is already quite long for a ping.

[zhurin]

Thanks for the quick reply. I agree that 2 seconds should be plenty, but at least it's something to take a look at. Since what I saw for each failed ping was a time of 1000 ± 20 ms, the current timeout shouldn't be the issue, but I'll try it anyway and see what happens.

Since this issue is sporadic, if the timeout change works, I'll probably keep it for a while to ensure that the resulting lack of false positives isn't just random. Stay tuned...