Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #115602 > unrolled thread

wlan hängt (manchmal)

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  wlan hängt (manchmal) Jan Novak <repcom@gmail.com> - 2021-03-14 07:13 +0100
    Re: wlan hängt (manchmal) Tim Ritberg <tim@server.invalid> - 2021-03-14 11:41 +0100
      Re: wlan hängt (manchmal) Jan Novak <repcom@gmail.com> - 2021-03-15 07:47 +0100
        Re: wlan hängt (manchmal) Andreas Kohlbach <ank@spamfence.net> - 2021-03-15 11:27 -0400
    Re: wlan hängt (manchmal) Andreas Kohlbach <ank@spamfence.net> - 2021-03-14 11:36 -0400
      Re: wlan hängt (manchmal) Jan Novak <repcom@gmail.com> - 2021-03-15 07:46 +0100
        Re: wlan hängt (manchmal) Andreas Kohlbach <ank@spamfence.net> - 2021-03-15 11:24 -0400
          Re: wlan hängt (manchmal) Jan Novak <repcom@gmail.com> - 2021-03-16 08:23 +0100
            Re: wlan hängt (manchmal) Andreas Kohlbach <ank@spamfence.net> - 2021-03-16 07:36 -0400
              Re: wlan hängt (manchmal) Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-03-16 11:59 +0000
                Re: wlan hängt (manchmal) Andreas Kohlbach <ank@spamfence.net> - 2021-03-16 11:02 -0400
                  Re: wlan hängt (manchmal) Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-03-16 15:39 +0000
              Re: wlan hängt (manchmal) Jan Novak <repcom@gmail.com> - 2021-03-16 13:21 +0100
            Re: wlan hängt (manchmal) Bernd Mayer <beam.bam.boom@knuut.de> - 2021-03-16 15:20 +0100
              Re: wlan hängt (manchmal) Jan Novak <repcom@gmail.com> - 2021-03-16 15:58 +0100
    Re: wlan hängt (manchmal) Joerg <news@analogconsultants.com> - 2021-03-16 09:27 -0700
      Re: wlan hängt (manchmal) Jan Novak <repcom@gmail.com> - 2021-03-17 07:24 +0100
        Re: wlan hängt (manchmal) Joerg <news@analogconsultants.com> - 2021-03-17 13:16 -0700
          Re: wlan hängt (manchmal) Kay Martinen <usenet@martinen.de> - 2021-03-17 22:22 +0100
            Re: wlan hängt (manchmal) Joerg <news@analogconsultants.com> - 2021-03-17 15:18 -0700
              Re: wlan hängt (manchmal) [OT] Joerg <news@analogconsultants.com> - 2021-03-17 15:55 -0700
              Re: wlan hängt (manchmal) Joerg <news@analogconsultants.com> - 2021-03-18 15:19 -0700
                Re: wlan hängt (manchmal) Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-03-19 21:35 +0100
                  Re: wlan hängt (manchmal) Joerg <news@analogconsultants.com> - 2021-03-19 15:21 -0700
                    Re: wlan hängt (manchmal) Andreas Kohlbach <ank@spamfence.net> - 2021-03-20 03:46 -0400
                      Re: wlan hängt (manchmal) Joerg <news@analogconsultants.com> - 2021-03-21 11:46 -0700
                        Re: wlan hängt (manchmal) Andreas Kohlbach <ank@spamfence.net> - 2021-03-21 17:23 -0400
                          Re: wlan hängt (manchmal) Joerg <news@analogconsultants.com> - 2021-03-22 13:02 -0700
                            Re: wlan hängt (manchmal) Kay Martinen <usenet@martinen.de> - 2021-03-22 21:41 +0100
                            Re: wlan hängt (manchmal) Andreas Kohlbach <ank@spamfence.net> - 2021-03-22 18:21 -0400
                    Re: wlan hängt (manchmal) Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-03-20 20:54 +0100
              Re: wlan hängt (manchmal) Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-03-18 20:46 +0100
                Re: wlan hängt (manchmal) Enrik Berkhan <Enrik.Berkhan@inka.de> - 2021-03-18 22:25 +0000
                  Re: wlan hängt (manchmal) Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-03-19 21:08 +0100
                    Re: wlan hängt (manchmal) Enrik Berkhan <Enrik.Berkhan@inka.de> - 2021-03-20 11:22 +0000
                      Re: wlan hängt (manchmal) Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-03-20 20:59 +0100
                Re: wlan hängt (manchmal) Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-19 12:17 +0100
                  Re: wlan hängt (manchmal) Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-03-19 21:12 +0100
            Re: wlan hängt (manchmal) Andreas Kohlbach <ank@spamfence.net> - 2021-03-17 18:28 -0400
              Reboot-Verhalten unattended-upgrades (was: wlan hängt (manchmal)) Thomas Stein <tstein@tstein.net> - 2021-03-18 08:38 +0100
                Re: Reboot-Verhalten unattended-upgrades Andreas Kohlbach <ank@spamfence.net> - 2021-03-18 18:34 -0400
                  Re: Reboot-Verhalten unattended-upgrades Thomas Stein <tstein@tstein.net> - 2021-03-22 10:49 +0100
                    Re: Reboot-Verhalten unattended-upgrades Andreas Kohlbach <ank@spamfence.net> - 2021-03-22 14:00 -0400
            Re: wlan hängt (manchmal) Jan Novak <repcom@gmail.com> - 2021-03-18 07:14 +0100
          Re: wlan hängt (manchmal) Helmut Waitzmann <nn.throttle@xoxy.net> - 2021-03-17 23:42 +0100
            Re: wlan hängt (manchmal) Joerg <news@analogconsultants.com> - 2021-03-17 15:52 -0700
    Re: wlan hängt (manchmal) Bernd Mayer <beam.bam.boom@knuut.de> - 2021-03-16 17:45 +0100
      Re: wlan hängt (manchmal) Jan Novak <repcom@gmail.com> - 2021-03-17 07:25 +0100

Page 1 of 3  [1] 2 3  Next page →

#115602 — wlan hängt (manchmal)

Hallo,

auf einem debian 10 Notebook, welches per WLAN verbunden ist, hängt das 
Wlan manchmal.

PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=227 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.38 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=87.9 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.917 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=169 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1.01 ms

Manchmal schwankt die Pingzeit zwischen den einzelnen Pings auch bis zu 
3000ms.

Mit einem Neustart oder auch nur einem deaktivieren und wieder 
aktivieren des WLAN's ist wieder alles ok.

Es läuft quasi nichts. Alle Loads sind bei ~0, netstat zeigt nichts 
auffälliges, ps auch nicht. Platte hat nichts zu tun. System ist up to date.

Jan

[toc] | [next] | [standalone]

#115608

Am 14.03.21 um 07:13 schrieb Jan Novak:
> Hallo,
> 
> auf einem debian 10 Notebook, welches per WLAN verbunden ist, hängt das 
> Wlan manchmal.
> 
> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=227 ms
> 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.38 ms
> 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=87.9 ms
> 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.917 ms
> 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=169 ms
> 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1.01 ms
> 
> Manchmal schwankt die Pingzeit zwischen den einzelnen Pings auch bis zu 
> 3000ms.
> 
> Mit einem Neustart oder auch nur einem deaktivieren und wieder 
> aktivieren des WLAN's ist wieder alles ok.

Zuviel "Auto-Kanal"?
Was hast du denn für Nachbarn? :-D

Tim

[toc] | [prev] | [next] | [standalone]

#115642

Am 14.03.21 um 11:41 schrieb Tim Ritberg:
> Am 14.03.21 um 07:13 schrieb Jan Novak:
>> Hallo,
>>
>> auf einem debian 10 Notebook, welches per WLAN verbunden ist, hängt 
>> das Wlan manchmal.
>>
>> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
>> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=227 ms
>> 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.38 ms
>> 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=87.9 ms
>> 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.917 ms
>> 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=169 ms
>> 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1.01 ms
>>
>> Manchmal schwankt die Pingzeit zwischen den einzelnen Pings auch bis 
>> zu 3000ms.
>>
>> Mit einem Neustart oder auch nur einem deaktivieren und wieder 
>> aktivieren des WLAN's ist wieder alles ok.
> 
> Zuviel "Auto-Kanal"?
> Was hast du denn für Nachbarn? :-D

aber dann würde ja ein wifa an/aus (am Notebook) keinen Unterschied 
machen sollen. Ist es aber. Danach ist die Verbindung einwandfrei.

Jan

[toc] | [prev] | [next] | [standalone]

#115655

On Mon, 15 Mar 2021 07:47:25 +0100, Jan Novak wrote:
>
> Am 14.03.21 um 11:41 schrieb Tim Ritberg:
>
>> Zuviel "Auto-Kanal"?
>> Was hast du denn für Nachbarn? :-D
>
> aber dann würde ja ein wifa an/aus (am Notebook) keinen Unterschied
> machen sollen. Ist es aber. Danach ist die Verbindung einwandfrei.

