Thema: (Erledigt?) Suse 10.3: Routingprobleme über WLAN

Ich habe ein lustiges kleines Netzwerk, was ungefähr so aufgebaut ist:

2 Rechner <-> LAN-Port von Router <-> WLAN-AP <-> WLAN-Repeater <-> WLAN-AP <-> Switch <-> 3 Rechner

Alle Rechner laufen unter Suse Linux (10.1 bis 10.3). Jeder Rechner kann jeden anderen pingen. Oder konnte, bis ich einen davon auf Suse 10.3 aktualisierte. Der hängt am LAN-Port vom Router und kann alles "diesseits" erreichen (also den anderen Rechner am selben LAN-Port, den Router und alles im Internet etc.), aber nichts ab dem WLAN-Repeater.

Das Problem tritt nur beim 10.3-Rechner auf, und nur wenn er am LAN-Port des Routers hängt. (Wenn ich ihn auf der "anderen Seite" in den Switch stöpsele, gibt es keinerlei Probleme.)

Hat jemand eine Idee, wo ich mit der Problemsuche ansetzen soll?

Wie verbindest du dich unter openSUSE?
- Networkmanager?
- Ifup?

Domainname deines Rechners?

Code:

hostname -d

Poste doch mal die IPs zu dem Netzwerk.

Außerdem: Folgendes Script laufen lassen.
=> Framp's Linux Tips und Beispielkonfigurationen - collectNWData
(Ausgaben posten)

In openSUSE wurde einiges bezügich AutoDNS (Avahi, etc.) geändert.
Versuch mal den nscd sowie den avahi-daemon abzuschalten:
YaST > System > System Services (Runlevel)

Danke erst mal für die schnelle Antwort!

Zitat von b3ll3roph0n

Wie verbindest du dich unter openSUSE?
- Networkmanager?
- Ifup?

Domainname deines Rechners?

Code:

hostname -d

Domainname ist für alle 5 Rechner

Code:

site

Poste doch mal die IPs zu dem Netzwerk.

Hier sind sie (ich benutze kein DHCP):

Code:

192.168.0.52    astraia-air
192.168.0.1     router lennart
192.168.0.2     ap finn
192.168.0.3     repeater linus
192.168.0.6     printer
192.168.0.10    iconnect2
192.168.0.11    themis.site themis
192.168.0.45    athena-air
192.168.0.101   athena.site athena
192.168.0.47    artemis.site artemis
192.168.0.102   astraia.site astraia

Außerdem: Folgendes Script laufen lassen.
=> Framp's Linux Tips und Beispielkonfigurationen - collectNWData
(Ausgaben posten)

Danke für den Link! An der momentanen Position gibt's meiner Problem-Maschine (am Switch) gibt's erwartungsgemäß nur die Rückmeldung

Code:

--- No obvious errors detected. Post contents of file collectNWData.out.

. Ich werde die Maschine heute abend mal in die Wohnung mitnehmen und dort (am LAN-Port des Routers) das Skript noch mal ablaufen lassen. Falls es Probleme meldet oder sonst etwas in

Code:

collectNWData.out

interessant aussieht, poste ich es hier.

In openSUSE wurde einiges bezügich AutoDNS (Avahi, etc.) geändert.
Versuch mal den nscd sowie den avahi-daemon abzuschalten:
YaST > System > System Services (Runlevel)

Gut zu wissen, vielen Dank!

Nachtrag:

Habe den Rechner an den LAN-Port des Routers gehängt. collectNWData.sh gibt auch jetzt (wo ich wie erwartet keinen Rechner im WLAN pingen kann) keine Fehler, aber diese Zeilen in der Ausgabedatei (muss wegen Längenrestriktionen dieses Forums leider kürzen):

Code:

Chain input_ext (5 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           PKTTYPE = broadcast udp dpt:177 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           PKTTYPE = broadcast udp dpt:631 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           PKTTYPE = broadcast udp dpt:123 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           PKTTYPE = broadcast udp dpt:427 
    1    78 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           PKTTYPE = broadcast udp dpt:137 
    6  1374 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           PKTTYPE = broadcast udp dpt:138 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           PKTTYPE = broadcast udp dpt:5353 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           PKTTYPE = broadcast udp dpt:67 
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           PKTTYPE = broadcast 
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 4 
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8 
    0     0 ACCEPT     esp  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 5 tcp dpt:5801 flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-INext-ACC-TCP ' 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:5801 
    0     0 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 5 tcp dpt:5901 flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-INext-ACC-TCP ' 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:5901 
    0     0 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 5 tcp dpt:53 flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-INext-ACC-TCP ' 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:53 
    0     0 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 5 tcp dpt:80 flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-INext-ACC-TCP ' 

...

    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:631 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:67 
    1    60 reject_func  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:113 state NEW 
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 5 PKTTYPE = multicast LOG flags 6 level 4 prefix `SFW2-INext-DROP-DEFLT ' 
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           PKTTYPE = multicast 
    0     0 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 5 tcp flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-INext-DROP-DEFLT ' 
    0     0 LOG        icmp --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 5 LOG flags 6 level 4 prefix `SFW2-INext-DROP-DEFLT ' 
    0     0 LOG        udp  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 5 LOG flags 6 level 4 prefix `SFW2-INext-DROP-DEFLT ' 
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 5 state INVALID LOG flags 6 level 4 prefix `SFW2-INext-DROP-DEFLT-INV ' 
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain reject_func (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    1    60 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with tcp-reset 
    0     0 REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-proto-unreachable

nscd und avahi scheinen am Problem nicht beteiligt zu sein (oder vielleicht doch? siehe verschiedene Fehlermeldungen beim Pingen):

Code:

astraia~ # rcnscd status
Checking for Name Service Cache Daemon:                               running
astraia~ # rcnscd stop
Shutting down Name Service Cache Daemon                               done
astraia~ # ping linus
PING repeater (192.168.0.3) 56(84) bytes of data.

--- repeater ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

astraia~ # rcnscd start
Starting Name Service Cache Daemon                                    done
astraia~ # rcavahi-dnsconfd status
Checking for Avahi DNS Configuration daemon:                          running
astraia~ # rcavahi-dnsconfd stop
Shutting down Avahi DNS Configuration daemon                          done
astraia~ # ping linus
PING repeater (192.168.0.3) 56(84) bytes of data.
From astraia.site (192.168.0.102): icmp_seq=1 Destination Host Unreachable
...

Kürzen bringt nix.

Vollständiges Script in .txt umbenennen und als Anhang an ein Posting drankleben oder einen No-Paste Service verwenden.

Greetz,

RM

Zitat von Rain_Maker

Kürzen bringt nix.

Vollständiges Script in .txt umbenennen und als Anhang an ein Posting drankleben oder einen No-Paste Service verwenden.

Greetz,

RM

War gesten wohl schon zu müde, um an sowas zu denken. Hier ist die vollständige Ausgabe: http://stefanhinz.dyndns.org/collectNWData.out

Da läuft doch auch noch ein VPN?
Über welche Verbindung funktioniert denn der Zugriff auf das Internet?
- Die Namensauflösung läuft jedenfalls nicht über deinen Router, sondern über 10.100.72.1.

IMHO solltest du auch den Nameserver deines lokalen Netzes in die /etc/resolv.conf eintragen:

Code:

search mysql.com
search site
nameserver 10.100.72.1
nameserver 192.168.0.1

Die Daemons avahi-daemon avahi-dnsconfd nscd kannst du eigentlich auch deaktivieren.
(Die Namensauflösung läuft bei dir sowieso über die /etc/hosts - bei dem Netzwerk könnte man auch schon mal über einen eigenen DNS-Server nachdenken )

Und dann bitte noch:

Code:

ping 192.168.0.1
ping lennart

Code:

ping 192.168.0.45
ping athena-air

Code:

ping 192.168.0.101
ping athena

Also: Router anpingen (über IP und Name), Rechner im LAN anpingen (über IP und Name) und Rechner im WLAN anpingen (über IP und Name).

Das Routing scheint allerding soweit in Ordnung zu sein.
... und wenn du auf die die Rechner im LAN zugreifen kannst ... und auf die im WLAN nicht, obwohl die doch im selben Subnetz liegen ...

Befinden sich alle Rechner gleichzeitig noch im VPN, oder nur die SUSE 10.3?

Zitat von b3ll3roph0n

Da läuft doch auch noch ein VPN?
Über welche Verbindung funktioniert denn der Zugriff auf das Internet?
- Die Namensauflösung läuft jedenfalls nicht über deinen Router, sondern über 10.100.72.1.

Ich hätte erwähnen sollen, dass das beschriebene Problem unabhängig davon ist, ob ein VPN-Tunnel da ist oder nicht.

IMHO solltest du auch den Nameserver deines lokalen Netzes in die /etc/resolv.conf eintragen:

Code:

search mysql.com
search site
nameserver 10.100.72.1
nameserver 192.168.0.1

Die Daemons avahi-daemon avahi-dnsconfd nscd kannst du eigentlich auch deaktivieren.
(Die Namensauflösung läuft bei dir sowieso über die /etc/hosts - bei dem Netzwerk könnte man auch schon mal über einen eigenen DNS-Server nachdenken )

Mittels Kopieren von /etc/hosts lief's bisher noch recht schmerzfrei. :-)

Und dann bitte noch:

Code:

ping 192.168.0.1
ping lennart

Code:

ping 192.168.0.45
ping athena-air

Code:

ping 192.168.0.101
ping athena

Also: Router anpingen (über IP und Name), Rechner im LAN anpingen (über IP und Name) und Rechner im WLAN anpingen (über IP und Name).

Das Routing scheint allerding soweit in Ordnung zu sein.
... und wenn du auf die die Rechner im LAN zugreifen kannst ... und auf die im WLAN nicht, obwohl die doch im selben Subnetz liegen ...

Genau das ist auch der Grund meiner Verwirrung. Alles im selben Subnetz, und alle Rechner sehen sich, außer der neue Suse 10.3-Rechner. Selbst der andere am LAN-Port des Routers hängende Rechner kann alle anderen Maschinen - auch über WLAN - erreichen.

Aus dem Grund hatte ich zuerst auf ein Problem bei den 3 WLAN-Access Points getippt. Nach Durchgehen aller relevanten Einstellungen auf diesen Geräten (man weiß ja nie, was man mal spät in der Nacht an MAC-Adressfilterung oder dergleichen aktiviert hat ;-)) bin ich jedoch sicher, dass hier kein Problem bei den Einstellungen der WLAN-Geräte vorliegt. Also muss es "irgendwie" am 10.3-Rechner liegen.

Befinden sich alle Rechner gleichzeitig noch im VPN, oder nur die SUSE 10.3?

Nur die Suse 10.3-Maschine. Ich werde heute abend mal VPN ausmachen und eine neue, "unverfälschte" Ausgabe von collectNWData erzeugen.

Zitat von stefanhinz

Ich werde heute abend mal VPN ausmachen und eine neue, "unverfälschte" Ausgabe von collectNWData erzeugen.

Scheint sich wohl um eine Polarnacht handeln.

Völlige Dunkelheit <== Licht aus.


Gruß

KM