Hallo Leute,

nach einer Ewigkeit habe ich auch mal wieder ein scheinbar unlösbares Problem! Ich habe vor einer Weile ein Thinkpad x200 bekommen und darauf lief bis vor kurzem erstmal Windows 7. Nach ner Weile gings mir auf den Sack und Arch sollte wieder drauf, nur will das nicht, wie ich will.

Ich sitze hinter einem Router (Belkin N Router) der an ein Kabelmodem (Thomson THG570K von Primacom) steckt. Dieses scheint mich aber nicht ins Internet lassen zu wollen. Laut DHCP wird eine IP-Adresse zugewiesen, die Netzwerkgeräte und Dienste sind alle an und werden erkannt, ich habe blos keine Verbindung zum Netz. Mit einer UbuntuLiveCD funktioniert es, ohne dass ich irgendetwas einstellen musste; was ich ja auch nicht sollte, da das Notebook per Kabel am Router hängt!

Ich kenne mich in Sachen Netzwerk nicht so aus, darum weiß ich auch nicht genau wo ich anfangen soll. Einstellungen habe ich bisher nicht verändert, wodurch sich ein posten der confs hoffentlich erübrigt 😛 ifconfig spuckt auch keine Fehler aus; eth0, lo, wlan0 und wwan0 werden alle erkannt und scheinen zu funktionieren!

LG aus dem Osten
Daniel

EDIT:
ich weiß, ist jetzt schon lange her, aber da ich noch ein paar Installationen durch hab (neue HDD ftw :> ), und der 2.6.36-Kernel komischerweise nur bis zum reboot Hilfe gebracht hat, möchte ich den Walk-around für das Problem geben 🙂

Also es liegt wohl am Router/Modem/Netzbetreiber, denn bei meinen Eltern funzt es ohne zu meckern! Zuhause hat es mit einem manuellen 
dhcpcd eth0 --no-hook mtu
immer geklappt 🙂

LG aus dem verschneiten Osten
Daniel
Da man bei der Installation ein paar Sachen einrichtet gibt es schon dort Abweichung vom "nichtkonfigurierten Zustand". Relevant wären deshalb erstmal:
  • der Netzwerkbereich der /etc/rc.conf 
    […]
HOSTNAME="DEINHOSTNAME"
[…]
eth0="dhcp"
INTERFACES=(eth0)
[…]
gateway="default gw 192.168.0.1"
ROUTES=(gateway)
  • die /etc/hosts 
    <ip-address>   <hostname.domain.org>   <hostname>
127.0.0.1       localhost.localdomain   localhost DEINHOSTNAME
  • Und die Ausgaben von 
    ifconfig eth0 | grep "inet addr"
    und 
    route
danke für deine Antwort 🙂

/etc/rc.conf 
HOSTNAME="x200"

eth0="dhcp"
INTERFACES=(eth0)

gateway="default gw 192.168.2.1"
ROUTES=(!gateway)
das Gateway hab ich von Windows, macht aber keinen Unterschied zu ...0.1
Wenn ich bei Routes das gateway wieder aktiviere, bekomme ich einen Fehler (SIOCDELRT: No such process) beim network restart und hab trotzdem kein Inet 🙂

/etc/hosts 
127.0.0.1     localhost.localdomain      localhost       x200
Die Ausgabe von 
ifconfig eth0 | grep 'inet addr'
ist leer,
normal # ifconfig eth0 zeigt: 
Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:129 errors:0 dropped:0 overruns:0 frame:0
TX packets:269 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:45942 (44.8 Kb) TX bytes:33999 (33.2 Kb)
Memory:f2600000-f2620000
# route bringt: 
Kernel IP routing table
Destination     Gateway     Genmask     Flags Metric Red     Use Iface
da fehlt wohl irgendwas, oder? Nur was 😃

In der resolv.conf steht übrigens auch nichts, aber ein manuelles reinschreiben des Nameservers, der bei Ubuntu drin stand, hat auch nichts gebracht!