Vielleicht hast Du das Problem damit Deinem Nachbarn übertragen. Der
hatte darauf bei sich aus/an gemacht, um Dir das Problem
zurückzugeben. ;-)

Ich habe hier geschaut, welcher Kanal am seltensten genutzt wird. Die
meisten anderen (meiner zuerst auch!) "intelligenten" Router meinte, Kanal 11
sei der beste. Fast alle anderen! Habe meinen dann auf 4 gesetzt. Hatte
sonst niemand.
-- 
Andreas

PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0

[toc] | [prev] | [next] | [standalone]

#115612

On Sun, 14 Mar 2021 07:13:40 +0100, Jan Novak wrote:
>
> auf einem debian 10 Notebook, welches per WLAN verbunden ist, hängt
> das Wlan manchmal.
>
> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=227 ms
> 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.38 ms
> 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=87.9 ms
> 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.917 ms
> 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=169 ms
> 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1.01 ms

Sieht IMO gut aus, auch wenn es stark (in kleinen Zahlen) schwankt

> Manchmal schwankt die Pingzeit zwischen den einzelnen Pings auch bis
> zu 3000ms.
>
> Mit einem Neustart oder auch nur einem deaktivieren und wieder
> aktivieren des WLAN's ist wieder alles ok.
>
> Es läuft quasi nichts. Alle Loads sind bei ~0, netstat zeigt nichts
> auffälliges, ps auch nicht. Platte hat nichts zu tun. System ist up to
> date.

Interessanter dürften Logs sein. Falls wie hier syslogd läuft, kannst Du
als root nebenher

tail -f /var/log/syslog

laufen lassen. Wenn es dann wieder hängt, schnell auf diese Anzeige
wechseln, ob sich Interessantes tut.

Wenn es aber nicht wirklich mehrere Sekunden hängt, würde ich das
ignorieren.

Ich hatte das auch so ähnlich, als ich noch über WIFI rein ging. Nicht
dass es störte. Mir fiel aber auch, dass es weg war, als ich über Kabel
(Ethernet) in Internet ging.
-- 
Andreas

[toc] | [prev] | [next] | [standalone]

#115641

> On Sun, 14 Mar 2021 07:13:40 +0100, Jan Novak wrote:
>> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
>> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=227 ms
>> 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.38 ms
>> 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=87.9 ms
>> 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.917 ms
>> 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=169 ms
>> 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1.01 ms
> 
> Sieht IMO gut aus, auch wenn es stark (in kleinen Zahlen) schwankt

Nach einem Wifi an/aus ist es aber einwandfrei immer ~1ms


>> Manchmal schwankt die Pingzeit zwischen den einzelnen Pings auch bis
>> zu 3000ms.

> Interessanter dürften Logs sein. Falls wie hier syslogd läuft, kannst Du
> als root nebenher
> tail -f /var/log/syslog
> laufen lassen. Wenn es dann wieder hängt, schnell auf diese Anzeige
> wechseln, ob sich Interessantes tut.

hmm... kucke ich mal, denke da wird sich aber nicht viel tun.

> 
> Wenn es aber nicht wirklich mehrere Sekunden hängt, würde ich das
> ignorieren.

Manachmal ist eine Arbeiten nicht möglich wiel die Netzwerkverbindung so 
langsam ist.

> 
> Ich hatte das auch so ähnlich, als ich noch über WIFI rein ging. Nicht
> dass es störte. Mir fiel aber auch, dass es weg war, als ich über Kabel
> (Ethernet) in Internet ging.

ist für dieses Notebook - an diesem Ort - nicht möglich.


Jan

[toc] | [prev] | [next] | [standalone]

#115654

On Mon, 15 Mar 2021 07:46:23 +0100, Jan Novak wrote:
>
>> On Sun, 14 Mar 2021 07:13:40 +0100, Jan Novak wrote:
>>> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
>>> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=227 ms
>>> 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.38 ms
>>> 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=87.9 ms
>>> 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.917 ms
>>> 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=169 ms
>>> 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1.01 ms
>> Sieht IMO gut aus, auch wenn es stark (in kleinen Zahlen) schwankt
>
> Nach einem Wifi an/aus ist es aber einwandfrei immer ~1ms

Ich hatte die 192.168.1.1 überlesen/ignoriert. Ich pinge meist "was
draußen", gerne auch mit Namen umzusehen, ob auch DNS mal wieder
hakt. Dabei bekomme ich ähnliche Werte.

