sheogorath
Goto Top

Raspbian verweigert WLAN Verbindung nach UMTS Verbindungsaufbau

Moin,

ich habe da mal ein unfeines Problem, das scheinbar nicht nur mein Problem ist, aber zu dem ich auch nach über 5 Stunden keine Lösung gefunden habe.

Es geht darum:
Mein Raspberry Pi mit Raspbian installiert soll ein bisschen Netzwerkmeister spielen und folgendes tun:
LAN (eth0) - Verbindung zum offline Switch stellt DHCP und DNS zur verfügung (läuft)
WLAN (wlan0) - Stellt Verbindung zum heimischen WLAN her, welches aber nicht immer aktiv ist.
und jetzt zum Problem:
UMTS (ppp0) - Nach einigem Gefrickel läuft es jetzt soweit ganz gut, Verbindung steht alles wunderbar. einzeln...

Über die UMTS Verbindung soll ein ZNC und ein IRCd für weniger Personen laufen, also nichts wildes, über das heimische WLAN ist das aufgrund einiger Personen im Haushalt nicht möglich. Genaueres in dieser Richtung, erspare ich euch.

Das Problem ist einfach: Sobald ich die UMTS Verbindung herstelle trennt Raspbian die Verbindung zum WLAN. Soweit kein Problem, dachte ich der wird die schon wieder finden. tut er aber nicht. sobald die UMTS Verbindung besteht weigert er sich das WLAN zu verbinden. mit etwas Gewalt also einem "ifdown --force wlan0" und einem anschließenden "ifup wlan0" geht das wieder, aber dann weigert sich iptables die Packe vom LAN ins WLAN zu routen oder das konfigurierte und ohne UMTS perfekt funktionierende NAT durchzuführen.

Was ich nun wissen will, was kann ich denn noch tun?? ich würde ja sagen, ich stelle die UMTS Verbindung her, bevor er die anderen Netzwerk Interfaces konfiguriert, aber das klappt nicht so wirklich. egal wie ich es probiere, ich bekomme das Routing nicht wieder hin. Kein Reimport der iptables Konfiguration hilft, nichts. jetzt suche ich nach einer Stellschraube, an der ich drehe kann um das disconnecten vom WLAN zu verhindern.

Was mir übrigens aufgefallen ist, dass es nicht nur mit UMTS so ist, sondern auch mit VPN Interfaces, sobald ich einen VPN-Dienst installiere und starte, keine Verbindung zum WLAN.

Könnt ihr mir irgendeinen Hinweis geben, woran es liegt, ich liege was Linux angeht, so auf dem Kenntnisstand eines fortgeschrittenen Anfänger, würde ich sagen. Vielleicht habe etwas einfach noch nie gesehen oder gehört. ich bin Gespannt, ob ihr eine Lösung wisst, denn das wäre wirklich von Vorteil!!!


Mit freundlichen Grüßen und Hoffnung auf Hilfe
Gruß
Chris

Content-ID: 236466

Url: https://administrator.de/contentid/236466

Ausgedruckt am: 23.11.2024 um 22:11 Uhr

certifiedit.net
Lösung certifiedit.net 26.04.2014 aktualisiert um 18:20:23 Uhr
Goto Top
Moin Chris,

fangen wir mal ganz bei den Basics an: Ist das Ding ggf. ausgelastet? Ich mein, ein Raspy ist ja ganz nett, hier hängt bei mir auch einer an der Wand, aber irgendwann sagt der sich eben, dass er nicht mehrmag. Daher: Check erstmal die Auslastung. danach lass dir mal die Routingtabelle ausgeben - vor und nach UMTS, falls Punkt eins nicht schon zur Ernüchterung beigetragen hat.

LG,

Christian
aqui
aqui 26.04.2014 um 11:07:42 Uhr
Goto Top
Sobald ich die UMTS Verbindung herstelle trennt Raspbian die Verbindung zum WLAN.
Das sollte auf keinen Fall so sein !
WLAN und UMTS koexistieren problemlos, denn für den RasPi sind es ja nur 2 unterschiedliche Netzwerk Adapter ?!
WIE hast du die WLAN Verbindung realisiert ?? Statisch über /etc/network/interfaces oder über die wpa_supplicant Datei ??
Näheres dazu hier:
Netzwerk Management Server mit Raspberry Pi