LG Daniel
Du hast keine IP-Adresse, keine MAC-Adresse und keine Route. Sicher das deine Netzwerkkarte korrekt erkannt wird? 
lspci | grep Ether
sollte den Namen deines Netzwerkchips bringen.
Daniel Schädlich schrieb das Gateway hab ich von Windows, macht aber keinen Unterschied zu ...0.1
Verstehe ich nicht. Unter Windos ist dein Gateway 192.168.2.1, oder 192.168.0.1?
Daniel Schädlich schrieb Wenn ich bei Routes das gateway wieder aktiviere, bekomme ich einen Fehler (SIOCDELRT: No such process) beim network restart und hab trotzdem kein Inet 🙂
Oder gerade deswegen. Ich komme zum Beispiel ohne nicht ins Internet…
Aber den Fehler kenne ich leider nicht.
Versuche mal händisch den DHCP-Server zu erreichen; 
dhcpcd -k eth0
dhcpcd -d eth0
Und poste da ggf. mal die Ausgaben, wenn du dadurch keine IP bekommen hast.

Ansonsten tut sich der dhcpcd etwas schwierig mitnicht ganz standardkonformen DHCP-Servern. Deshalb könntest du alternativ erstmal mit einer statischen IP arbeiten: 
ifconfig eth0 netmask 255.255.255.0 192.168.2.100
ping 192.168.2.1
(Der Router sollte antworten)
route add default gw 192.168.2.1
echo "nameserver 192.168.2.1" > /etc/resolv.conf
ping www.google.de
Schau mal, welche Methode funktioniert...
@mannohneschuh:
doch doch, die Netzwerkkarte wird erkannt: 
00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
Das Gateway unter Windows ist 192.168.2.1, aber auch wenn ich das nicht übernehmen können sollte, also 192.168.0.1 lasse, geht es aber nicht 🙂

Und die Mac-Adresse hab ich nur aus Faulheit einfach mit xx besetzt 😛 wollt nicht abschreiben...

@GerBra:
# dhcpcd -k eth0 gibt: 
dhcpcd: sending signal 1 to pid 1972
dhcpcd: waiting for pid 1972 to exit
#dhcpcd -d eth0 gibt: 
dhcpcd: eth0: executing '/usr/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT
dhcpcd: eth0: executing '/usr/lib/dhcpcd/dhcpcd-run-hooks', reason CARRIER
dhcpcd: eth0: broadcasting for a lease
dhcpcd: eth0:  sending DHCP_DISCOVER (xid 0x2b728093), next in 3.92 seconds
dhcpcd: eth0: offered 192.168.2.2 from 192.168.2.1
dhcpcd: eth0: sending DHCP_REQUEST (xid 0x2b728093), next in 3.37 seconds
dhcpcd: eth0: acknowledged 192.168.2.2 from 192.168.2.1
dhcpcd: eth0: checking for 192.168.2.2
dhcpcd: eth0: sending ARP probe (1 of 3), next in 1.06 seconds
dhcpcd: eth0: sending ARP probe (2 of 3), next in 1.32 seconds
dhcpcd: eth0: sending ARP probe (3 of 3), next in 2.00 seconds
dhcpcd: eth0: leased 192.168.2.2 for infinity
dhcpcd: eth0: adding IP address 192.168.2.2/24
dhcpcd: eth0: adding route to 192.168.2.0/24
dhcpcd: eth0: adding default route via 192.168.2.1
dhcpcd: eth0: writing lease '/var/lib/dhcpcd/dhcpcd-eth0.lease'
dhcpcd: eth0: executing '/usr/lib/dhcpcd/dhcpcd-run-hooks', reason BOUND
dhcpcd: eth0: MTU set to 1492
dhcpcd: forking to background
boar war das jetzt ne Arbeit, das abzutippen 😃

statische IPs würd ich nur ungern vergeben, da ich öfters mal ne LAN bei mir veranstalte und da immer mal andere Leute dabei sind! es muss doch auch ohne gehen...

Wenn ich den Router jetzt anpinge, kommt nur 
connect: Network is unreachable
macht es da einen Unterschied ob ich eine statische IP vergebe?

Danke für die Antworten und LG Daniel
Also dein dhcpcd -d Ausgabe sieht gut aus, du bekommst vom DHCP-Server 192.168.2.1 eine IP zugewiesen (192.168.2.2.), ebenso werden die Routen gesetzt.

Hast du gleichzeitig noch Networkmanager oder ein anderes Tool laufen?

laß dir nochmal der dhcpcd (erst -k dann -d, wie beschrieben) nochmal ne IP geben und pinge dann nochmal die 192.168.2.1 an. Wenn wieder die fehlermeldung kommt, dann bitte auch nochmal so:
ping -I eth0 192.168.2.1