>>> Manchmal schwankt die Pingzeit zwischen den einzelnen Pings auch bis
>>> zu 3000ms.
>
>> Interessanter dürften Logs sein. Falls wie hier syslogd läuft, kannst Du
>> als root nebenher
>> tail -f /var/log/syslog
>> laufen lassen. Wenn es dann wieder hängt, schnell auf diese Anzeige
>> wechseln, ob sich Interessantes tut.
>
> hmm... kucke ich mal, denke da wird sich aber nicht viel tun.

Hier war (ist es wohl noch; aber egal, da ich kein WIFI mehr nutze) der
NetworkManager meist gerade mit dem Neuaushandeln der Verbindung
beschäftigt, wenn es bei mir auftrat. Das steht im Log.

>> Wenn es aber nicht wirklich mehrere Sekunden hängt, würde ich das
>> ignorieren.
>
> Manachmal ist eine Arbeiten nicht möglich wiel die Netzwerkverbindung
> so langsam ist.

Antwortzeit oder (und) Geschwindigkeit?

>> Ich hatte das auch so ähnlich, als ich noch über WIFI rein
>> ging. Nicht
>> dass es störte. Mir fiel aber auch, dass es weg war, als ich über Kabel
>> (Ethernet) in Internet ging.
>
> ist für dieses Notebook - an diesem Ort - nicht möglich.

IIRC ist meines 12 Meter lang. War es mir aber wert. *g*
-- 
Andreas

PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0

[toc] | [prev] | [next] | [standalone]

#115695

> On Mon, 15 Mar 2021 07:46:23 +0100, Jan Novak wrote:
>>> On Sun, 14 Mar 2021 07:13:40 +0100, Jan Novak wrote:
>>>> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
>>>> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=227 ms
>>>> 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.38 ms
>>>> 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=87.9 ms
>>>> 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.917 ms
>>>> 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=169 ms
>>>> 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1.01 ms

>> Nach einem Wifi an/aus ist es aber einwandfrei immer ~1ms

Hinzuzufügen sei noch, dass es sich bei diesem Notebook um eines 
handelt, das fast immer 24/7 an ist.


> Ich hatte die 192.168.1.1 überlesen/ignoriert. Ich pinge meist "was
> draußen", gerne auch mit Namen umzusehen, ob auch DNS mal wieder
> hakt. Dabei bekomme ich ähnliche Werte.

Nach draussen ist es nicht besser. Wenn es aber schon nach Innen hakt, 
kanns nach draussen nicht besser sein. Natürlich hatte ich das auch 
versucht, mit ähnlichem Ergebniss.

> Hier war (ist es wohl noch; aber egal, da ich kein WIFI mehr nutze) der
> NetworkManager meist gerade mit dem Neuaushandeln der Verbindung
> beschäftigt, wenn es bei mir auftrat. Das steht im Log.
> 
>>> Wenn es aber nicht wirklich mehrere Sekunden hängt, würde ich das
>>> ignorieren.
>>
>> Manachmal ist eine Arbeiten nicht möglich wiel die Netzwerkverbindung
>> so langsam ist.
> 
> Antwortzeit oder (und) Geschwindigkeit?

~5000ms, Geschwindigkeit mit speedtest-cli nicht messbar, weil nach 
vielen Minuten imme rnoch kein Ergebniss kommt.



>>> Ich hatte das auch so ähnlich, als ich noch über WIFI rein
>>> ging. Nicht
>>> dass es störte. Mir fiel aber auch, dass es weg war, als ich über Kabel
>>> (Ethernet) in Internet ging.
>>
>> ist für dieses Notebook - an diesem Ort - nicht möglich.
> 
> IIRC ist meines 12 Meter lang. War es mir aber wert. *g*

Unabhängig davon, sollte das WLAN doch ordentlich funktionieren, was es 
meistens ja tut. Es macht den Eindruck, das irgendwann (das passiert ~ 1 
mal die Woche) sich irgendwas "verschluckt" und ab da gehts dann sol 
lange nicht, bis ich es resette.


Jan

[toc] | [prev] | [next] | [standalone]

#115700

On Tue, 16 Mar 2021 08:23:33 +0100, Jan Novak wrote:
>
>> On Mon, 15 Mar 2021 07:46:23 +0100, Jan Novak wrote:
>>>> On Sun, 14 Mar 2021 07:13:40 +0100, Jan Novak wrote:
>>>>> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
>>>>> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=227 ms
>>>>> 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.38 ms
>>>>> 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=87.9 ms
>>>>> 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.917 ms
>>>>> 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=169 ms
>>>>> 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1.01 ms
>
>>> Nach einem Wifi an/aus ist es aber einwandfrei immer ~1ms
>
> Hinzuzufügen sei noch, dass es sich bei diesem Notebook um eines
> handelt, das fast immer 24/7 an ist.

