Beiträge von rpi444

    ..., da das System ja nicht komplett abstürzt, aber eher einfriert und manchmal wieder auftaut.

    Wie ist jetzt die Ausgabe von:

    Code
    1. sysctl net.ipv4.tcp_abort_on_overflow

    ?


    Kannst Du von einem anderen Gerät in deinem (W)LAN, einen arping auf den "abgestürzten" PI oder auf den eingefrorenen PI machen?

    Code
    1. sudo arping -c 3 -I <Interface> -s <IP-Adresse-Interface> <IP-Adresse-PI>

    (ohne spitze Klammern).


    EDIT:


    BTW: Ich habe auch einem PI 3B, bei dem ich mit Datenübertragung per ssh oder per telnet-ssl, das temporäre "Einfrieren" des PI3B provozieren und reproduzieren kann. Im temporär "eingefrorenen" Zustand sieht der arping dann so:

    Code
    1. :~$ sudo arping -c 3 -I wlan1 -s 192.168.178.22 192.168.178.43
    2. ARPING 192.168.178.43 from 192.168.178.22 wlan1
    3. Unicast reply from 192.168.178.43 [B8:27:EB:A8:6A:64] 6.673ms
    4. Unicast reply from 192.168.178.43 [B8:27:EB:A8:6A:64] 931.556ms
    5. Unicast reply from 192.168.178.43 [B8:27:EB:A8:6A:64] 9.553ms
    6. Unicast reply from 192.168.178.43 [B8:27:EB:A8:6A:64] 932.312ms
    7. Unicast reply from 192.168.178.43 [B8:27:EB:A8:6A:64] 6.419ms
    8. Unicast reply from 192.168.178.43 [B8:27:EB:A8:6A:64] 932.044ms
    9. Sent 3 probes (1 broadcast(s))
    10. Received 6 response(s)

    aus. Mit icmp, tcp, udp ist mein PI3b im temporär "eingefrorenen" Zustand nicht erreichbar.

    Ausgabe von den Befehlen:

    Code
    1. pi@raspberrypi:~ $ mtr -4nr -T -i 2 -c 2 -a $(hostname -I | awk {'print $1'}) -P 80 69.172.201.153
    2. Start: Sun Jun 3 19:05:12 2018

    Hast Du evtl. nicht lange genug gewartet oder keine weitere Ausgabe bekommen?


    Versuch mal mit einer Seite die per IPv4 erreichbar ist. Z. B.:

    Code
    1. mtr -4nr -T -i 2 -c 2 -a 192.168.2.155 -P 80 heise.de

    ... mit Chromium bestimmte Webseiten nicht aufrufen kann.

    z.B. raspberry.org

    Ist das nur mit dem Chromium so? Wie sind z. Zt. auf deinem PI, die Ausgaben von:

    Code
    1. nc -zv raspberry.org 80 443
    2. mtr -4nr -c 2 -i 2 104.28.21.67
    3. mtr -4nr -c 2 -i 2 69.172.201.153

    ? Hast Du evtl. einen "DS-lite"-Internetanschluss, bei einem Kabelprovider?

    Ich will definitiv nicht das per DHCP die Statische IP-Adresse verandert wird.


    Ich verstehe das so, die statische IP-Adresse, die ich in der Schock.conf angebe wird verwendet wenn kein Server vorhanden ist. Sobald ein DHCP-Server im Netzwerk vorhanden ist würde dieser dem Client eine Ip zuweisen und die statisch eingestellte überschreiben. Richtig?

    Nein, denn für den Fall, dass kein dhcp-Server erreicht werden kann, wird ein fall-back-Profil benötigt.


    Aber wenn Du kein dhcp haben willst, muss das ja nicht weiter diskutiert werden.

    Jetzt meine Frage, ist dadurch automatisch DHCP auf dem konfigurierten Interface deaktiviert oder muss ich das noch irgendwo deaktivieren?


    In einigen Posts gehts auch darum diesen dienst zu deaktivieren und nach alter Struktur zu konfigurieren. Was haltet ihr davon?

    Wenn Du das mit dem dhcpcd-daemon machst, dann darfst Du DHCP nicht deaktivieren.


    Von der alten "Struktur" (Vorgehensweise) halte ich nichts. Wenn Du es ohne DHCP haben willst, schlage ich dir systemd-networkd vor.

    Weißt du vielleicht auch, wie lange solche Adresse im Cache bleiben?

    Das kann man konfigurieren. Beim dnsmasq mit z. B:

    Zitat

    --max-cache-ttl=<time>Set a maximum TTL value for entries in the cache.


    --min-cache-ttl=<time>Extend short TTL values to the time given when caching them. Note that artificially extending TTL values is in general a bad idea, do not do it unless you have a good reason, and understand what you are doing. Dnsmasq limits the value of this option to one hour, unless recompiled.

    Wie bringe ich den Pi dazu, das WLAN bei aktiver LAN-Verbindung zu deaktivieren? Es wäre schön, wenn man es nicht dauerhaft deaktivieren möchte, um im Bedarfsfall bei gezogenem LAN-Kabel auf das WLAN automatisch umschaltet.

    Da hast Du mehrere Möglichkeiten. Z. B. ifplugd oder einen cronjob oder eine timer unit/service unit.

    Dass quasi PiHole intern ein Liste hinterlegt, mit den Namen und der dazugehörigen IP und bei einem erneuten Aufruf er es direkt aus dem Cache holen kann und nicht erst "im Internet" anfragen muss?

    Das kannst Du testen bzw. feststellen (mit der "query time"). Z. B. nicht im dns-cache:

    Code
    1. :~$ dig whitehouse.gov | grep msec -A1
    2. ;; Query time: 115 msec
    3. ;; SERVER: 127.0.0.1#53(127.0.0.1)

    und hier im dns-cache:

    Code
    1. :~$ dig whitehouse.gov | grep msec -A1
    2. ;; Query time: 0 msec
    3. ;; SERVER: 127.0.0.1#53(127.0.0.1)

    ..., nur das was ich eigentlich sehen wollte rtsplaneta.rs bleibt Schwarz. Wo liegt da das Problem? Ist das auch dieses Video on Demand wie bei Netflix.

    Kannst Du die Port 80 und 443 erreichen?

    Code
    1. nc -zv rtsplaneta.rs 443
    2. nc -zv rtsplaneta.rs 80

    Das ist m. E. ein MM-Angebot (per Internet) des öffentlichen Rundfunks von Serbien.

    Aus welchem Land versuchst Du?

    ... wenn im tagesbetrieb nur die Hälfte ankommt?

    Versuch mal auf deinem PI einen tatsächlichen Download (d. h. nicht nach /dev/null) per _ftp_ auf den Datenträger und danach mit diesem tool (axel), zwischen deinen Geräten per ftp:

    Code
    1. sudo apt-get install axel
    2. axel -a -n 5 ftp://mirror.de.leaseweb.net/speedtest/1000mb.bin
    3. rm 1000mb.bin