Routing Probleme tauchen nur auch wenn den WLAN und das UMTS Netz gleiche IP Netzwerkadressen verwenden. Ziemlich unwahrscheinlich aber ausschliessen kann man es nicht, denn bei Billig Surftarifen im UMTS bekommt man dort auch private RFC 1918 IP Adressen statt öffentliche Adressen und die Gefahr einer IP Adressdopplung ist dann schon gegeben. Check das also mit ifconfig mal. zur Sicherheit.

Das das WLAN ausfällt wenn auf anderen Adaptern was passiert ist auf alle Fälle nicht normal !
Interessant wäre mal der Inhalt der interfaces Datei ?!
Sheogorath
Sheogorath 26.04.2014 um 11:57:25 Uhr
Goto Top
Moin,

danke für die Antworten, ich hoffe wir finden den Fehler, aqui, ich stimme dir 100% zu, eigentlich sollte das nicht so sein! Ich vermute mal es liegt daran, dass bei einem "ifconfig" der UMTS Adapter erst auftaucht, sobald ich die Verbindung hergestellt habe. Adresskonflikt, kann ich ausschließen (UMTS nutzt einen 10.x.x.x/32 (warum auch immer) Bereich WLAN ist im 192.168.137.x/24 Bereich unterwegs. Lokal im 192.168.100.x/24).
und wie gesagt, wenn ich ein "ifdown --force wlan0" und dann "ifup wlan0" mache, dann berappelt er sich auch wieder, nur leitet er keine Pakete mehr weiter.

interfacesdatei sieht so aus:
auto lo eth0

iface lo inet loopback
	iface eth0 inet static
	address 192.168.100.1
	network 192.168.100.0
        netmask 255.255.255.0
        broadcast 192.168.100.255

allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp
ich vermute auch, dass hier der Fehler liegt, nur wüsste ich nicht, wie ich ihm mitteilen kann, dass er ein UMTS modem besitzt ohne, dass er res erkannt hat.

wie du siehst, eigentlich ziemlich 08/15 die Interface config

routingtablelle von iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       tcp  --  anywhere             anywhere             tcp dpt:webmin

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
Verwundert mich gerade etwas, erklärt aber nicht, warum das Interface down geht...

importiert wird folgendes als config:
# Generated by iptables-save v1.4.14 on Mon Mar 31 23:56:40 2014
*mangle
:PREROUTING ACCEPT [1819:174032]
:INPUT ACCEPT [1775:172004]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1262:442805]
:POSTROUTING ACCEPT [1266:443787]
COMMIT
# Completed on Mon Mar 31 23:56:40 2014
# Generated by iptables-save v1.4.14 on Mon Mar 31 23:56:40 2014
*filter
:INPUT ACCEPT [351:27094]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [233:25896]
-A INPUT -i wlan0 -p tcp -m tcp --dport 10000 -j DROP
COMMIT
# Completed on Mon Mar 31 23:56:40 2014
# Generated by iptables-save v1.4.14 on Mon Mar 31 23:56:40 2014
*nat
:PREROUTING ACCEPT [32594:2468143]
:INPUT ACCEPT [12012:1327947]
:OUTPUT ACCEPT [17149:1633086]
:POSTROUTING ACCEPT [4384:342870]
-A POSTROUTING -o wlan0 -j MASQUERADE
COMMIT
# Completed on Mon Mar 31 23:56:40 2014

Die UMTS Verbindung stelle wie folgt her:
/home/pi/umtskeeper/umtskeeper --sakisoperators "USBINTERFACE='0' OTHER='USBMODEM' USBMODEM='12d1:1001' APN='CUSTOM_APN' CUSTOM_APN='pinternet.interkom.de' APN_USER='0' APN_PASS='0'" --sakisswitches "--sudo --console" --devicename 'Huawei' --log --silent --monthstart 8 --nat 'no'  

Ich hoffe, jetzt hat jemand eine Erleuchtung.

Ich vermute sogar, dass der Fehler dadurch zustande kommt, dass er eben das Interface naträglich hinzufügt, aber warum der dann das WLAN abschaltet ist mir schleierhaft. (denn wie schobn gesagt, das Problem trat ebenfalls beim installieren eines VPN Clients auf, nur hielt ich es da für einen Programm"fehler", was sich nun als falsch herausstelt)