Hier auch, aber

s/fast//

>> Ich hatte die 192.168.1.1 überlesen/ignoriert. Ich pinge meist "was
>> draußen", gerne auch mit Namen umzusehen, ob auch DNS mal wieder
>> hakt. Dabei bekomme ich ähnliche Werte.
>
> Nach draussen ist es nicht besser. Wenn es aber schon nach Innen hakt,
> kanns nach draussen nicht besser sein. Natürlich hatte ich das auch 
> versucht, mit ähnlichem Ergebniss.

Klar.

>> Hier war (ist es wohl noch; aber egal, da ich kein WIFI mehr nutze) der
>> NetworkManager meist gerade mit dem Neuaushandeln der Verbindung
>> beschäftigt, wenn es bei mir auftrat. Das steht im Log.
>> 
>>>> Wenn es aber nicht wirklich mehrere Sekunden hängt, würde ich das
>>>> ignorieren.
>>>
>>> Manachmal ist eine Arbeiten nicht möglich wiel die Netzwerkverbindung
>>> so langsam ist.
>> Antwortzeit oder (und) Geschwindigkeit?
>
> ~5000ms, Geschwindigkeit mit speedtest-cli nicht messbar, weil nach
> vielen Minuten imme rnoch kein Ergebniss kommt.

speedtest-cli kannte ich gar nicht, wird gerade installiert. Das ganze
Web-Geraffel mit Flash (okay, mag heute node.js sein) zieht u.U. den
alten Rechner hier runter, dass der Test falsche Ergebnisse liefert.

Zeigt aber keine Ping-Werte an, wenn es

| Selecting best server based on ping...

ausgibt.

>>>> Ich hatte das auch so ähnlich, als ich noch über WIFI rein
>>>> ging. Nicht
>>>> dass es störte. Mir fiel aber auch, dass es weg war, als ich über Kabel
>>>> (Ethernet) in Internet ging.
>>>
>>> ist für dieses Notebook - an diesem Ort - nicht möglich.
>> IIRC ist meines 12 Meter lang. War es mir aber wert. *g*
>
> Unabhängig davon, sollte das WLAN doch ordentlich funktionieren, was
> es meistens ja tut. Es macht den Eindruck, das irgendwann (das
> passiert ~ 1 mal die Woche) sich irgendwas "verschluckt" und ab da
> gehts dann sol lange nicht, bis ich es resette.

Zeigt

/sbin/ifconfig

auffällig hohe Werte bei "errors" an? Hier

TX errors 59  dropped 0 overruns 0  carrier 0  collisions 0

bei ca. 100 GB Upload. "59" ist nichts. Gibt auch noch eine Zeile mit "RX".
-- 
Andreas

PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0

[toc] | [prev] | [next] | [standalone]

#115702

Andreas Kohlbach <ank@spamfence.net> wrote:

> > ~5000ms, Geschwindigkeit mit speedtest-cli nicht messbar, weil nach
> > vielen Minuten imme rnoch kein Ergebniss kommt.
> 
> speedtest-cli kannte ich gar nicht, wird gerade installiert. Das ganze
> Web-Geraffel mit Flash (okay, mag heute node.js sein) zieht u.U. den
> alten Rechner hier runter, dass der Test falsche Ergebnisse liefert.

Geht auch einfacher: http://flupp.belwue.de/tcpbm

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#115706

On Tue, 16 Mar 2021 11:59:38 +0000 (UTC), Ulli Horlacher wrote:
>
> Andreas Kohlbach <ank@spamfence.net> wrote:
>
>> > ~5000ms, Geschwindigkeit mit speedtest-cli nicht messbar, weil nach
>> > vielen Minuten imme rnoch kein Ergebniss kommt.
>> 
>> speedtest-cli kannte ich gar nicht, wird gerade installiert. Das ganze
>> Web-Geraffel mit Flash (okay, mag heute node.js sein) zieht u.U. den
>> alten Rechner hier runter, dass der Test falsche Ergebnisse liefert.
>
> Geht auch einfacher: http://flupp.belwue.de/tcpbm

Danke. Mal in meine URL-Sammlung aufgenommen.
-- 
Andreas

[toc] | [prev] | [next] | [standalone]

#115709

Andreas Kohlbach <ank@spamfence.net> wrote:

> > Geht auch einfacher: http://flupp.belwue.de/tcpbm
> 
> Danke. Mal in meine URL-Sammlung aufgenommen.

Siehe auch http://flupp.belwue.de/

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#115703

Am 16.03.21 um 12:36 schrieb Andreas Kohlbach:

> speedtest-cli kannte ich gar nicht, wird gerade installiert. Das ganze
> Web-Geraffel mit Flash (okay, mag heute node.js sein) zieht u.U. den
> alten Rechner hier runter, dass der Test falsche Ergebnisse liefert.

Stimmt. das Tool gibts schon ewig und funktioniert bestens

> Zeigt
> 
> /sbin/ifconfig
> 
> auffällig hohe Werte bei "errors" an? Hier
> 
> TX errors 59  dropped 0 overruns 0  carrier 0  collisions 0
> 
> bei ca. 100 GB Upload. "59" ist nichts. Gibt auch noch eine Zeile mit "RX".


werde ich beim nächsten mal nachschauen.

Jan

[toc] | [prev] | [next] | [standalone]

#115704

Am 16.03.21 um 08:23 schrieb Jan Novak:
>> On Mon, 15 Mar 2021 07:46:23 +0100, Jan Novak wrote:
>>>> On Sun, 14 Mar 2021 07:13:40 +0100, Jan Novak wrote:
>>>>> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
>>>>> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=227 ms
>>>>> 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.38 ms
>>>>> 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=87.9 ms
>>>>> 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.917 ms
>>>>> 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=169 ms
>>>>> 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1.01 ms
> 
>>> Nach einem Wifi an/aus ist es aber einwandfrei immer ~1ms
> 
> Hinzuzufügen sei noch, dass es sich bei diesem Notebook um eines 
> handelt, das fast immer 24/7 an ist.

Hallo,

überprüf mal die Temperaturen und kontrollier ob die Lüftung/Kühlung 
noch gut funktioniert.


Bernd Mayer

[toc] | [prev] | [next] | [standalone]

#115705

Am 16.03.21 um 15:20 schrieb Bernd Mayer:
> Am 16.03.21 um 08:23 schrieb Jan Novak:
>>> On Mon, 15 Mar 2021 07:46:23 +0100, Jan Novak wrote:
>>>>> On Sun, 14 Mar 2021 07:13:40 +0100, Jan Novak wrote:
>>>>>> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
>>>>>> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=227 ms
>>>>>> 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.38 ms
>>>>>> 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=87.9 ms
>>>>>> 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.917 ms
>>>>>> 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=169 ms
>>>>>> 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1.01 ms
>>
>>>> Nach einem Wifi an/aus ist es aber einwandfrei immer ~1ms
>>
>> Hinzuzufügen sei noch, dass es sich bei diesem Notebook um eines 
>> handelt, das fast immer 24/7 an ist.
> 
> Hallo,
> 
> überprüf mal die Temperaturen und kontrollier ob die Lüftung/Kühlung 
> noch gut funktioniert.

Danke, für den Tip. Das isses leider nicht. Vor allem: im gleichen 
Zustand innerhalb von wenigen Sekunden (nach Neustart des 
Netzwerkdienstes) läuft sofort einwandfrei.

Jan

[toc] | [prev] | [next] | [standalone]

#115714

On 3/13/21 10:13 PM, Jan Novak wrote:
> Hallo,
> 
> auf einem debian 10 Notebook, welches per WLAN verbunden ist, hängt das 
> Wlan manchmal.
> 
> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=227 ms
> 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.38 ms
> 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=87.9 ms
> 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.917 ms
> 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=169 ms
> 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1.01 ms
> 
> Manchmal schwankt die Pingzeit zwischen den einzelnen Pings auch bis zu 
> 3000ms.
> 
> Mit einem Neustart oder auch nur einem deaktivieren und wieder 
> aktivieren des WLAN's ist wieder alles ok.
> 
> Es läuft quasi nichts. Alle Loads sind bei ~0, netstat zeigt nichts 
> auffälliges, ps auch nicht. Platte hat nichts zu tun. System ist up to 
> date.
> 

Setze das Notebook probeweise ganz nahe an den WiFi Router, so 1-2m 
entfernt. Wenn das Problem dann immer noch auftritt, liegt es an Deiner 
HW/SW, wenn nicht, dann ist es ein Funkproblem aehnlich wie Andreas das 
schilderte. Damit haettest Du in Sachen Diagnose schonmal eine dicke 
Lage der Zwiebel gepellt. Ist es ein Funkproblem, koennte ich 
weiterhelfen, bei HW/SW die Linux-Experten in dieser NG.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#115730

