Beiträge von rpi444

  • WLan meist unterbrochen oder nicht vorhanden

    MiB schrieb:

    Mit meinem Raspberry B3+ sitze ich direkt neben der Fritzbox, trotzdem dauert es sehr lange, bis eine Internetseite geladen wird, wenn, was meinst passiert, nicht vorher schon mit der Fehlermeldung, dass die Seite nicht erreichbar ist, abgebrochen wird. Auch Versuche, eine Systemaktualisierung zu machen, scheitern daran. Die Verbindung steht sicher, Signal ist sehr stark.

    Wie sind auf deinem PI, die Ausgaben von:

    Code
    1. iwconfig
    2. iw dev <wlan-Interface> station dump
    3. ip a
    4. route -n
    5. ip n s
    6. cat /etc/resolv.conf
    7. cat /etc/nsswitch.conf
    8. nc -zv heise.de 80 443
    9. wget -4 -c -O /dev/null http://mirror.de.leaseweb.net/speedtest/10mb.bin
    10. wget -4 -c -O /dev/null http://speedtest.wdc01.softlayer.com/downloads/test10.zip

    ?

  • LAN-WLAN Brücke (bridge) unter Raspbian einrichten

    Dann hast Du einen Fehler in deiner Konfiguration des arp-proxy, denn lt. Anleitung von framp:

    Code
    1. # Assign eth0 same IP address as wlan0 so dhcp-proxy will proxy for the same subnet

    Du kannst doch die Interfaces und das routing so konfigurieren, dass diese keine LL-IP-Adresse bekommen bzw. nicht berücksichtigen:

    Code
    1. LinkLocalAddressing=no
    2. IPv4LL=false
    3. IPv6LL=false

    bzw.:

    Code
    1. pi@raspberrypi:~ $ route -n | grep -i 169.254.0.0
    2. 169.254.0.0 - 255.255.0.0 ! 0 - 0 -

  • LAN-WLAN Brücke (bridge) unter Raspbian einrichten

    Waldemar schrieb:

    Da geht nix


    Code
    1. pi@raspberrypi:~ $ sudo arping -c 3 -I wlan0 -s 192.168.178.26 192.168.178.27
    2. ARPING 192.168.178.27 from 192.168.178.26 wlan0
    3. Sent 3 probes (3 broadcast(s))
    4. Received 0 response(s)

    Versuch mal mit konfiguriertem arp_filter in der "/etc/sysctl.conf"-Datei:

    Code
    1. net.ipv4.conf.all.arp_filter = 1
    2. net.ipv4.conf.default.arp_filter = 1
    3. net.ipv4.conf.eth0.arp_filter = 1
    4. net.ipv4.conf.wlan0.arp_filter = 1

    danach:

    Code
    1. sudo sysctl -p

    ausführen. Jetzt erneut den arping mit dem eth0-Interface ausführen:

    Code
    1. sudo arping -c 3 -I eth0 -s 192.168.178.26 192.168.178.27

    und

    Code
    1. sudo arping -c 3 -I wlan0 -s 192.168.178.26 192.168.178.27

    Die IP-Adressen evtl. anpassen, falls nicht mehr aktuell (hier .27 für Receiver und .26 für wlan0/eth0).

  • LAN-WLAN Brücke (bridge) unter Raspbian einrichten

    someone schrieb:

    ... dass das eingebaute WLAN in einer anderen Zone ist als das LAN (ähnlich wie beim TO).

    Ist das beim arp-proxy auch der Fall?


    Er könnte auch mit:

    Code
    1. sudo tcpdump -vvveni eth0 multicast

    und parallel mit:

    Code
    1. sudo tcpdump -vvveni wlan0 multicast

    auf seinem PI schauen.

    Auch wenn am eth0-Interface die multicast-Pakete gesehen werden, heißt das m. E. nicht, dass diese auch den Receiver erreichen.

  • LAN-WLAN Brücke (bridge) unter Raspbian einrichten

    Waldemar schrieb:
    Code
    1. Host is up (0.048s latency).
    3. PORT STATE SERVICE
    4. 1900/udp closed upnp
    5. MAC Address: 74:DA:38:59:BC:FE (Edimax Technology)
    7. Nmap done: 1 IP address (1 host up) scanned in 0.59 seconds



    @all

    Ich glaube wir können das Problem nun daran festmachen, dass der ARP Proxy die UDP Anfragen an dem Port 1900 nicht weiterleitet. Die Frage ist nun wie kann man den Port öffnen und kann man das überhaupt bei einem ARP Proxy?

    Warum zeigt der arp-scan die IP-Adresse (und MAC-Adresse) 192.168.178.27 deines Receivers nicht an?


    Ich denke der Receiver wird den UDP-Port 1900 evtl. (automatisch) öffnen, sobald die upnp-multicast-Pakete ihn erreicht haben. Das scheint bis jetzt aber nicht der Fall zu sein.

  • LAN-WLAN Brücke (bridge) unter Raspbian einrichten

    Waldemar schrieb:

    Es sieht so aus als ob nur der Port 80, für die Internetverbindung und Onlineradio offen ist, alle anderen (insbesondere der für dlna wichtige 1900) geschlossen sind bzw. die Verbindung wird auf diesen Port nicht weitergeleitet.


    Um nun noch mehr Verwirrung zu stiften, habe ich die Ports von dem Receiver mit nmap abgescannt - hier die entsprechende Ausgabe:



    BTW: nmap zeigt (mit "open") ob auf den Ports gelauscht wird. Der tcp-scan den Du hier gepostet hast zeigt, dass auch auf dem TCP-Port 1900 (... und nicht nur auf dem TCP-Port 80) gelauscht wird. Wenn Du den UDP-Port 1900 meinst und diesen UDP-Port scannen willst, dann mit:

    Code
    1. sudo nmap -sU 192.168.178.37 -p1900


    EDIT:


    Wenn Du arp-scan installiert hast, dann poste mal die Ausgabe von:

    Code
    1. sudo arp-scan -I wlan0 -RN -l

    und auch die Ausgaben von:

    Code
    1. sysctl net.ipv4.ip_forward
    2. sudo iptables -nvx -L


    EDIT 2:


    BTW: Statt den Receiver, könntest Du einen 2. PI an der bridge anschließen/verbinden und testen/schauen ob auf dem 2. PI die upnp-multicast-Pakete ankommen.

  • Cloud nicht von jedem Gerät aus dem Internet erreichbar

    Mario Be schrieb:

    Ich habe es vorhin mit dem DNS Rebind Schutz probiert, hat aber nichts gebracht.


    Und das hat schon damit zu tun, denn die myfritz Adresse hat ja das Gerät selber, und Domains mit der myfritz Adresse werden dann halt nicht aufgelöst.

    Nein. die myfritz-Adresse hat deine FritzBox (als border device).


    Auf welche IPv4-Adresse wird das myfritz..... aufgelöst? Einmal (im Internet) mit 1.1.1.1 als DNS-Server und einmal (in deinem WLAN) mit 192.168.178.1 als DNS-Server.

  • Cloud nicht von jedem Gerät aus dem Internet erreichbar

    Mario Be schrieb:

    Das Problem ist hier eine Sicherheitseinstellung in der FP. Ich muss die myfritz Adresse unter welcher der Pi erreichbar sein soll dort beim DNS-Rebind als Ausnahme eintragen.

    Die FB blockt alle FQDN welche aus dem Netz das eigene Netz betreffen wenn diese über das WAN kommen.

    Das könnte ein myfritz-Problem sein, kann ich aber nicht testen weil ich myfritz nicht benutze.


    Hat aber mit dem "klassischen" rebind-schutz der FB nicht zu tun, denn dort steht:

    Code
    1. DNS-Rebind-Schutz
    2. FRITZ!Box unterdrückt DNS-Antworten, die auf IP-Adressen im eigenen Heimnetz verweisen (DNS-Rebind-Schutz).

    Aber bei dir soll ja cloud.mablog.de und/oder myfritz.... nicht auf eine interne IPv4-Adresse (aus dem W/LAN dewr FB) aufgelöst werden, ... oder? Und mit der WAN-IP-Adresse der FB hat der rebind-schutz nichts zu tun.


    Mach mal von einem anderen Linux-Gerät im (W)LAN deiner FB (... ohne irgendwelche rebind-schutz-Einstellungen):

    Code
    1. nc -zv cloud.mablog.de 443
    2. nc -zv 85.13.161.214 443
    3. host -t A cloud.mablog.de
    4. host -t A cloud.mablog.de 1.1.1.1
    5. dig -x 85.13.161.214 +short @1.1.1.1
    6. dig -x 85.13.161.214 +short @192.168.178.1
    7. dig -x 85.13.161.214 +short

  • Cloud nicht von jedem Gerät aus dem Internet erreichbar

    Mario Be schrieb:

    rpi444 Der DNS löst die myfritz Adresse richtig auf.

    OK, aber ich habe nach der Auflösung von "cloud.mablog.de" und nicht nach der Auflösung der myfritz-Adresse gefragt.


    Gut, das verstehe ich jetzt so, dass die Geräte deiner Frau, z. Zt. die myfritz-Adresse im (W)LAN benutzen. Da die FritzBox NAT-Loopback (Hairpin-NAT) kann sollte es mit dem Zugriff auf das WAN-Interface der FB aus deren (W)LAN keine Probleme geben. Es sei denn, myfritz macht Probleme (btw. ich benutze myfritz absichtlich nicht) oder die Geräte (Konfiguration) deiner Frau haben generelle Probleme mit dem NAT-Loopback.


    Versuch mal mit "cloud.mablog.de" (statt mit der myfritz-Adresse) auf den Geräten deiner Frau bzw. deaktiviere auch Umleitung der subdomain von deiner Homepage auf die myfritz Adresse.


    Wie ist es mit deinen Geräten, funktionieren die mit der myfritz-Adresse (aus dem W/LAN der FB)?

  • Pi hängt sich auf beim Herunterfahren

    hyle schrieb:

    rpi444 Du kennst meine Meinung dazu, besser zurück auf stabil, als vorwärts ins Unbekannte. ;)

    Ich habe ja als 1. das Zurück (btw. der .69 ist lt. upgrade auch "stabil") und danach, _wenn nicht produktiv_, das "rpi-update" empfohlen. ... und das auch nur deshalb weil ich den aktuellen .70 auf meinem PI3 getestet habe:

    Code
    1. pi@raspberrypi:~ $ uname -a
    2. Linux raspberrypi 4.14.70-v7+ #1144 SMP Tue Sep 18 17:34:46 BST 2018 armv7l GNU/Linux



    EDIT:


    BTW: Wer auf einen stabilen Kernel wechselt und sein System mit "apt-get upgrade --with-new-pkgs" aktuell halten will, sollte die relevanten Kernel-packages mit hold markieren.

  • Pi hängt sich auf beim Herunterfahren

    Luelaes schrieb:

    Bei uname wird folgendes ausgeschrieben:


    Linux raspberrypi 4.14.69-v7+ #1141 SMP Mon Sep 10 15:26:29 BST 2018 armv7l GNU/ Linux

    Mit diesem Kernel gibt es die Probleme (siehe die Links im anderen Thread). Entweder auf einen älteren Kernel wechseln, oder wenn es kein produktives System ist, ausnahmsweise mal ein "sudo rpi-update" machen.

  • Cloud nicht von jedem Gerät aus dem Internet erreichbar

    Mario Be schrieb:

    rpi444  

    Also der Laptop wie auch der Rechner meiner Frau sind im gleichen Netzwerk wie auch der Pi.

    Das hat aber nichts mit der Erreichbarkeit aus dem Internet zu tun (siehe Threadtitel), wenn deine Frau es aus dem (W)LAN der FritzBox versucht.


    Oder versucht sie es mit "cloud.mablog.de" aus dem (W)LAN? Wenn ja, warum? ... denn im (W)LAN kann sie doch die interne IP-Adresse verwenden. Wie wird auf den Geräten deiner Frau, "cloud.mablog.de" im (W)LAN aufgelöst?