Übirgens: Auslastung sollte nicht das Problem sein, zum Einen idlet er fast nur herum und zum Anderen kann er ja dann wieder in WLAN, sobald ich das WLAN-Interface per Shell zurück gesetzthabe, nur das NAT zieht dann eben nicht mehr. er selbst hat Internetverbindung über das WLAN (ip und Co ist geprüft)

Gruß
Chris
aqui
Lösung aqui 26.04.2014 aktualisiert um 18:20:16 Uhr
Goto Top
OK die wpa_supplicant sollte dann so aussehen:
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev 
update_config=1 
eapol_version=1 
ap_scan=1 
network={ 
               ssid="Kernis-WLAN" 
               scan_ssid=1 
               key_mgmt=WPA-PSK 
               pairwise=CCMP 
               group=CCMP 
               psk=01b035e08abcdefg3e348e6fbb478312345678950789c691687ee0a6f71584e8b 
          }  
Wobei man die PSK Passpharse mit wpa_passphrase erzeugt.
Damit sollte das WLAN dann immer autark arbeiten !

Beim UMTS Adapter irritiert eher das --nat 'no' in der Konfig, denn zu einem öffentlichen Internet sollte man natürlich immer NAT bzw. Masquerading machen...alles andere wäre tödlich.
Da der UMTS sich ja mit PPP einwählt ist das entsprechende Netzwerk Device ein dynamisches PPP Interface was man nur sieht wenn eine aktive UMTS Verbindung besteht.
Knackpunkt ist häufig die PIN der Daten SIM Karte. Oftmals können die Dialer damit nicht richtig umgehen. Wäre also vielleicht zum Testen besser wenn man die SIM Pin temporär erstmal deaktiviert.
Hast du sudo apt-get install ppp usb-modeswitch installiert ?

Nochwas zum Schluss:
Essentiell wichtig ist eine potente Spannungsversorgung am besten über den USB Hub selber. Der Ausfall deines WLANs ist auch möglicherweise durch einen Reboot bedingt wenn der UMTS Stick gesteckt wird. Das passiert sehr häufig wenn man USB Devices nutzt die etwas mehr Strom ziehen und man keinen aktiven USB Hub benutzt.
Du kannst das an den LEDs des RasPi sehen wenn der beim Stecken rebootet.
Dann ist es besser einen aktiven USB Hub wie diesen hier zu verwenden:
http://www.reichelt.de/USB-Hubs/DIGITUS-DA-70220/3/index.html?&ACTI ...

Zusätzlich hilft ggf. noch das hier:
http://www.sven-lindeboom.net/?page_id=392
und
http://www.henrykoch.de/raspberry-pi-via-umts-ins-netz
Sheogorath
Sheogorath 26.04.2014 um 18:46:40 Uhr
Goto Top
Moin,

so ich habe es gelöst bekommen face-smile

nach knapp 24 Stunden -,-

zunächst war ja nun das Problem, dass er das WLAN nicht behalten hat, das habe ich hinbekommen indem ich ein Interface angelegt habe, die es in dem von aqui genannten Artikel erklärt ist. das hat dann schon mal in Grundzügen funktioniert, das Interface, nur mein WLAN erstmal wieder nicht. Daraufhin habe ich mal in die logs geschaut, wie es in einem der gefühlten 1000 anderen Artikel, die ich zu dem Thema gelesen habe stand. Fehler gefunden es ist wpa_supplicant, was das WLAN-Interface tötet. also habe ich in /etc/wpa_supplicant/Action_wpa.sh den "Check" auskommentiert und siehe da, wir blieben online. Zumindest mit dem WLAN verbunden. Jetzt das leidige Weiterleitungsproblem. auch gefunden face-smile Es war kein Problem des Pis direkt, also er hat schon alles richtig weitergegeben, nur hatte sein Navi den Weg nicht parat. Kurzum, die Routingtabelle wurde beim Start des UMTS Modems verändert und deswegen war nun das WLAN ohne Gateway unterwegs. Kaum hatte ich nun das nachgetragen, perfekt, funktioniert alles!

Danke für die Hinweise und Hilfen!!

Gruß
Chris
aqui
aqui 26.04.2014 aktualisiert um 22:53:19 Uhr
Goto Top
Moin,
Hört sich gut an ! Vielleicht könntest du die Settings nochmal posten hier. Ich habe selber mal etwas getestet und das Raspberry Tutorial entsprechend erweitert mit dem UMTS Setup:
Netzwerk Management Server mit Raspberry Pi