Am 16.03.21 um 17:27 schrieb Joerg:
> On 3/13/21 10:13 PM, Jan Novak wrote:
>> Mit einem Neustart oder auch nur einem deaktivieren und wieder 
>> aktivieren des WLAN's ist wieder alles ok.
>>
>> Es läuft quasi nichts. Alle Loads sind bei ~0, netstat zeigt nichts 
>> auffälliges, ps auch nicht. Platte hat nichts zu tun. System ist up to 
>> date.
>>
> 
> Setze das Notebook probeweise ganz nahe an den WiFi Router, so 1-2m 
> entfernt. Wenn das Problem dann immer noch auftritt, liegt es an Deiner 
> HW/SW, wenn nicht, dann ist es ein Funkproblem aehnlich wie Andreas das 
> schilderte. Damit haettest Du in Sachen Diagnose schonmal eine dicke 
> Lage der Zwiebel gepellt. Ist es ein Funkproblem, koennte ich 
> weiterhelfen, bei HW/SW die Linux-Experten in dieser NG.


Es tritt ja nur 1 mal die Woche, manchmal sogar nur alle 2 Wochen auf.
Sobald es wieder soweit ist, teste ich das.


Jan

[toc] | [prev] | [next] | [standalone]

#115736

On 3/16/21 11:24 PM, Jan Novak wrote:
> Am 16.03.21 um 17:27 schrieb Joerg:
>> On 3/13/21 10:13 PM, Jan Novak wrote:
>>> Mit einem Neustart oder auch nur einem deaktivieren und wieder 
>>> aktivieren des WLAN's ist wieder alles ok.
>>>
>>> Es läuft quasi nichts. Alle Loads sind bei ~0, netstat zeigt nichts 
>>> auffälliges, ps auch nicht. Platte hat nichts zu tun. System ist up 
>>> to date.
>>>
>>
>> Setze das Notebook probeweise ganz nahe an den WiFi Router, so 1-2m 
>> entfernt. Wenn das Problem dann immer noch auftritt, liegt es an 
>> Deiner HW/SW, wenn nicht, dann ist es ein Funkproblem aehnlich wie 
>> Andreas das schilderte. Damit haettest Du in Sachen Diagnose schonmal 
>> eine dicke Lage der Zwiebel gepellt. Ist es ein Funkproblem, koennte 
>> ich weiterhelfen, bei HW/SW die Linux-Experten in dieser NG.
> 
> 
> Es tritt ja nur 1 mal die Woche, manchmal sogar nur alle 2 Wochen auf.
> Sobald es wieder soweit ist, teste ich das.
> 

Ja, sowas ist unangenehm. Wie bei meinen NAS (gehackter Pogoplug), wo 
sich das ArchLinux alle paar Wochen aufhaengt, im Log aber nichts 
verdaechtiges steht. Gerade ist es mal wieder abgekachelt. Es koennten 
elektrische oder elektromagnetische Gruende sein, zumal im Log 
vereinzelt unaufgeforderte Re-Boots stehen, doch da sucht man sich einen 
Wolf. Nervig ist, dass auch nach Absturz die gruene "Alles paletti" 
Betriebs-LED leuchtet, obwohl das Dingen voll festgefroren ist.

Bei der sich gelegentlich von selbst einschaltenden Schreibtischlampe 
meiner Frau habe ich es raus. Wenn ich auf bestimmten Frequenzen im 40m 
Band sende, geht die an.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#115737

Am 17.03.21 um 21:16 schrieb Joerg:
> On 3/16/21 11:24 PM, Jan Novak wrote:

>> Es tritt ja nur 1 mal die Woche, manchmal sogar nur alle 2 Wochen auf.
>> Sobald es wieder soweit ist, teste ich das.

Da hätte ich noch die Idee im WLAN-Router der da vermutlich involviert
ist mal zu schauen wie lange der eine IP Adresse reserviert. Also die
leasetime. Wenn die auf 1 Monat steht versucht der Client die nach 2
Wochen zu erneuern. Wenn der Router aber inzwischen neu gestartet
wurde... Oder irgendwas anderes dazwischen kam...

Man könnte die lease-dauer ja testweise mal auf wenige Stunden
einstellen und schauen ob das Problem ebenso häufiger auftritt.


> vereinzelt unaufgeforderte Re-Boots stehen, doch da sucht man sich einen

cronjob, unattended-updates?

> Wolf. Nervig ist, dass auch nach Absturz die gruene "Alles paletti"
> Betriebs-LED leuchtet, obwohl das Dingen voll festgefroren ist.

Die wird doch vermutlich hart auf AN gesetzt so bald der gestartet ist.
Schlechter Indikator so lange kein tool dauernd läuft das damit blinkt
wenn etwas NICHT mehr stimmt.

> Bei der sich gelegentlich von selbst einschaltenden Schreibtischlampe
> meiner Frau habe ich es raus. Wenn ich auf bestimmten Frequenzen im 40m
> Band sende, geht die an.

Vagabundierende HF? Antenne nicht geerdet? Vielleicht killt das auch
deinen Pogoplug. Bei einem raspi-modell reicht eine Blitzlampe. ;-)



Kay

-- 
Posted via leafnode

[toc] | [prev] | [next] | [standalone]

#115741

On 3/17/21 2:22 PM, Kay Martinen wrote:
> Am 17.03.21 um 21:16 schrieb Joerg:
>> On 3/16/21 11:24 PM, Jan Novak wrote:
> 
>>> Es tritt ja nur 1 mal die Woche, manchmal sogar nur alle 2 Wochen auf.
>>> Sobald es wieder soweit ist, teste ich das.
> 
> Da hätte ich noch die Idee im WLAN-Router der da vermutlich involviert
> ist mal zu schauen wie lange der eine IP Adresse reserviert. Also die
> leasetime. Wenn die auf 1 Monat steht versucht der Client die nach 2
> Wochen zu erneuern. Wenn der Router aber inzwischen neu gestartet
> wurde... Oder irgendwas anderes dazwischen kam...
> 
> Man könnte die lease-dauer ja testweise mal auf wenige Stunden
> einstellen und schauen ob das Problem ebenso häufiger auftritt.
> 

In Jans erstem Post sieht es aber so aus, dass die Verzoegerungen alle 
paar Millisekunden passieren.

> 
>> vereinzelt unaufgeforderte Re-Boots stehen, doch da sucht man sich einen
> 
> cronjob, unattended-updates?
> 

Es ist ArchLinux, es hat keine cron Eintraege in /etc und es kennt das 
Command crontab nicht. Muss man m.W. nachinstallieren (cronie?).

Unattended Updates kann natuerlich sein. Doch dann wuerde ich vor den 
Re-Boots je mindestens einen Eintrag dazu im Log erwarten.

Ich bin gerade runter in den Keller, weil ich dann immer einen Power 
Cycle machen muss. Als ich ankam, blinkte die Zugriffs-LED des USB 
Sticks, auf dem ArchLinux weilt, durchgehend in schneller Frequenz. 
Hoffentlich sind das keine Schreibzugriffe. Die Daten sind auf einer SD 
Card.

Diesmal kam das NAS im Terminal sehr viel anders zurueck, aber es 
funktioniert wie sonst:

$ ssh 10.0.0.54
The authenticity of host '10.0.0.54 (10.0.0.54)' can't be established.
ECDSA key fingerprint is SHA256:Y1P8iElhTm+EuI2BXVjlXAAIUMznx/kMZzAF+Nqdxeo.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.0.54' (ECDSA) to the list of known hosts.
joerg@10.0.0.54's password:



>> Wolf. Nervig ist, dass auch nach Absturz die gruene "Alles paletti"
>> Betriebs-LED leuchtet, obwohl das Dingen voll festgefroren ist.
> 
> Die wird doch vermutlich hart auf AN gesetzt so bald der gestartet ist.


Nee, sie blinkt und geht erst dann auf Dauerlicht, wenn der Pogoplug 
sich im LAN als verfuegbar meldet.


> Schlechter Indikator so lange kein tool dauernd läuft das damit blinkt
> wenn etwas NICHT mehr stimmt.
> 

Ich habe das ganz dekadent so wie in der Distro gelassen und weiss 
nicht, wie diese LED software-maessig beschickt wird.


>> Bei der sich gelegentlich von selbst einschaltenden Schreibtischlampe
>> meiner Frau habe ich es raus. Wenn ich auf bestimmten Frequenzen im 40m
>> Band sende, geht die an.
> 
> Vagabundierende HF? Antenne nicht geerdet? Vielleicht killt das auch
> deinen Pogoplug. Bei einem raspi-modell reicht eine Blitzlampe. ;-)
> 

:-)

Bis da unten im Keller ist es sehr weit von Antennen und Funkstation, 
auch gut geschirmt. Aber ... nur 2m entfernt steht mein Gaerschrank fuer 
die Hobbybrauerei und wenn bei dem der fette Kompressor anspringt ...

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web