Hallo, vielleicht nicht das ideale Forum, aber hier gibts einfach deutlich mehr Kompetenz und Hilfsbereitschaft als in den meisten anderen Foren :-) Ich versuche einen Raspberry Pi 3 als WLAN Access Point (Ethernet / WLAN Bridge) zu betreiben, alles mit den Onboard Schnittstellen. Da ich nicht routen sondern einfach nur bridgen möchte, habe ich gemäß den Anleitungen im Netz die Pakete hostapd und bridge-utils (aber nicht dnsmasq !) installiert und konfiguriert. Der Raspi soll unter einer statischen IP Adresse verfügbar sein. Habe daher seinen dhcpcd Daemon deaktiviert. Das ganze funktioniert eine begrenzte Zeit genau wie gewünscht: WLAN Geräte können sich mit dem Raspi verbinden, bekommen vom DSL-Router (nicht vom Raspi!) eine IP zugewiesen, Zugriff auf Heimnetz und Internet, alles wunderbar. Nach einer Weile (dies kann zwischen wenigen Minuten und mehreren Stunden variieren, habe noch keine Abhängigkeit erkennen können) verliert der Raspi aber die Netzwerkverbindung. Ich kann ihn nicht mehr über Telnet auf eth0 erreichen, und auch die (nach wie vor verbundenen!) WLAN Geräte haben keinen Zugriff aufs Heimnetz oder Internet. Ich vermute dass es nicht an der hostapd Konfiguration oder an WLAN Energiesparmodi liegt, denn wie gesagt sehe ich immer noch ras Raspi WLAN und kann mich immer noch drahtlos verbinden. Dann scheitert es aber an der Vergabe der IP-Adresse, er verbindet also nicht mehr ins drahtgebundene Netz. Oder das drahtgebundene ist eben offline, weil Telnet ist ja ebenfalls tot. Ohne Bridge-Betrieb arbeitet eth0 tagelang problemlos. Nachfolgend noch meine Konfig aus /etc/network/interfaces System ist Jessie Kernel 4.4.34-v7+ Hat jemand eine Idee warum das ganze prinzipiell zwar gut funktioniert, aber leider nicht dauerhaft läuft? Danke, Ignaz auto lo iface lo inet loopback auto eth0 auto wlan0 iface wlan0 inet manual wireless-power off # wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf auto br0 iface br0 inet static address 192.168.2.222 netmask 255.255.255.0 gateway 192.168.2.1 dns-nameservers 192.168.2.1 bridge_ports eth0 wlan0 bridge_fd 0 bridge_stp off
Ignaz schrieb: > Hat jemand eine Idee warum das ganze prinzipiell zwar gut funktioniert, > aber leider nicht dauerhaft läuft? hast du Tastatur und Monitor am Raspi? Dann könnte man wenn das Problem auftritt ein paar tests machen. Oder mal dmesg aufrufen.
An sich soll das ganze headless laufen, aber für die Fehlersuche kann ich einen Bildschirm anschließen - sofern Du mir sagst was ich damit tun soll :-) Gibts was bestimmtes worauf ich bei dmesg achten soll, oder einfach gucken was passiert wenn er sich wieder aufhängt? Meine Linux Kenntnisse sind sind recht mäßig...
Ignaz schrieb: > An sich soll das ganze headless laufen, aber für die Fehlersuche kann > ich einen Bildschirm anschließen - sofern Du mir sagst was ich damit tun > soll :-) auf der console mal dmesg aufrufen.
Ignaz schrieb: > sofern Du mir sagst was ich damit tun > soll :-) Neben dmesg würde ich dann noch ifconfig und route anschauen, falls noch irgendwo ein mdns service wie avahii oder sonstwas hineinpfuscht.
Danke für die Vorschläge.
Es hat etwas gedauert mit dem Reproduzieren, an den
Werktags-Feierabenden wollte der Fehler nicht kommen.
Dafür jetzt umso öfters.
Im folgenden ein Vergleich der von Euch vorgeschlagenen Logfiles.
Kommando route:
Solange die Bridge korrekt funktioniert:
Ziel Router Genmask Flags Metric Ref Use
Iface
default fritz.box 0.0.0.0 UG 0 0 0
br0
192.168.2.0 * 255.255.255.0 U 0 0 0
br0
Sobald eth0 nicht mehr erreichbar ist:
Ziel Router Genmask Flags Metric Ref Use
Iface
default 192.168.2.1 0.0.0.0 UG 0 0 0
br0
192.168.2.0 * 255.255.255.0 U 0 0 0
br0
Im Fehlerfall wird aus fritz.box die (korrekte!) IP der Fritzbox.
Kommando ifconfig:
Einziger Unterschied: im Fehlerfall hat eth0 TX/RX error packets Zähler
>0.
Kommando dmesg:
Sowohl im funktionierenden als auch im defekten Zustand kommt ca. alle 2
Minuten diese Meldung:
[ 1846.274067] brcmfmac: brcmf_proto_bcdc_hdrpull: wlan0: non-BCDC
packet received, flags 0x36
Das scheint wohl normal zu sein!?
Sobald eth0 sich aufhängt, kommen folgende Meldungen dazu.
Einmalig:
[65184.893507] TCP: request_sock_TCP: Possible SYN flooding on port 80.
Sending cookies. Check SNMP counters.
Zyklisch, das geht dann endlos so weiter:
[70467.837253] brcmfmac: brcmf_proto_bcdc_hdrpull: wlan0: non-BCDC
packet received, flags 0x36
[70574.773802] smsc95xx 1-1.1:1.0 eth0: kevent 0 may have been dropped
[70574.773843] smsc95xx 1-1.1:1.0 eth0: kevent 0 may have been dropped
[70598.699581] brcmfmac: brcmf_proto_bcdc_hdrpull: wlan0: non-BCDC
packet received, flags 0x36
[70639.086904] smsc95xx 1-1.1:1.0 eth0: kevent 0 may have been dropped
[70726.061476] brcmfmac: brcmf_proto_bcdc_hdrpull: wlan0: non-BCDC
packet received, flags 0x36
[70799.993604] smsc95xx 1-1.1:1.0 eth0: kevent 0 may have been dropped
[70799.993645] smsc95xx 1-1.1:1.0 eth0: kevent 0 may have been dropped
[70811.177969] smsc95xx 1-1.1:1.0 eth0: kevent 0 may have been dropped
[70832.206128] smsc95xx 1-1.1:1.0 eth0: kevent 0 may have been dropped
[70841.722944] brcmfmac: brcmf_proto_bcdc_hdrpull: wlan0: non-BCDC
packet received, flags 0x36
[70864.398895] smsc95xx 1-1.1:1.0 eth0: kevent 0 may have been dropped
Beim googeln nach letzterer Meldung berichten manche Leute von
instabilder Spannungsversorgung. In der Tat habe ich den Raspberry
bewusst nur mit 4.7V versorgt und das ganze nun testhalber mal auf 5.1V
(gemessen auf Raspi IO Leiste) erhöht. Pufferelkos, kurze Kabel und
ausreichend Stromreserve (3 Ampere) vorhanden. Daran dürfte es bei mir
eher nicht liegen.
Andere Leute vermuten eine fehlerhafte SD-Karte, aber eigentlich ist das
eine überdimensionierte Sandisk die erst kurz im Einsatz ist. Habe
dennoch das System auf eine andere Karte geklont, auch hier dasselbe
Fehlerbild.
Habt Ihr einen Tip?
Danke.
Ignaz schrieb: > Im Fehlerfall wird aus fritz.box die (korrekte!) IP der Fritzbox. ist nur eine Nebenwirkung, weil die DNS-Auflösung nicht geht. Ignaz schrieb: > Beim googeln nach letzterer Meldung berichten manche Leute von > instabilder Spannungsversorgung. warum? Damit wird er Strom sogar höher, weil der Rapsi einen Schaltregler hat. Ich würde auch auf die Stromversorgung tippen. Verwende mal einen aktiven USB-HUB (mit Stromversorgung) für den WLAN-Dongel.
Peter II schrieb: > Verwende mal einen > aktiven USB-HUB (mit Stromversorgung) für den WLAN-Dongel. probier doch überhaupt mal einen usb wifi dongle anstatt des onboard moduls
Peter II schrieb: > warum? Damit wird er Strom sogar höher, weil der Rapsi einen > Schaltregler hat. Hatte das Projekt mit einem alten B+ begonnen, soweit ich weiß hat der einen Linearregler, daher hatte ich nur mit 4.7V gespeist. Beim Raspi 3 dürfte dieses Argument hinfällig sein, aber wie gesagt mit 5.1V lief es auch nicht. Kann aber gerne mal versuchen ob ich einen externen WLAN Dongle finde, dann versuche ich deinen Vorschlag.
Konntest Du schon eine Lösung finden? Habe hier das exakt selbe Problem (selbe Konfiguration wie Du).
Possible SYN flooding on port 80 hört sich nach einem Angriff an zu mindestens kann ich diesbezüglich in einigen Router Firewalls etwas einstellen ab welcher Anzahl das unterbunden wird. gestern Abend gabs ein größeres Update vielleicht wurde da was gefixt. führe das mal Schritt für Schritt durch sudo apt-get update sudo apt-get upgrade sudo apt-get dist-upgrade
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.