Sind nach dem dhcpcd oben die Routen gesetzt?
route -n
Stehen dort zwei Einträge die in der Iface-Spalte eth0 haben? (Mußt nicht abtippen ;-) )
ich habe noch nichts installiert, das System befindet sich im Grunde im Ausgangszustand der Core-Installation! Ausser die paar config-Sachen der Installation!

# ping 192.168.2.1 bringt wieder network unreachable und # ping -l eth0 192.168.2.1 gibt: 
ping: bad preload value, should be 1..65536
# route -n gibt wieder nur ne leere Tabelle aus...
Hmm,

Welcher Kernel läuft bei dir? (uname -a sagt dir das).

Kannst du dein wireless Device abschalten am laptop(z.B. per Schalter)? Wenn ja versuch es mal ohne.

bad preload irritiert mich hier gewaltig. Evtl. verliert dein eth0 dauernd den Link zum Router (Kabel, ...)
Melde dich zum Bsp. auf ALT+F2 auch mal als root an und laß dort mal laufen:
mii-tool -vw
eth0 sollte dort auftauchen mit "link ok".

Wenn du auf tty1(ALT+F1) jetzt den dhcpcd Vorgang (-k und dann -d) machst (die Ausgabe bei -d ist immer gleich der, dioe du abgeschrieben hast?, also ohne erkennbare Fehlermeldungen), hat sich dann auf ALT+F2 bei den mii-tool Ausgaben etwas geändert?

Siehst du nach dem Ping-Versuch in der Ausgabe von dmesg am Ende irgendetwas was wie ein Fehler aussieht? Also "error" oder "failed"? Mußt nicht alles abschreiben...

Edit: Hast du bei: ping -I eth0 evtl. ein kleines L (wie Ludwig) geschrieben? Der Paranmeter sollte eihn großes i (-I wie Italien) sein
Edit2: Ich solte diese Dinger in block-Quotes setzen, ist aber von der Schrift her schwer zu erkennen...
alsooooo

- der Kernel ist die 2.6.33..

- abschalten des wireless device bringt nichts

- also mii-tool -vw bringt: 
SIOCGMIIREG on eth0 failed: Input/Output error
12:17:xx eth0 negotioated 100baseTx-FD flow-control, link ok
SIOCGMIIREG on eth0 failed: Input/Output error
12:17:xx eth0: no link
und das wieder holt sich immer und immer wieder! Verändert hat sich da nix.
Genausowenig wie bei dhcpcd -d! dmesg haut auch nix raus mit Fehlermeldung oder ähnlichem!
Bin mal kurz weg.
Versuche mal ein anderes Kabel/Port am Router und schau mal ob alle Kabel richtig gesteckt sind. Auch ob an Laptop und Router duie LEDs für die Ports brennen (wenn vorhanden).

Du nutzt für die Karte das e1000e Modul, richtig? lspci -k sagt dir das bei kernel driver in use: für die Netzkarte.

Die Usache ist das der Link dauernd wegbricht (Hadware oder Modul/kernel-Problem)
jap, das e1000e-Modul! Und das ändern der Ports am Router hat nichts gebracht 🙁 Warum funzt es denn bei Ubuntu und bei Arch nicht *grrr*
Es gibt etliche Berichte über Probleme mit diversen 2.6.35 Arch-Kernelrevisionen und eine Suche nach e1000e im englischen Forum zeigen auch einige Posts mit Problemen mit dem Kernel des aktuellen Install-ISOs und diversen Chipsatz-Revisionen.

Hast du Erfahrung wie du z:b. von der Ubuntu-Live-CDs ein Chroot auf dein Archlinux machst und dort das System aktualisieren kannst? Wenn ja, dann würde ich vorschlagen auf den 2.6.36 aus testing zu aktualisieren.

Alternativ kannst du auch nochmal versuchen die MTU zu reduzieren. Also nach dem Start: 
ifconfig eth0 mtu 576
dhcpcd eth0
ping 192.168.2.1
Evtl. verhindert die kleine MTU den Linkverlust zum Router (mii-tools)

Edit: Nutzt du bei Archlinux bzw. Ubuntu i686 oder x64_86 (also 32 oder 64 bit)?
GerBra schriebEs gibt etliche Berichte über Probleme mit diversen 2.6.35 Arch-Kernelrevisionen und eine Suche nach e1000e im englischen Forum zeigen auch einige Posts mit Problemen mit dem Kernel des aktuellen Install-ISOs und diversen Chipsatz-Revisionen.