Mit dem "Weiterleitungsproblem" meinst du vermutlich die Default Route über das ppp0 Interface, richtig ? In der wvdial.conf gibt es dafür den Parameter Check Def Route der aber im Default auf ON ist also nicht gesetzt werden muss.
Damit erzwingt man das Setzen der Default Route auf ppp0 bei erfolgter Einwahl. Ein man wvdial.conf zeigt die Optionen dort.
Bei dir müsste reichen Check Def Route = OFF zu setzen in der wvdial.conf. Allerdings hast du dann auf dem UMTS Stick keinen Internet Zugang mehr routigtechnisch...
Gesehen hab ich aber das auch allerdings genau andersrum am eth0 mit DHCP. Bei DHCP am eth0 verschwindet das Default Gateway nicht. Erst ein route add default ppp0 mangelt das über was man dann mit route -n sehen kann.

Spannend wären also mal deine Settings für die betroffenen Dateien. In der im Tutorial beschrieben wpa_supplicant.conf gibt es gar keinen Check Parameter was du da ansprichst ?!
Wie hast du das Problem des offenen Internet am ppp0 gelöst mit den iptables ?
Sheogorath
Sheogorath 28.04.2014 um 09:34:26 Uhr
Goto Top
Moin,

stimmt, ich habe inzwischen gemerkt, dass es da wirklich Probleme gibt. neben der Tatsache, dass mein UMTS Stick nicht immer die Verbindung hält, ist mein Hauptproblem eben gerade dass ich 2 defaultrouten definiere. Nur versteht der Pi dann nicht ganz was ich von ihm will. die Idee ist ja eigentlich, dass ZNC und IRCd über UMTS laufen und der von eth0 kommende Datenstrom einfach ins WLAN läuft. Vielleicht sollte ich es doch mit einer Bridge realisieren. nur hat das zumindest über Windows nicht funktioniert. (Die Hinter der Bridge liegenden Geräte bekamen keine IP mehr, das war mitunter der Grund, warum ich das ganze via NAT gelöst habe).

Deinen Tipp mit der Check Def Route muss ich mal testen, in der wpa_supplicant.conf kann man das leider auch nicht auskommentieren, da muss man etwas tiefer einsteigen. In einer der .sh Dateien gibt es 3 Zeilen, die man da anpassen muss und schon läuft's. (ich werde Dateinamen mit aktuellen Inhalt mal anfügen, sobald ich zuhause bin).

Im Moment habe ich erstmal zurückgebaut und schicke ihn nochmal per WLAN ins Netz.

Sicherheit, klar, iptables. Allerdings funktioniert im Moment so oder so der Zugriff von außen noch nicht. Ich habe da noch einiges vor mir. Und gestern tragen ganz seltsame Effekte auf. Plötzlich bricht der Rasp komplett zusammen, (stumpf reboot mitten in allem drin) wollte aber auch nicht mehr hochkommen, Strom getrennt, 10 Minuten warten, Strom dran. Ging wieder. Irgendwas ist eindeutig schief.

Gruß
Chris
aqui
aqui 28.04.2014 aktualisiert um 15:26:55 Uhr
Goto Top
dass mein UMTS Stick nicht immer die Verbindung hält
Hast du in der wvdial.conf den Parameter Idle Seconds = 0 gesetzt ?? Damit schaltet man den Idle Timeout ab, der die PPP Verbindung nach x Sekunden Inaktivität terminiert.
dass ich 2 defaultrouten definiere
Das geht so ohne weiteres nicht ! Du musst dem RasPi ja schon genau sagen WELCHE du priorisierst, denn woher soll er sonst wissen welche für ihn relevant ist ??
Das geht entweder mit einer Route Metrik oder indem du wirklich nur die eine oder andere nutzt.
http://unix.stackexchange.com/questions/35713/adding-two-default-gatewa ...
http://debianforum.de/forum/viewtopic.php?f=18&t=121141
http://verahill.blogspot.de/2012/02/debian-testing-wheezy-64-configurin ...
usw. usw.
in der wpa_supplicant.conf kann man das leider auch nicht auskommentieren
Im Tutorial Beispiel ist das gar nicht drin und es geht dennoch !! Ggf. lässt du einfach das def. Gateway am WLAN weg und ergänzt das mit einer manuellen statischen Route und entspr. Metrik ?!

