# Netzwerk und Ping außer Kraft gesetzt

## Christoph Schnauß

hallo,

ich habe vorgestern ein neues Gentoo (2006.0-miniinstall) aufgesetzt.  Der Rechner hat zwei Netzwerkschnittstellen: einen onboard-Chip fürs lokale Netz und eine RealTek-Karte zum DSL-Modem. Gentoo war schonmal drauf, aber ich habe die Platte gecrasht und mußte es jetzt eben auf eine neue Platte aufspielen.

Im Kernel sind die für die beiden Netzwerkschnittstellen zuständigen Module (skge für den onboard-Chip und 8130too für die RealTek-Karte) aktiviert, sie werden mir mit lsmod auch gezeigt. Solange ich nach der Installation des Basissystems noch weiteren Krimskrams (X-Server, Apache und einiges Weitere will man ja haben) geholt und gebaut habe, ging auch alles gut, sogar die TV-Karte wollte über xawtv schon funktionieren, Firewall (iptables) lief, so daß auch angeschlossene Netzwerkrechner online konnten.

Als ich den Rechner heute angestellt habe, ist er zunächst auch korrekt hochgefahren, und nach "pppoe-start" meldete er mir auch eine Verbindung; ifconfig hat ppp mit einer der üblichen t-online-Adressen betätigt. Aber ich bekam überhaupt kein Ergebnis mit Ping. Weder ins Internet (ich benutze für ping gerne ganz einfach www.google.de), noch zu einem lokalen Rechner, noch zu localhost. Mein Apache ist zwar gestartet (es existiert eine PID), trägt aber nichts in irgendein log ein, nichtmal die Startmeldung, und ist auch in keinem Browser erreichbar. dmesg meldet nichts Auffälliges, lspci zeigt beide Netzwerkschnittstellen an, ifconfig meldet die erwarteten Einträge, einzig netstat -ar zeigt gar nichts. Und in /var/log/messages steht auch nichts Auffälliges.

Da bin ich ziemlich ratlos, sowas übersteigt mein Erklärungsvermögen. Aber vielleicht hat jemand von euch noch eine gute Idee, was da defekt sein könnte?

[edit] der Treiber für die RealTek ist natürlich 8139too

Christoph S.

----------

## rincewind

Hallo !

Hast du mal versucht eine IP adresse anzupingen ? zb für Google :66.249.66.45

Wenn das klappt, poste mal deine /etc/resolv.conf evtl. stimmt was mit deiner Namensauflösung nicht.

T-Online Nameserver :217.5.115.7 

194.25.2.129 

Gruss Rince

----------

## Christoph Schnauß

hi,

ja, ich habe meine eigene Domain probiert, ergebnislos. Die /etc/resolv.conf hat die beiden t-online-Nameserver:

213.237.151.33

217.237.149.225

Außerdem: selbst wenn ich gar keine resolv.conf hätte, müßte ein

```
ping localhost
```

 funktionieren. Tut es aber nicht.

Christoph S.

----------

## blice

was sagen denn

/etc/conf.d/net***

ifconfig

rc-update -s

?

----------

## Christoph Schnauß

 *blice wrote:*   

> was sagen denn
> 
> /etc/conf.d/net***
> 
> ifconfig
> ...

 

Hm. An sich waren die Antworten dazu bereits in einer "Kurzform" in meiner Frage enthalten, aber ich liefere die "Langform" natürlich gerne nach. Wird bloß stellenweise bißchen viel Code.

Zuerst: Was du mit "etc/conf.d/net***" wissen möchtest, ist mir nicht ganz klar. Wenn du wissen möchtest, ob die Links für die beiden NICs in /etc/init.d gesetzt sind: das sind sie. /etc/conf.d/net enthält im Moment nur eine einzige Zeile:

```
config_eth0=( "192.168.0.1/24 brd 192.168.0.255" )
```

eth0 ist der onboard-Chip fürs lokale Netz, eth1 ist die RealTek-Karte fürs DSL-Modem, die soll ihre IP über DHCP erhalten und steht daher im Moment nicht drin in dieser Konfigurationsdatei. Ich könnte ihr immer noch eine IP verpassen, die dann, wenn pppoe-start aufgerufen wird, einfach überschrieben würde. Im Handbuch gibts auch noch den Hinweis, daß man

```
config_eth1=("noop" "dhcp")

fallback_eth1=("null" "apipa")
```

eintragen könnte. Hatte ich bereits, auf mein Problem hat das keinerlei Auswirkungen.

ifconfig liefert unmittelbar nach Systemstart folgendes:

```
eth0      Link encap:Ethernet  HWaddr 00:0E:A6:16:03:C1  

          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

          Interrupt:22 

lo        Link encap:Local Loopback  

          inet addr:127.0.0.1  Mask:255.0.0.0

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0 

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
```

Konsequenterweise ist hier eth1 nicht gelistet, was aber an dhcpcd liegt. Sobald ich pppoe-start aufgerufen habe, ändert sich die Ausgabe von ifconfig zu:

```
eth0      Link encap:Ethernet  HWaddr 00:0E:A6:16:03:C1  

          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

          Interrupt:22 

eth1      Link encap:Ethernet  HWaddr 00:50:BF:91:2A:24  

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:11 errors:0 dropped:0 overruns:0 frame:0

          TX packets:13 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:672 (672.0 b)  TX bytes:2916 (2.8 Kb)

          Interrupt:23 Base address:0xd400 

lo        Link encap:Local Loopback  

          inet addr:127.0.0.1  Mask:255.0.0.0

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0 

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

ppp0      Link encap:Point-to-Point Protocol  

          inet addr:84.190.217.87  P-t-P:217.0.116.3  Mask:255.255.255.255

          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1

          RX packets:3 errors:0 dropped:0 overruns:0 frame:0

          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:3 

          RX bytes:30 (30.0 b)  TX bytes:30 (30.0 b)
```

Jetzt hat also eth1 seine IP bekommen, und ppp0 existiert.

"rc-update -s" liefert eine längere Liste (übrigens kannte ich das Kürzel "s" bisher nicht, wenn ich die Übersicht brauchte, habe ich "rc-update -show" genommen)

```
             apache2 |      default                  

            bootmisc | boot                          

             checkfs | boot                          

           checkroot | boot                          

               clock | boot                          

            coldplug | boot                          

         consolefont | boot                          

         crypto-loop |                               

               cupsd |                               

          domainname | boot                          

              esound |                               

                 gpm |                               

              hdparm |                               

            hostname | boot                          

             hotplug |                               

           ip6tables |                               

            iptables |      default                  

             keymaps | boot                          

                lisa |      default                  

               local |      default nonetwork        

          localmount | boot                          

             modules | boot                          

            net.eth0 |      default                  

            net.eth1 |      default                  

              net.lo | boot                          

            net.ppp0 |                               

            netmount |      default                  

                nscd |                               

             numlock |                               

          postgresql |                               

             pwcheck |                               

             reslisa |                               

           rmnologin | boot                          

              rsyncd |                               

               samba |                               

           saslauthd |                               

                sshd |                               

           syslog-ng |      default                  

             urandom | boot                          

                 xdm |
```

Apache, PostgreSQL und lisa sind meine eigenen Zutaten, die brauche ich. Ob ich net.ethx in runlevel "boot" oder eben in "default" stopfe, spielt keine so große Rolle, Hauptsache, sie sind vorhanden.

Der Vollständigkeit wegen noch das, was ich in meiner Frage bereits angedeutet hatte.

- lspci liefert (Ausschnitt):

```
01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1)

02:05.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] (rev 12)

02:0a.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)

02:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)

02:0c.0 RAID bus controller: Silicon Image, Inc. PCI0680 Ultra ATA-133 Host Controller (rev 02)

02:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
```

Hier sind also beide Ethernet Controller aufgeführt. Daß es einen RAID-Controller gibt, ist vielleicht nicht ganz Standard, aber ich brauche das Teil, weil ich mehr als vier Platten im Rechner habe.

- dmesg liefert, nachdem pppoe-start gelaufen ist (Ausschnitt):

```
ACPI: PCI Interrupt 0000:02:0a.1[A] -> GSI 22 (level, low) -> IRQ 22

8139too Fast Ethernet driver 0.9.27

ACPI: PCI Interrupt 0000:02:0d.0[A] -> GSI 21 (level, low) -> IRQ 23

eth1: RealTek RTL8139 at 0xd400, 00:50:bf:91:2a:24, IRQ 23

eth1:  Identified 8139 chip type 'RTL-8139C'

skge eth0: enabling interface

eth1: link up, 100Mbps, full-duplex, lpa 0x41E1

skge eth0: Link is up at 100 Mbps, half duplex, flow control none

eth1: link up, 100Mbps, full-duplex, lpa 0x41E1

CSLIP: code copyright 1989 Regents of the University of California

PPP generic driver version 2.4.2
```

- cat /var/log/messages liefert als letztes:

```
Apr 21 22:02:23 pc1 ACPI: PCI Interrupt 0000:02:0a.1[A] -> GSI 22 (level, low) -> IRQ 22

Apr 21 22:02:23 pc1 8139too Fast Ethernet driver 0.9.27

Apr 21 22:02:23 pc1 ACPI: PCI Interrupt 0000:02:0d.0[A] -> GSI 21 (level, low) -> IRQ 23

Apr 21 22:02:23 pc1 eth1: RealTek RTL8139 at 0xd400, 00:50:bf:91:2a:24, IRQ 23

Apr 21 22:02:23 pc1 eth1:  Identified 8139 chip type 'RTL-8139C'

Apr 21 22:02:24 pc1 skge eth0: enabling interface

Apr 21 22:02:25 pc1 rc-scripts: Configuration not set for eth1 - assuming dhcp

Apr 21 22:02:25 pc1 eth1: link up, 100Mbps, full-duplex, lpa 0x41E1

Apr 21 22:02:26 pc1 skge eth0: Link is up at 100 Mbps, half duplex, flow control none

Apr 21 22:03:25 pc1 dhcpcd[8677]: timed out waiting for a valid DHCP server response

Apr 21 22:03:38 pc1 login(pam_unix)[8898]: session opened for user root by LOGIN(uid=0)

Apr 21 22:04:34 pc1 eth1: link up, 100Mbps, full-duplex, lpa 0x41E1

Apr 21 22:04:34 pc1 CSLIP: code copyright 1989 Regents of the University of California

Apr 21 22:04:34 pc1 PPP generic driver version 2.4.2

Apr 21 22:04:34 pc1 pppd[8987]: pppd 2.4.2 started by root, uid 0

Apr 21 22:04:34 pc1 pppd[8987]: Using interface ppp0

Apr 21 22:04:34 pc1 pppd[8987]: Connect: ppp0 <--> /dev/pts/0

Apr 21 22:04:34 pc1 pppoe[8991]: PADS: Service-Name: ''

Apr 21 22:04:34 pc1 pppoe[8991]: PPP session is 1481 (0x5c9)

Apr 21 22:04:35 pc1 pppd[8987]: PAP authentication succeeded

Apr 21 22:04:36 pc1 pppd[8987]: local  IP address 84.190.217.87

Apr 21 22:04:36 pc1 pppd[8987]: remote IP address 217.0.116.3
```

- netstat liefert, wie bereits ausgesagt, leider überhaupt nichts. Das heißt, es bleibt einfach "stehen", so daß ich es nach einer Minute mit Strg+C abbrechen muß.

- ping liefert, wie bereits ausgesagt, ebenfalls gar nichts. Egal, ob "ping localhost" oder "ping  66.249.85.104".

Das müßte jetzt als "Diagnosematerial" erstmal ausreichen. Wenn noch was fehlt, reiche ich es natürlich gerne nach.

Christoph S.

----------

## zworK

Auf den ersten Blick kann ich da nichts ungewöhnliches erkennen.

Wie sieht das denn mit deinen iptables Regeln aus ?

Ich würde mal deine Netzwerkdienste auf das Minimum runterfahren und iptables stoppen bzw ein kompletter flush um die Verdächtigen einzugrenzen.

Möglich dass sich da eine falsche Regel eingeschlichen hat ? Dass du nicht auf localhost pingen kannst, lässt mich das spontan vermuten.

----------

## Christoph Schnauß

 *zworK wrote:*   

> Auf den ersten Blick kann ich da nichts ungewöhnliches erkennen.
> 
> Wie sieht das denn mit deinen iptables Regeln aus ?

 

Die sind erstmal sehr einfach, weil eigentlich nur zu Prüfzwecken da, ob das vorgesehene Routing funktioniert. Im Moment sind es lediglich fünf Zeilen:

```
iptables -A FORWARD -i ppp0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

iptables -A FORWARD -i eth0 -o ppp0 -j ACCEPT

iptables -A FORWARD -j REJECT --reject-with icmp-net-prohibited

iptables -P FORWARD DROP

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
```

Aber du hast recht, da könnte das Problem liegen, schließlich hat alles noch funktioniert, ehe ich die aktiviert habe. Und an die Dinger hab ich überhaupt noch nicht gedacht.

Allerdings haben diese Regeln über ein Jahr lang mit meiner früheren Gentoo-Installation prima funktioniert und keinerlei Probleme verursacht.

Ähm ... bitte jetzt noch keine Diskussion darüber, daß das ja nun wirklich keine durchkonstruierte Firewall ist. Es ist lediglich das, was ich zum Testen auf Routingfähigkeit benutze, im endgültigen Betrieb muß da noch allerlei dazukommen.

 *Quote:*   

> Ich würde mal deine Netzwerkdienste auf das Minimum runterfahren und iptables stoppen bzw ein kompletter flush um die Verdächtigen einzugrenzen.

 

Gute Idee, werde ich probieren.

 *Quote:*   

> Möglich dass sich da eine falsche Regel eingeschlichen hat ? Dass du nicht auf localhost pingen kannst, lässt mich das spontan vermuten.

 

Naja - "nichts ist unmöglich". Aber hat sich denn bei iptables irgendwas verändert? Die Veränderungen im baselayout, die es vor rund einem halben Jahr gab, betreffen iptables nicht.

Christoph S.

----------

## zworK

 *Christoph Schnauß wrote:*   

> Die sind erstmal sehr einfach, weil eigentlich nur zu Prüfzwecken da, ob das vorgesehene Routing funktioniert. Im Moment sind es lediglich fünf Zeilen:
> 
> ```
> iptables -A FORWARD -i ppp0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
> 
> ...

 

Also an den FORWARD Regeln kann es nicht liegen. Und wenn das momentan deine einzigen sind, könntest du noch prüfen ob INPUT und OUTPUT auch auf ACCEPT stehen.

 *Christoph Schnauß wrote:*   

> 
> 
> Naja - "nichts ist unmöglich". Aber hat sich denn bei iptables irgendwas verändert? Die Veränderungen im baselayout, die es vor rund einem halben Jahr gab, betreffen iptables nicht.

 

Ich meinte damit einen Fehler im eigenen Regelwerk (s.o.). Ich durfte schon das eine oder andere mal in den Keller zu meinem Gentoo Router laufen, da ich bei meinen iptables Regeln mal zu schnell geschossen oder falsch gedacht habe.

Da die Einwahl erforlgreich ist, das Interface hoch kommt und dir eine IP zugewiesen wird, scheint die eigentliche Funktionalität ja gegeben zu sein. Traffic über ppp0 und eth1 ist, wie man sieht, auch schon geflossen.

Du könntest noch deine Routingtabelle prüfen

```
route -n
```

 und falls vorhanden/bearbeitet, die Dateien

```
/etc/hosts.allow

/etc/hosts.deny
```

----------

## Christoph Schnauß

 *zworK wrote:*   

> Wie sieht das denn mit deinen iptables Regeln aus ?

 

Wow, das wars tatsächlich, jedenfalls, was ping angeht. Ich habe iptables aus den runleveln herausgenommen, und dann funktioniert auch ping wieder:

```
PING localhost (127.0.0.1) 56(84) bytes of data.

64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.048 ms

64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.028 ms

--- localhost ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 1002ms

rtt min/avg/max/mdev = 0.028/0.038/0.048/0.010 ms

PING pc3 (192.168.0.3) 56(84) bytes of data.

64 bytes from pc3 (192.168.0.3): icmp_seq=1 ttl=128 time=0.178 ms

64 bytes from pc3 (192.168.0.3): icmp_seq=2 ttl=128 time=0.165 ms

--- pc3 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 999ms

rtt min/avg/max/mdev = 0.165/0.171/0.178/0.014 ms
```

"pc3" ist in diesem Fall ein Netzwerkrechner.

Allerdings mag die Kiste jetzt nicht online gehen, pppoe-start bricht nach einer Weile mit einer Fehlermeldung ab. Hm. Darf es eigentlich nicht, wenn gar kein iptables aktiv ist.

Meine Neuinstallation hat mir für iptables eine Version 1.3.5 geliefert. Leider weiß ich nicht mehr, was ich vorher hatte, als es mit meiner "alten" Installation auf der inzwischen zerschmissenen Platte noch keinerlei Probleme gab. Dabei habe ich mir eingebildet, ich hääte per Cronjob dafür gesorgt, daß ich mindestens einmal pro Woche das Gesamtsystem einschließlich aller Sourcen, also auch iptables, auf den jeweils aktuellen Stand gebracht hätte.

Na klasse, jetzt darf ich mich mal wieder mit iptables beschäftigen, statt meine alten und bewährten Regeln einfach weiter zu benutzen 

:-(

----------

## zworK

iptables speichert nach dem Stop standardmäßig alle Regeln in

```
/var/lib/iptables/rules
```

 und läd diese wieder beim Start. Unabhäng von den Regeln die du noch per Script definierst (die kommen einfach dazu).

Ein paar Einstellungen dazu gibts in

```
/etc/conf.d/iptables
```

Da du iptables per runlevel startest, ist es gut möglich das sich dort die problematischen Regeln festgesetzt haben.

Du könntest mal versuchen iptables zu stoppen, die Dateien aus 

```
/var/lib/iptables/
```

 an einen anderen Ort zu verschieben und iptables wieder zu starten.

So fängst du mit einem sauberen Regelwerk an und sparst dir das flushen von Hand.

Die DSL Einwahl sollte eigentlich unabhängig von iptables funktionieren.

----------

## Christoph Schnauß

[quote="zworK"]iptables speichert nach dem Stop standardmäßig alle Regeln in

```
/var/lib/iptables/rules
```

 und läd diese wieder beim Start. Unabhäng von den Regeln die du noch per Script definierst (die kommen einfach dazu).

Das passiert erst dann, wenn wenigstens einmal "iptables save" gefahren wurde.

 *Quote:*   

> Die DSL Einwahl sollte eigentlich unabhängig von iptables funktionieren.

 

Nun ja, "sollte"...

----------

## Nightfire

Hast du mal versucht im kernel einige Netzwerk optionen abzuschalten die du nich unbedingt brauchst?

----------

## zworK

 *Christoph Schnauß wrote:*   

> Das passiert erst dann, wenn wenigstens einmal "iptables save" gefahren wurde.

 

Ich habe grade nochmal nachgeschaut (iptables-1.3.4) und mein init Script richtig sich nach "SAVE_ON_STOP" in der Konfigurationsdatei, ein SAVE ist nicht nötig. Möglich das dies bei 1.3.5 anders ist. Jedoch benutze ich ein selbstgeschriebenes init Script um meine Regeln zu definieren und habe das von iptables ewig nicht mehr verwendet.

Wenn ich das richtig verstehe ist das Phänomen folgendes ? :

- iptables gestartet und die PPP Einwahl funktioniert, jedoch ist das Netzwerk tot.

- iptables nicht gestartet und PPP Einwahl scheitert, aber Netzwerk funktionsfähig.

Wenn dem so ist, könntest du die für den jeweiligen Fall aktiven Regeln anschauen

```
#iptables -L -v -t nat

#iptables -L -v -t mangle

#iptables -L -v -t filter
```

Ich bin jetzt auch nicht der Netzwerk und iptables Profi, vielleicht hat ja jemand anders noch eine gute Idee.

----------

## Nightfire

 *Quote:*   

> 
> 
> Wenn ich das richtig verstehe ist das Phänomen folgendes ? : 
> 
> - iptables gestartet und die PPP Einwahl funktioniert, jedoch ist das Netzwerk tot. 
> ...

 

Das hört sich so an als würde er die Netzwerkkarten vertauschen oder das device falsch mappen.

----------

## Christoph Schnauß

 *Nightfire wrote:*   

> Hast du mal versucht im kernel einige Netzwerk optionen abzuschalten die du nich unbedingt brauchst?

 

In meinem Kernel sind nur die Sachen drin, die ich wirklich brauche. Ich würde zum Beispiel sofort Konflikte bekommen, wenn ich sowohl 8139too (den brauche ich) wie auch 8139lin einbauen würde.

----------

## Christoph Schnauß

 *zworK wrote:*   

> mein init Script richtig sich nach "SAVE_ON_STOP" in der Konfigurationsdatei, ein SAVE ist nicht nötig

 

Das wirkt dann, wenn du den Rechner (oder das Netzwerk) neu bootest bzw. initialisierst. Das steht bei mir auch drin. 

 *Quote:*   

> Wenn ich das richtig verstehe ist das Phänomen folgendes ? :
> 
> - iptables gestartet und die PPP Einwahl funktioniert, jedoch ist das Netzwerk tot.
> 
> - iptables nicht gestartet und PPP Einwahl scheitert, aber Netzwerk funktionsfähig.

 

Ja, so sieht es momentan aus.

 *Quote:*   

> Wenn dem so ist, könntest du die für den jeweiligen Fall aktiven Regeln anschauen
> 
> ```
> #iptables -L -v -t nat
> 
> ...

 

Mal schauen.Ich werde erstmal aus einer gechrooteten Umgebung heraus (Start von der CD) ein paar Systembausteine erneuern, vielleicht hilft das schon.

Christoph S.

----------

## Christoph Schnauß

 *Nightfire wrote:*   

> Das hört sich so an als würde er die Netzwerkkarten vertauschen oder das device falsch mappen.

 

Nee, ich glaube, das kann "er" ausschließen ;-)

Christoph S.

----------

## Anarcho

Als Anmerkung:

```
iptables -A FORWARD -j REJECT --reject-with icmp-net-prohibited

iptables -P FORWARD DROP 
```

Das default auf DROP zu stellen hat in diesem Fall absolut keine Wirkung da er immer spätestens bei -j REJECT aussteigt. 

Was manchmal noch eine Fehlerquelle ist, wenn man multicast im kernel ausschaltet.

----------

## Christoph Schnauß

 *Anarcho wrote:*   

> Was manchmal noch eine Fehlerquelle ist, wenn man multicast im kernel ausschaltet.

 Du meinst, multicast sollte aktiviert sein?

----------

## Anarcho

 *Christoph Schnauß wrote:*   

>  *Anarcho wrote:*   Was manchmal noch eine Fehlerquelle ist, wenn man multicast im kernel ausschaltet. Du meinst, multicast sollte aktiviert sein?

 

Genau.

----------

## Christoph Schnauß

hallo nochmals,

ich finds ja gut, daß es allerlei beherzigenswerte Hinweise gegeben hat. Aber gebracht hat das alles leider nix, jedenfalls bisher.

Zunächst einmal: an iptables scheint es doch nicht gelegen zu haben. Ich hatte gestern zunächst die Situation, daß pppoe-start nicht funktionieren wollte, dafür aber Ping ins lokalen Netz ging. Daraufhin habe ich nochmal "pppoe-setup" ausgeführt, weil ich dachte, ich hätte meine Daten vielleichgt nicht korrekt eingetragen (obwohl sie in den Scripts richtig drinstanden). Siehe da, plötzlich meldete mir "pppoe-start" ganz fröhlich ein "Connected!".

Aber da funktioniert auf einmal wieder ping nicht mehr, und trotz der "connected"-Meldung ist auch kein emerge --sync möglich. iptables ist mit "emerge unmerge iptables" vorsichtshalber rausgeworfen worden.

Also habe ich nochmal von CD gestartet. Auf einmal wollte auch von der CD (2006.0-miniinstall oder Live-CD) keine Verbindung mehr aufgebaut werden. Also kalter Reset des DSL-Modems, Rechner eine halbe Stunde lang ausgeschaltet, kleinen Spaziergang eingeschoben ...

Dann Rechner wieder an, CD-Start, Laufwerk (ist in diesem Fall hdb1) gemountet und chroot gemacht. Verbindung ließ sich jetzt aufbauen, emerge --sync lief auch. Ich habe dann ppp, rp-pppoe und noch ein paar Kleinigkeiten neu geholt und meinen Kernel neu gebaut. Nach etc-update war natürlich erstmal einiges wieder "futsch" (unter anderem die Tastaturbelegung), aber damit kann man ja umgehen.

Nur hatte ich beim nächsten reboot ohne CD dasselbe Problem wieder: solange ich rppoe-start nicht aufgerufen habe, funktioniert ping ins lokale Netz, aber schon mein Apache will, obwohl er "läuft" und es eine PID gibt, nichts an einen beliebigen Browser ausliefern. Wenn ich "pppoe-start" eintippe, bekomme ich sehr schnell die Verbindungsmeldung, aber ping funktioniert dann wieder nicht mehr - und es ist auch nicht wirklich eine Verbindung vorhanden. Ich habe es mit "emerge dev-lang/php" probiert (brauche ich sowieso, habe ich aber noch nicht) und mit "emerge phppgadmin" (brauche ich ebenfalls). Es dauert rund sechs Minuten, bis eine Meldung wegen fehlgeschlagener Namensauflösung kommt. Das ist aber eine Fehlinterpretation: wenn keine Connection besteht, kann ja der Nameserver auch nicht erreicht werden.

Meine Hardware ist in Ordnung. Ich habe auf der ersten Platte (hda) noch ein Windows laufen, das ich im Moment grade benutze. Und das spricht genau dieselben NICs und dasselbe DSL-Modem an und verwendet selbstverständlcih die identischen Verbindungsdaten einschließlich der t-online-Nameserver.

Was bleibt da noch übrig?

Die logs liefern nichts Neues, was ich nicht bereits in diesem Thread angegeben hätte.

frustrierte Grüße

Christoph S.

----------

## blice

wenn alles andre in ordnung ist, dann probier mal /etc/ppp/resolv.conf zu löschen, und in /etc/resolv.conf fest dns einzutragen, und beim pppoe-setup die dns nicht auf "server" stellen, sonst überschreibt dir die nexte verbindung das wieder .

----------

## Christoph Schnauß

 *blice wrote:*   

> wenn alles andre in ordnung ist, dann probier mal /etc/ppp/resolv.conf zu löschen, und in /etc/resolv.conf fest dns einzutragen

 

Wie meinst du das? In /etc/resolv.conf stehen die beiden Nameserver von T-Online drin, also 217.237.151.33 und 217.237.149.225. Zusaätzlich habe ich noch 192.168.0.1 eingetragen, weil meine /etc/hosts die lokalen Rechnernamen und IP-Adressen auflistet.

 *blice wrote:*   

> und beim pppoe-setup die dns nicht auf "server" stellen, sonst überschreibt dir die nexte verbindung das wieder .

 

Auch das verstehe nicht nicht ganz. Bei pppoe-setup werde ich nach dem DNS-Server gefragt. Ich gebe da seit Jahren immer die T-online-Server an, wo man da "Server" eintragen könnte, weiß ich gar nicht.

Es könnte mir im Kernel noch irgendwas verrutscht sein (Kernel 2.6.15). Ich habe aber das .config-Script meiner vorherigen Installation, ehe mir die Platte kaputtging, genommen, das war ebenfalls 2.6.15, und der hat alles zu meiner Zufriedenheit erledigt. Aber es kann natürlich sein, daß bei einem vor wenigen Tagen vollkommen neu eingespielten System auch in den Kernelsourcen irgendetwas neu ist, was ich nicht gleich mitbekommen habe. Und ich verstehe nicht, wieso ppp nach pppoe-start sogar ein ping auf einen Netzwerkrechner bzw. auf die loopback-Adresse blockiert. Das kann nicht nur mit dem Resolver zusammenhängen. Ein lokaler DNS (z.B. bind), der dazwischenfunken könnte, ist derzeit nicht installiert.

Christoph S.

----------

## think4urs11

 *Christoph Schnauß wrote:*   

> In /etc/resolv.conf ... Zusaätzlich habe ich noch 192.168.0.1 eingetragen, weil meine /etc/hosts die lokalen Rechnernamen und IP-Adressen auflistet.... Ein lokaler DNS (z.B. bind), der dazwischenfunken könnte, ist derzeit nicht installiert.

 

Und genau deswegen ist es völlig sinnlos und kontraproduktiv deinen eigenen Rechner in resolv.conf einzutragen.

----------

## Anarcho

Wenn du den lokalen Rechner als DNS Server einträgst, aber dort keine DNS Server Daemon läuft dann klappt das natürlich nicht, denn die Datei /etc/hosts wird vor der Anfrage beim DNS Server überprüft ohne eine richtige DNS Anfrage zu starten. Wenn er aber nun einen Namen findet der nicht in der lokalen /etc/hosts steht versucht er sich mit dem lokalen DNS Server zu verbinden, was natürlich nicht geht.

Also schmeiss das mal wieder raus aus der /etc/resolv.conf

----------

## Christoph Schnauß

öhm ....

das mit dem Eintrag in meiner /etc/resolv.conf ist eigentlich ein unwichtiges Nebenthema. Richtig ist: das hat, sofern es der "Host" im lokalen Netz ist, keine Bedeutung und sollte bestenfalls gar nichts bewirken. Für Netzwerkclients, also auf "angeschlossenen" Rechnern, ist das aber sehr wohl ein wichtiger Eintrag.

Aber egal, das kann ich natürlich wieder streichen.

Im Moment funktioniert übrigens alles, das heißt, der Gentoo-Rechner kann online gehen, ping tut, was es soll, und iptables kann ich auch wieder einsetzen. Aber der Weg, auf dem ich das jetzt zustande gebracht habe, ist mehr als fragwürdig:

ich habe meinen Rechner über die CD gestartet und bin in eine chroot-Umgebung gegangen. Dann ein "emerge --sync", womit auch einige Kernelquellen (vanilla-sources) erneuert wurden. Dann habe ich meinen Kernel nochmal neu gebaut, was standardmäßig über die Schritte "make menuconfig" -> "make" -> "make modules_install" läuft. Es wurde nun neuerdings ein Kernel 2.6.17-rc2. Und natürlich habe ich meinen "alten" Kernel, den ich mit 2.6.15.1 gebaut hatte, nicht weggeschmissen, sondern für den Fall der Fälle nach "kernel_old" umbenannt und aufbewahrt.

Siehe da, der "neue" Kernel 2.6.17-dingsbums produziert mir eine "kernel panic". Na gut, sowas kennt man. Und genau dafür ist der alte Kernel ja noch vorhanden, damit man mit ihm wenigstens das System hochfahren kann. Hab ich auch gemacht. Und plötzlich war alles so, wie es eigentlich sofort hätte sein sollen: Rechner bootet, Internetverbindung läßt sich aufbauen, ping funktioniert in alle Richtungen, iptables ermöglicht das gewünschte Routing.

Aber auf welcher Grundlage? Ich fahre jetzt also mit meinem 2.6.15-Kernel hoch, aber in /lib/modules sind die mit 2.6.17-rc2 gebauten Module enthalten, und keine anderen (da hab ich versäumt, ein "backup" zu machen). Also lädt der 2.6.15-Kernel die Module dazu, die mit 2.6.17 gebaut wurden - und damit kann er plötzlich alles.

Das geht über meinen Horizont. Hat jemand eventuell ein Erkärungmodell dafür? Ich bin schließlich einer von denen, die nicht bloß endlich ein funktionierendes Sstem haben wollen, sondern auch verstehen möchten, warum plötzlich auf einer eigentlich "unmöglichen" Grundlage etwas funktioniert, was eigentlich zwingend eine "kernel panic" hervorrufen müßte.

----------

## think4urs11

 *Christoph Schnauß wrote:*   

> das mit dem Eintrag in meiner /etc/resolv.conf ist eigentlich ein unwichtiges Nebenthema. Richtig ist: das hat, sofern es der "Host" im lokalen Netz ist, keine Bedeutung und sollte bestenfalls gar nichts bewirken. Für Netzwerkclients, also auf "angeschlossenen" Rechnern, ist das aber sehr wohl ein wichtiger Eintrag.

 

wie meinen?

Einträge in der /etc/resolv.conf wirken *ausschließlich* auf die Maschine selbst. Jegliche sonstigen Rechner egal ob im gleichen LAN oder 'on the other side of the planet' interessieren sich für diesen Eintrag exakt gar nicht.

Für den Host selbst hat es aber (wenn als erstes eingetragen) zur Folge das sämtliche DNS-Requests erstmal dorthin gehen und in einen timeout laufen, d.h. unnötig verzögert werden. Als zweites oder drittes eingetragen ist es nicht ganz so schlimm aber genauso sinnlos. Weil ... wozu einen Nameserver dort eintragen von dem du weißt das er gar nicht existiert?

Einträge in /etc/hosts interessieren ebenfalls *ausschließlich* den Host selbst. Andere PC sehen diese Einträge nicht. (außer wenn z.B. dnsmasq läuft und dieser so konfiguriert wird das er diese Datei mitbenutzt fürs resolven).

Warum allerdings ein alter Kernel mit neuen Modulen plötzlich besser kann (bzw. überhaupt noch kann) als vorher mit den 'eigenen' ist mir um diese Uhrzeit auch zu hoch   :Rolling Eyes: 

----------

## Anarcho

Also ich bezweilfle stark das der alte Kernel die neuen Module läd. Das dürfte unmöglich sein. 

Und wenn du die alten Module nicht per hand gelöscht hast werden die auch nicht von einem anderen programm gelöscht. 

Falls tatsächlich keine alten Module mehr unter /lib/modules/ zu finden sind, dann dürfte lsmod auch eine leere Liste ausspucken.

Du kannst ja mal zum testen mit insmod versuchen ein modul des 2.6.17er kernels zu laden, dürfte nicht gehen:

insmod /lib/modules/2.6.16-rc2/kernel/.../blah.ko

Falls das klappt würde ich mal mit uname -a überprüfen welcher Kernel wirklich läuft.

Beim Thema resolv.conf schliesse ich mich meinem Vorredner an (siehe auch mein letzter)

----------

## Christoph Schnauß

hi,

 *Think4UrS11 wrote:*   

> Einträge in der /etc/resolv.conf wirken *ausschließlich* auf die Maschine selbst.

 Voll korrekt ;-) Und wenn nun die "Maschine selbst" ein Netzwerkclient ist, sucht der nach einem Kumpel im (lokalen) Netz, der diese Anforderung erfüllt - also diese IP hat. Bei meinem "LAN" findet er so einen Kumpel dann auch. *Quote:*   

> Für den Host selbst hat es aber (wenn als erstes eingetragen) zur Folge das sämtliche DNS-Requests erstmal dorthin gehen und in einen timeout laufen

 Schon gut. "wenn als erstes eingetragen" triifft eh nicht zu, aber das macht nichts.

 *Quote:*   

> wozu einen Nameserver dort eintragen von dem du weißt das er gar nicht existiert?

 Einfache Antwort, auch wenn sie dich nicht überzeugen wird: wenn ich lediglich mein lokales Netz auf Funktionsfähigkeit prüfen möchte und der Rechner selbst noch gar nicht online geschaltet wird, _kann_ das ziemlich hilfreich sein.

 *Quote:*   

> Einträge in /etc/hosts interessieren ebenfalls *ausschließlich* den Host selbst. Andere PC sehen diese Einträge nicht. (außer wenn z.B. dnsmasq läuft und dieser so konfiguriert wird das er diese Datei mitbenutzt fürs resolven).

 Jaein. Selbst angeschlossene Windows-Rechner können die /etc/hosts des "Netzwerkhost" zwar nicht einsehen oder darstellen, aber sie können, wenn der als DNS bei ihnen eingetragen ist, sehr wohl die dort vorhandenen Zuordnungen befolgen. Glaubs mir - bitte. Ich hab das in vielen Jahren mehrfach durch, wirklich verstanden hab ich es aber seit jeher nicht. - Richtig ist, daß diese Eintragung in der resolv.conf auf dem Netzwerkhost selber normalerweise Unsinn ist. Aber _darüber_ mag ich nicht weiter debattieren, das war im OP auch nicht meine Frage.

 *Quote:*   

> Warum allerdings ein alter Kernel mit neuen Modulen plötzlich besser kann (bzw. überhaupt noch kann) als vorher mit den 'eigenen' ist mir um diese Uhrzeit auch zu hoch  :roll:

 Siehst du (übrigens lag/liegt es nicht an der Uhrzeit). _Das_ beschäftigt mich nun allerdings sehr. Ich habe mittlerweile aus einer gechrooteten Umgebung heraus nochmal emerge --sync gefahren. Da hatte ich denn in den vanilla-sources neuerdings die Quellen für einen 2.6.17-r2-Kernel. Also hab ich meinen Kernel nochmal neu gebaut (und dafür die .config aus dem 2.6.15-Verzeichnis in das neue 2.6.17-r3-Verzeichnis rübergeschoben). Es sollte einigermaßen exakt derselbe Kernel werden wie der ursprünglich vor ein paar Tagen neu gebaute Kernel für 2.6.15.1. Und dieser neue 2.6.17er Kernel kanns nun auf einmal alles.

Schlußfolgerung: ich hätte mit dem Neubau meines Systems einfach noch zehn Tage abwarten sollen, bis ich mit emerge die Kernelquellen für 2.6.17-r2 bekomme, und nicht gleich mit einem Kernel 2.6.15.1 loslegen sollen. Dann hätte ih mir und euch diese ganze Debatte ersparen können - aber das lag bedauerlicherweise außerhalb der kalkulierbaren Möglichkeiten ;-)

Naja. Problem gelöst, wenn auch ohne Kenntnis der Ursachen, die anfangs zum "Problem" führten.

Grüße

Christoph S.

----------

## think4urs11

 *Christoph Schnauß wrote:*   

> Einfache Antwort, auch wenn sie dich nicht überzeugen wird: wenn ich lediglich mein lokales Netz auf Funktionsfähigkeit prüfen möchte und der Rechner selbst noch gar nicht online geschaltet wird, _kann_ das ziemlich hilfreich sein.

 

Irgendwie will mir trotzdem kein Anwendungsfall einfallen wo das in irgendeiner Weise bei irgendwas hilft.

 *Quote:*   

> Jaein. Selbst angeschlossene Windows-Rechner können die /etc/hosts des "Netzwerkhost" zwar nicht einsehen oder darstellen, aber sie können, wenn der als DNS bei ihnen eingetragen ist, sehr wohl die dort vorhandenen Zuordnungen befolgen. Glaubs mir - bitte. Ich hab das in vielen Jahren mehrfach durch, wirklich verstanden hab ich es aber seit jeher nicht.

 

Reden wir jetzt von Windows oder von Linux? Wobei ich selbst für Windows relativ sicher bin das du wirr redest... verwurschtest du hier evtl. DNS, WINS, NetBIOS und lmhosts mit ein bißchen netbios node-type zu einem bunten Eintopf?

Und ja im Gegensatz zu dir bilde ich mir ein Windows+Linux diesbezüglich sehr gut verstanden zu haben.

----------