Hast du Erfahrung wie du z:b. von der Ubuntu-Live-CDs ein Chroot auf dein Archlinux machst und dort das System aktualisieren kannst? Wenn ja, dann würde ich vorschlagen auf den 2.6.36 aus testing zu aktualisieren.

Alternativ kannst du auch nochmal versuchen die MTU zu reduzieren. Also nach dem Start: 
ifconfig eth0 mtu 576
dhcpcd eth0
ping 192.168.2.1
Evtl. verhindert die kleine MTU den Linkverlust zum Router (mii-tools)
Wäre sorum nicht sinniger:
dhcpcd eth0
ifconfig eth0 mtu 576
ping 192.168.2.1
Das DHCP liefert doch einen eigenen mtu-Wert welcher dann den gesetzten überschreibt.

Grüße
@Bomb: hast recht!
ne, mit chrooten kenne ich mich nicht aus! Hab das zwar einmal gemacht, als ich mal gentoo installiert hatte, aber keine Ahnung mehr 🙂

Verringerung des MTU brachte auch nichts!

Evt. werde ich eben doch einfach per WLan ins Inet gehen (sofern das funzt, die Treiber waren zum Glück im Core-Image dabei) und dann hoffen dass es mit Wicd oder dem Networkmanager klappt... Wollte zwar eigentlich wissen wo der Fehler liegt und wie man ihn beheben kann, aber wenn das scheinbar nicht möglich ist 😃
Edit: Bei dem MTU-test hast hast du noch Bomb's Post gelesen? (Fehler von mir)

Wlan wäre eine Alternative (dann könntest du dein System zum einen aktualisieren (auf aktuell 2,6,35), bei Problemen ggf. auf den Testing-Kernel.

Du könntest auch den Testing-2.6.36 downloaden, auf z.B. einen USB-Stick oder CD packen, diese in Arch einhängen und den Kernel so aktualisieren. Interessant wäre ja erstmal nur, ob Kernel > 2.6.33 das Problem beheben.

http://ftp.hosteurope.de/mirror/ftp.archlinux.org/testing/os/i686/kernel26-2.6.36-3-i686.pkg.tar.xz

Hier bekommst du für i686 den Testing-kernel.

In dein Arch-System kopieren, dann ein: 
pacman -U /pfad_zum_kernel_gz/kernel26-2.6.36-3-i686.pkg.tar.xz
bzw. bei Meldungen über Abhängigkest-probleme (sollten vernachlässigbar sein)
pacman -Udf /pfad_zum_kernel_gz/kernel26-2.6.36-3-i686.pkg.tar.xz
hm okay das hat funktioniert 😃 hoffentlich macht der testing-kernel keine Probleme 🙂

Also das Problem lag nun entweder am alten Kernel oder an dem paket linux-firmware, das scheint ja einiges zu ersetzen!

na gut, dann ist das soweit gelöst; ich danke für die umfangreiche hilfe 🙂 endlich kann ich wieder arch benutzen 🙂
Freut mich!

Der Testing-Kernel sollte keine Probleme mit den "normalen" Paketen/bzw.Upgrades machen, ich schätze das er gerade wegen den Problemen mit diversen Intel-Net-Chipsätzen sowieso bald nach Core kommen wird.

Mußtest du/hast du das Firmware-Paket auch auf (testing) aktualisiert? Soweit ich weiß braucht man für den e1000e keine Firmware, bin aber nicht sicher...

Bei viel Experimentierfreude könntest du ja auch nochmal schauen, ob der core-Kernel (2.6.35) auch funktionieren würde, dann könntest du aktuell auf testing-Pakete verzichten. Aber: nur weil du den Kernel aus testing benutzt heißt nicht zwangsläufig daß du auch das testing-repo aktiviert haben mußt.

SCNR: Immerhin sind wir - mit Hilfe aller Beteiligten - unter 24h bis zur Problemlösung geblieben, also keine Regressansprüche wegen Verstöße gegen ein SLA oder schlechter Reaktionszeit....
ne, das firmware war ein community paket glaub ich! Ne den 2.6.35 will ich jetzt nicht noch probieren 🙂 wenn der 2.6.36er eh bald nach core kommt...

hehe ich weiß auch so, dass dieses forum immer hilfe bietet! und wenn man mal länger als 24h warten muss, dann kann man da imho niemandem einen vorwurf machen 🙂