Ohne iptables wie es der Default ist, kommt man natürlich auch problemlos über den UMTS Link auf den RasPi. Das klappt wunderbar. Allerdings....lauert der Teufel hier wie immer im Detail:
Wenn du einen billigen Surf only Account besitzt dann bekommst du in der Regel private RFC 1918 IP Adressen vom Provider auf dem PPP Interface (UMTS). Dort macht der Provider dann ein zenrales NAT ins Internet und du hast so keinerlei Chancen den RasPi zu erreichen...klar und logisch !
Kannst du daran sehen wenn wvdial dir 10er, 172.16-32er oder 192.168er Provider IP Adressen anzeigt beim Dialin oder bei erfolgter Verbindung dann ein ifconfig.
Mit solchen IPs ist ein remoter Zugang unmöglich. Meist kann man durch Wechsel des APN im Mobilfunknetz öffentliche IPs erzwingen, birgt aber die Gefahr dann in einem anderen Tarif (öff. IPs oft nur bei Business) bei höheren Kosten zu landen ! Dann funktioniert der Zugriff wieder..klar.
Ausweg ist dann immer VPN. Wenn der RasPi dann automatisch eine VPN Verbindung aufbaut zu einem VPN Server erzeugt er damit automatisch ein Port Forwarding am zentralen Provider NAT und der Zugang klappt so wieder.
Nur das du das bei deinen test im Hinterkopf hast ?!

Das der RasPi unvermittelt rebootet kommt vor wenn man im laufenden Betrieb USB Adapter steckt die einen sehr hohen Stromverbrauch haben. Ein Dip in der Spannungsversorgung triggert dann einen Reboot. Könnte bei dir ein Indix eines defekten oder schlechten USB Netzteils sein. Achte darauf das das mindestens 1 Ampere kann also über 5 Watt verkraftet.
Wenn du übertaktest achte darauf keine Class 10 SD Karten einzusetzen. Besser max. Class 4 dann oder Class 6.
Sheogorath
Sheogorath 29.04.2014 um 08:58:35 Uhr
Goto Top
Moin,

ich habe gestern nochmal etwas rumprobiert, wie ich es drehe und wende, es klappt alles nicht leider alles nicht so ganz. Wohlbemerkt, der Absturz findet meist mitten im Betrieb (allerdings nur bei angeschlossenem UMTS Stick und letztes mal, nach über 2h aktiver UMTS Verbindung) statt. Danach, bootet er nicht mehr wirklich. Dann heißt es eben Strom weg, kurz warten, UMTS Stick weg und neuer Versuch. Am Stromverbrauch kann es nicht liegen, da ich einen USB-Hub mit externem Strom verwende (habe ich nach deiner Empfehlung am Samstag noch gekauft, vermutlich umsonst).

Klar, mit zentralem NAT funktioniert es nicht, aber ich bastle mir jetzt mal ein VPN mit Hamachi ein. UMTS werde ich vermutlich mit einem alten Smartphone und WLAN realisieren. Keine schöne Lösung aber eine funktionierende.

Es stört mich zwar, dass es nicht ganz so einfach ist, wie geplant, aber naja, was will man machen.

Gruß
Chris
aqui
aqui 29.04.2014 aktualisiert um 18:33:05 Uhr
Goto Top
Das stehenbleiben oder nicht booten zeugt dann eher von einer kaputten SD Karte bzw. kaputtem Filesystem. Wie oben schon angemerkt solltest du wenn du den RasPi übertaktes keine Class 10 SD Karten verwenden.
http://elinux.org/index.php?title=RPiconfig&section=14#SD_Card_Usag ...
Du solltest dann besser nur ausschliesslich Class 4 Karten verwenden, denn die laufen stabil. Wenn du eine Class 10 Karte hast dann besser nicht overclocken oder nur einen Schritt ohne Spannungserhöhung.
Also besser nochmal ein neues Image auf die Karte schreiben so das das wenigstens stabil rennt.
Von Hamachi VPN kann man nur dringend abraten Das nutzt einen Vermittlungsserver und ist nicht wirklich sicher.
Nutze lieber IPsec direkt. Den Shrew Client gibt es auch für Debian und mit apt-get install ike intsallierst du den. Sogar PPTP mit einem mehr als 12 stelligen Password wäre da noch sicherer.
Eigentlich ist es ganz einfach, du musst nur erstmal den RasPi stabil zum Laufen bringen, denn das ist erste Priorität und klappt auch wenn man die SDs entsprechend wählt.