News: This forum is now permanently frozen.
Pages: [1]
Topic: Kein Zugriff auf GUI über Interfaces != LAN - SOLVED  (Read 2846 times)
« on: September 19, 2008, 17:38:55 »
david *
Posts: 18

Hi!

Habe m0n0wall 1.3b14 auf einem ALIX eingerichtet und hänge bei dem Problem, dass ich nicht von WLAN auf LAN zugreifen kann.

Konfiguration:

LAN 192.168.1.1/30 (reicht, der Rest läuft über eigene VLAN-interfaces)
- kein DHCP

WLAN 192.168.1.128/28
- Typ: hostap
- DHCP aktiviert
- Bridge with: none

Firewall: jeweils für LAN und WLAN eine (einzige) "pass * * * * *"-Regel.

Wenn ich mich per Netzwerkkabel mit statischer 192.168.1.1 verbinde, kann ich problemlos auf das Web-GUI zugreifen und .1 pingen. Passt.

Verbinde ich mich via WLAN, bekomme ich eine IP-Adresse aus dem richtigen Bereich zugewiesen, kann aber nicht auf das Web-GUI zugreifen. Wenn ich .1 pinge, bekomme ich "ping: sendto: Host is down", bei .128 (dem WLAN-Gateway) passiert überhaupt nichts.

Ich kann übrigens genausowenig aus anderen Segmenten (VLANs) auf das LAN zugreifen. Nachdem das Problem aber auch in Verbindung mit WLAN auftritt, dürfte der Fehler nichts mit der VLAN-Konfiguration zu tun haben.

Es ist wahrscheinlich nur ein blöder Fehler - hat jemand eine Idee? TIA!
« Last Edit: September 20, 2008, 08:30:44 by lonelyroad »
« Reply #1 on: September 19, 2008, 17:58:19 »
Manuel Kasper
Administrator
*****
Posts: 364

WLAN 192.168.1.128/28

Im Subnet 192.168.1.128/28 ist 192.168.1.128 die Netzwerkadresse und darf damit nicht einem Gerät zugewiesen werden. Gib deiner m0n0wall stattdessen 192.168.1.129, dann sollte es funktionieren.
« Reply #2 on: September 19, 2008, 18:40:16 »
david *
Posts: 18

Danke für die rasche Antwort, Manuel!

Mit der Subnet-IP hast Du natürlich Recht. Trotzdem tut es leider immer noch nicht: ping meint "route to host is down". Ach ja, der Interface-status zeigt beim WLAN-Interface haufenweise In-Errors. Hat vielleicht was damit zu tun... Noch eine Idee?
« Last Edit: September 19, 2008, 18:44:27 by lonelyroad »
« Reply #3 on: September 20, 2008, 08:30:27 »
david *
Posts: 18

So, ich mach jetzt mal die Ingrid: Die Sache hat sich großteils gelöst.

Ursache war, dass ich parallel zur m0n0wall noch den bisherigen Router am Laufen hatte, der (über ein anderes Interface des PCs) Adressen aus einem anderen 192.168.x.0/24-Subnet vergab. Das wäre an sich auch kein Problem gewesen, nur kam der PC offenbar mit den Routen durcheinander, insbesondere mit der default-Route. Deshalb klappte auch der Zugriff nur, wenn ich eine IP aus dem LAN-Segment hatte (selbes Subnet). Eine händisch eingetragene Route, oder die passende default-Route, behoben das Problem.

Unabhängig davon habe ich beobachtet, dass ein paar Mal Hin- und Herstecken des am LAN-Interface hängenden Switches (samt anderen Geräten dran) möglicherweise die m0n0wall aus dem Tritt bringt und sie zumindest nicht mehr auf DHCP DISCOVER antwortete. Wenn ich in so einem Fall per CLI die LAN-IP neu setzte, kam eine Meldung in Richtung "vr0: force reset" (wobei vr0 = LAN-IF). Ich habe mich allerdings bis jetzt zu wenig damit beschäftigt, um Genaueres sagen zu können. Reboot half - ist ja auch eine beta, da ist das entschuldbar.

Danke nochmal für die rasche Hilfe, Manuel! Ich lehne Paypal ab, hätte aber IIRC noch ein paar Franken in cash, die ich Euch/Dir (nicht nur wegen des Supports in meinem Fall) gern zukommen lassen würde. Bräucht ich nur eine snail-mail-Adresse...
« Reply #4 on: September 20, 2008, 13:37:17 »
Manuel Kasper
Administrator
*****
Posts: 364

Unabhängig davon habe ich beobachtet, dass ein paar Mal Hin- und Herstecken des am LAN-Interface hängenden Switches (samt anderen Geräten dran) möglicherweise die m0n0wall aus dem Tritt bringt und sie zumindest nicht mehr auf DHCP DISCOVER antwortete. Wenn ich in so einem Fall per CLI die LAN-IP neu setzte, kam eine Meldung in Richtung "vr0: force reset" (wobei vr0 = LAN-IF). Ich habe mich allerdings bis jetzt zu wenig damit beschäftigt, um Genaueres sagen zu können. Reboot half - ist ja auch eine beta, da ist das entschuldbar.

Das ist mir auch schon aufgefallen - siehe http://m0n0.ch/wall/list/showmsg.php?id=344/90. Sieht nach einem Bug (oder vielleicht einem fehlenden Workaround für einen Chipset-Bug ;) im vr-Treiber von FreeBSD 6.3 aus. Gut möglich, dass es in FreeBSD 7.0 behoben ist (es wurden massive Änderungen am vr-Treiber gemacht); ein Backport scheint aber nicht einfach möglich zu sein. Damit m0n0wall 1.3 nicht noch weiter verzögert wird, muss es wohl bei FreeBSD 6.3 bleiben; somit wird das Problem bis dahin leider noch bestehen... es sei denn, jemand findet einen vernünftigen Workaround - vielleicht automatisch ifconfig down/up ausführen, wenn der Link-Status geändert hat oder sowas...
 
Pages: [1]
 
 
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines