Arch Linux

Verbindung mit Internet funktioniert nicht

walter

Hallo liebe Leute,

ich habe auf meinem alten Notebook Arch-Linux von CD installiert [Amilo m 7400, archlinux-2010.05-core-i686]. Die Installation verlief ohne Probleme.
Mein Internetzugang läuft über ein Kabelmodem direkt zu dem Laptop, kein Wlan. Die gleiche Verbindung funktioniert bei meinem PC einwandfrei.
Nach der Installation wollte ich die Datenbank mit Pacman aktualisieren.
Im folgenden habe ich einmal alle Ausgaben aufgelistet die event. hilfreich sein könnten.

#pacman -Sy

dabei trat folgender Fehler auf

:: Synchronisiere Paketdatenbanken...
Fehler: Konnte Datei 'code.db.tar.gz' nicht von ftp.spline.inf.fu-berlin.de übertragen : Transient resolver failure
Fehler: Konnte core nicht aktualisieren (Transient resolver failure)
...
Fehler: Konnte keinerlei Datenbanken synchronisieren

Der Code-Schnipsel ist nur repräsentativ. Diese Fehlermeldungen treten auch für 'extra' und 'community' auf. Ich habe auch andere Server ausprobiert, sowohl ftp als auch http.
Hier sind Ausschnitte der folgenden .conf-Dateien

rc.conf

 
#HARDWARE
MOD_AUTOLOAD="yes"
MODULES=()
USELVM="no"

#NETWORKING
HOSTNAME="myhost"
eth0="dhcp"
INTERFACES=(eth0)
gateway="default gw 192.168.0.1"
ROUTES=(!gateway)

#DAEMONS
DAEMONS=(syslog-ng network netfs crond)

resolv.conf

 
# Generated by dhcpcd
# /etc/resolf.conf.head can replace this line
# /etc/resolf.conf.tail can replace this line

... sonst gibt es keine weiteren Einträge. Ich denke das ich meine Daten über DHCP beziehe, daher sollte ja hier eigentlich etwas drin stehen (nameserver <ip-Adresse>).

nach der Abfrage

 
#ifconfig -a

gibt er mir Folgendes aus

 
eth0     Link encap:Ethernet   HWaddr 00:0A:E4:20:xx:xx
            UP BROADCAST MULTICAST MTU:1500 Metric:1
            RX packets:6680 errors:0 dropped:0 overruns:0 frame:0
            TX packets:277 errors:0 dropped:0 overruns:0 carrier:0
            collisions:0 txqueuelen:1000
            RX bytes:448982 (438.4 Kb)   TX bytes:35449 (34.6 Kb)
            interrupt:10

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)

Ping auf www.google.com / 209.85.148.103

 
#ping -c 3 www.google.com
ping: unknown host www.google.com
#ping -c 3 209.85.148.103
connect: Network is unreachable

Für 127.0.0.1 / localhost funktioniert es einwandfrei.

Wenn ich die routing table abfrage, zeigt er mir keinerlei Einträge. Sie ist leer.

 
#route -n
Kernel IP routing table
Destination     Gateway     Genmask     Flags     Metric     Ref     Use     Iface

Ich sitze jetzt schon eineinhalb Tage an dem Problem, und habe das Gefühl, den Wald vor lauter Bäumen nicht mehr sehen zu können.
Es wäre nett wenn ihr mir helfen könntet.

Gruß Walter

GerBra

Sicher, daß dein Kabemodem einen DHCP-Server hat? Wie arbeitest du den an dem PC, mit statischer IP oder auch per DHCP?

Die rc.conf sieht ok aus, du kannst es mit dhcp auch explizit versuchen:
dhcpcd eth0
Ein DHCP-Server sollte dir nun eine IP zuweisen (was bisher laut ifconfig-Ausgabe ja nicht geschehen ist) und auch einen Nameserevr eintragen. Oder halt Fehelrmeldungen werfen (ggf. auch versuchen: dhcpcd -d eth0 für debug-meldungen)

Ansonsten kannst du auch eine statische IP-Zuweisung versuchen, dafür mußt du dein IP-Segment und die Gateway-IP/Nameserver-IP wissen. Nehmen wir mal 192.168.0.1 an für das Kabelmodem:
ifconfig eth0 192.168.0.100 up
(du hast jetzt die 192.168.0.100 als IP)
ping 192.168.0.1
(du solltest dein kabelmodem anpingen können)
route add default gw 192.168.0.1
(Pakete nach außerhalb übers Kabelmodem)
ping -c 3 209.85.148.10
(sollte jetzt auch nach außen gehen)
echo "nameserver 192.168.0.1" >> /etc/resolv.conf
(trägt das kabelmodem auch als DNS-Server ein)
ping -c 3 www.google.com
(solte nun funktioneiren)

sky-hawk

Es scheint so, als würde deiner Netzwerkarte keine Adresse zugewiesen,. Gründe können u.a. fehlerhaftes Kabel sein oder dass dein Modem kein DHCP-Server bereitstellt. Probier es doch einmal mit

ifconfig eth0 192.168.0.100
route add default gw 192.168.0.1
echo "nameserver 192.168.0.1" > /etc/resolve.conf

Gruß

Edit: Sorry für den "Doppelpost"

Edward d'Eath

walter schriebHallo liebe Leute,

rc.conf

 
#HARDWARE
MOD_AUTOLOAD="yes"
MODULES=()
USELVM="no"

#NETWORKING
HOSTNAME="myhost"
eth0="dhcp"
INTERFACES=(eth0)
gateway="default gw 192.168.0.1"
ROUTES=(!gateway)

#DAEMONS
DAEMONS=(syslog-ng network netfs crond)

Moin,

im Bereich Networking der rc.conf hat sich vor kurzem was geändert. Du müßtest eine /etc/rc.conf.pacnew mit der neuen Struktur in Deinem System haben. Siehe hier:

https://wiki.archlinux.de/title/Rc.conf

Hth,

Edward

SiD

Dazu müsste aber erstmal das Update funktionieren.
Die Installations CDs enthalten ja noch ältere Pakete.

Svlad Cjelli

Ich glaube fast ich habe dasselbe Problem. Ich habe ein Modem von Unitymedia (Motorola), an das ein D-Link-Router angeschlossen ist.

Bei mir wird nichtmal der Ethernet-Controller erkannt 🙁

Nutze DHCP

walter

Hallo,

vielen Dank erst einmal für eure Antworten.
Ich beziehe meine Daten über das DHCP. Habe das Problem aber immer noch nicht gelöst.
Ich werde mal meine Schritte und Ausgaben nacheinander posten, damit es gut nachvollziehbar ist was ich gemacht habe.

Ich habe, wie beschrieben

#dhcpcd -d eth0

ausgeführt. Ergebnis:

dhcpcd: version 5.2.2 starting
dhcpcd: eth0: executing '/usr/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT
dhcpcd: eth0: executing '/usr/lib/dhcpcd/dhcpcd-run-hooks', reason CARRIER
dhcpcd: eth0: reading lease '/usr/lib/dhcpcd/dhcpcd-eth0.lease'
dhcpcd: eth0: discarding expired lease
dhcpcd: eth0: broadcasting for a lease
dhcpcd: eth0: sending D(1)CP_DISCOVER (xid 0xf1f8xxxx), next in 3.92 seconds          ;(1) J od. H, kann ich nicht mehr prüfen
dhcpcd: eth0: sending DJCP_DISCOVER (xid 0xf1f8xxxx), next in 7.96 seconds
dhcpcd: eth0: offered 31.16.xx.xx from 83.169.185.130
dhcpcd: eth0: sending DHCP_REQUEST (xid 0xf1f8xxxx), next in 3.49 seconds
dhcpcd: eth0: acknowledged 31.16.xx.xx from 83.169.185.130
dhcpcd: eth0: checking for 31.16.xx.xx
dhcpcd: eth0: sending ARP probe (1 of 3), next in 1.44 seconds
dhcpcd: eth0: sending ARP probe (2 of 3), next in 1.92 seconds
dhcpcd: eth0: sending ARP probe (3 of 3), next in 2.00 seconds
dhcpcd: eth0: leased 31.16.xx.xx for 1800 seconds
dhcpcd: eth0: adding IP address 31.16.xx.xx/21
dhcpcd: eth0: adding route to 31.16.64.0/21
dhcpcd: eth0: adding default route via 31.16.71.254
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 576
dhcpcd: eth0: forking to background

Also wenn ich das richtig verstehe hat er nach dem Ausführen von dhcpcd ein paar Anfragen gestellt und von dem DHCP-Server? ...130 eine IP 31... angeboten bekommen.
Die hat er dann mit ARP zugeordnet und übernommen, sowie zwei routen, die ich nicht auseinander zu halten weiß.

Danach habe ich nochmal die Netzwerkschnittstellen abgefragt [Veränderung: UP BROADCAST RUNNING MULTICAST]
Allerdings wurde die IP Adresse der eth0 Schnittstelle nicht zugeordnet. Ratlosigkeit.

#ifconfig -a

eth0     Link encap:Ethernet   HWaddr 00:0A:E4:20:xx:xx
            UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
            RX packets:12770 errors:0 dropped:0 overruns:0 frame:0
            TX packets:448 errors:0 dropped:0 overruns:0 carrier:0
            collisions:0 txqueuelen:1000
            RX bytes:861620 (841.4 Kb)   TX bytes:57900 (56.5 Kb)
            interrupt:10

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)

anschließend habe ich die resolv.conf überprüft, und dhcpcd hat mir zwei Nameserver reingeschrieben

#nano resolv.conf
# Generated by dhcpcd from eth0
# /etc/resolf.conf.head can replace this line
nameserver 83.169.185.161
nameserver 83.169.185.225
# /etc/resolf.conf.tail can replace this line

Die routing table hat sich nicht verändert, sie ist immer noch leer.

Ich habe die Zuweisung der statischen IP, so wie beschrieben, durchgeführt. Allerdings habe ich noch nicht ganz begriffen, was ich da eigentlich gemacht habe.
Besonders da ich mit dem Adressbereich von 192.168.... und der tatsächlichen IP 31.... durcheinander komme.

#ifconfig eth0 192.168.0.100

... funktioniert.
wenn ich jetzt die Netzwerkschnittstellen abfrage, zeigt er mir

...
inet addr:192.168.0.100 Bcast:192.168.0.255 Mask:255.255.255.0

an. Das default gateway habe ich auch wie beschrieben zugewiesen

#route add default gw 192.168.0.1

wenn ich es allerding versuche anzupingen, kommt folgende Fehlermeldung

From 192.168.0.100 icmp_seq=1 Destination Host Unreachable

hier nochmal die routing table

#route -n
Kernel IP routing table
Destination     Gateway       Genmask             Flags     Metric     Ref     Use     Iface
192.168.0.0     0.0.0.0     255.255.255.0            U         0      0     0       eth0
0.0.0.0     192.168.0.1     0.0.0.0                  UG       0     0      0       eth0

Ich hoffe, ich habe mir hier nicht völligen Unsinn zusammen geschrieben.

Gruß Walter

GerBra

Hmm, die Ausgaben des manuellen dhcpcd sehen eigentlich vollkommen ok aus...

Eine andere Möglichkeit gibt es AFAIK auch nicht, soweit ich mich mit Kabelmodems auskenne. Die Dinger sind ja per se erstmal nur wirkliche Modems, zu bekommst also von deinem Kabelprovider eine IP zugewiesen welche dann genau das Endgerät erhält welches am Modem angeschlossen ist. Das Modem ist also nur Durchschleifer zwischen zwei unterschiedlichen Techniken, eben Ethernet und (Fernseh)Kabel.

Welches Modell des Maodems ist das denn? Sehe ich das richtig: Du kannst nur mit jeweils einem Rechner gleichzeitig ins Internet (der, der gerade am Modem hängt, also kein Router/Switch mehr dazwischen)?
Vergleiche oder poste dochmal vom anderen PC die IP-Settings (ipconfig/all bei Windows, ifconfig -a und route -n bei Linux). Dieser PC sollte eigentlich die gleiche IP haben wie der dhcpcd-Aufruf beiArchlinux es auch machen wollte (aber nicht gemacht hat). Oder zumindest sollte die IP aus dem Block 31.16.xx.xx kommen.

Also dhcpcd macht ja alles richtig (laut Debug-Ausgabe), also IP beziehen, Routen setzen und DNS eintragen. Übrig bleibt aber scheinbar nur der /etc/resolv,conf Eintrag.
Es könnte sein daß evtl. noch ein dhcpcd-Prozeß lief (der, der über die rc.conf als Daemon gestartet wird) und dir ungünstig reingepfuscht hat. Setze mal jeweils ein ! vor network und netfs in der rc.conf->DAEMONS, sodaß also kein Netzwerk gestartet wird. Reboot.

Dann versuche nochmal dhcpcd per Hand, dafür wirst du brauchen:

ifconfig eth0 up
dhcpcd -d eth0

Und schaue dann mal recht schnell, ob ifconfig bzw. route was Plausibles sagen.

Ein Blick ist nach dieser Aktion auch nochmal die dmesg-Ausgabe wert (dmesg als Befehl), ob die Netzwerkverbindung evtl. sofort danach zusammenbricht oder andere offensichtliche Fehler im Zusammenhang mit Netzwerkgeräten...

Das Modem muß seitens dir nicht irgendwie konfiguriert werden (evtl. das berechtige MAC-Adressen einzutragen sind ähnlich wie man das bei WLAN machen kann) usw...
War dieser Laptop schonmal (mit anderen Linuxen oder Windows) über dieses Kabelmodem am Internet?

Und zu dieser Zuweisung einer festen IP statt dhcpcd: Da hast du nichts falsch gemacht oder mißverstanden, bei dieser Technik wird/kann mein Vorschlag so nicht funktionieren. Bei "normalen" Routern/DSL-Modems bekommen die Clients vom Router eine IP aus sog. privaten IP-Segmenten zugewiesen (eben z.B. aus dem 192.168.x.x Bereich), nur der Router/das Gateway hat eine "richtige", öffentliche IP und setzt Pakete der Clients aus dem privaten Bereich zum Transport über/mit der öffentlichen IP um. Deine PCs bekommen aber AFAIK direkt die öffentliche IP, da ist mit den privaten IPs nichts statisch zuzuweisen.

[gelöscht]

Moin,
hast du das Modem eigentlich neu gestartet, nachdem du vom PC auf Notebook gewechselt bist? Soweit ich mich erinnere merken sich diese Modems die MAC des Netzwerkadapters, der zuerst damit verbunden war. Erst nach einem Neustart vom Modem kann man ein anderes Gerät damit verbinden. Wobei dann ja dhcpcd auch schon nicht funktionieren dürfte.

walter

Guten Tag an alle,

@GerBra, Fooo

GerBra schrieb Sehe ich das richtig: Du kannst nur mit jeweils einem Rechner gleichzeitig ins Internet (der, der gerade am Modem hängt, also kein Router/Switch mehr dazwischen)?

Genau, kein Switch, kein Router. Nur eine direkte Verbindung zu dem jeweils angeschlossenen Rechner.
Das Kabelmodem ist vom Modell: Thomson THG540K
Beide Rechner haben unterschiedliche IP-Adressen, doch sind beide im gleichem Block 31.16.xx.xx

GerBra schrieb War dieser Laptop schonmal (mit anderen Linuxen oder Windows) über dieses Kabelmodem am Internet?

Ja. Ich habe Vorgestern, ohne konkreten Verdacht, nach der ersten "problematischen" Installation von Arch, Ubuntu installiert um die Netzwerkfähigkeit zu testen. Da gab es keine Probleme. Vor einigen Monaten lief auch WinXP drauf.
Auf meinem PC läuft momentan (X)ubuntu, dort wird auch alles vernünftig zugewiesen.

Fooo schrieb hast du das Modem eigentlich neu gestartet, nachdem du vom PC auf Notebook gewechselt bist? ...

kurz vorne weg: ich habe in der Vergangenheit das Kabel immer zwischen den beiden Rechnern rum-gesteckt, das funktionierte.
Ich hatte gestern so etwas Ähnliches im Englischsprachigen Wiki gelesen:
https://wiki.archlinux.org/index.php/Configuring_Network#Swapping_computers_on_the_cable_modem
auch wenn es nicht das ist was du meinst. Ich hatte das Modem vom Strom getrennt und anschließend das Notebook hochgefahren, doch funktionierte nicht.
Noch mal zu den IP-Adressen der beiden Rechner: Da ja beide über unterschiedliche verfügen, müssen sie sich ja auch mit ihrer jeweiligen Hardwareadresse dort "angemeldet" haben, wo auch immer (DHCP-Server)? Was dann ja zwangsläufig bedeutet, das es zu so einem Konflikt nicht kommen kann, oder? [HW-Adressen wurden nicht verändert]

Ich habe auch die Dienste abgeschaltet, neu gebootet, dhcpcd gestartet (wie beschrieben), Doch kam auch leider hier keine Änderung.
Was ich allerdings seltsam fand, das diesmal auch keine Einträge der Nameserver in der resolv.conf standen.
Ich muss noch einmal nachdenken was ich anders gemacht habe, und es ggf. wiederholen.

Hier sind kleine Auschnitte das dmesg-Aufrufs

#dmesg
...
lib80211: common routines for IEEE802.11 drivers
lib80211-crypt: registered algorithm 'NULL'
...
ieee80211: 802.11 data/management/control stack, git-1.1.13
...
ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, git-1.2.2
...
b44.c:v2.0
eth0: Broadcom 44xx/47xx 10/100BaseT Ethernet 00:0a:e4:xx:xx:xx
...
ipw2100: Detcted Intel PRO/Wireless 2100 Network Connection
ipw2100 0000:xx:xx.x: firmware: requesting ipw2100-1.3.fw                                            ;die Hexwerte ließ ich weg, da ich nicht weiß was sie bedeuten
 clean.
...
;hier zwischen gibt es einige Einträge, in denen der ipw2100-Treiber versucht die nicht vorhandene eth1 Schnittstelle zu initialisieren
;und dann wiederholt sich mehrmals diese Meldung
...
b44: eth0: Link is up at 100 Mbps, full duplex.                             
b44: eth0: Flow control is off for TX and off for RX                                                ;Rx = Reciever = Empfänger; Tx = Transmitter = Sender  
b44: eth0: powering down PHY                                                                        ;PHY = physical layer
b44: eth0: Link is down.

;b44 = Treiber

...die, die ich für eventuell wichtig hielt. So richtig schlau werde ich daraus nicht.
Es gibt Einträge dazu, ich werde gleich noch mal lesen.

Gruß Walter

GerBra

Hmm....

Meine Vermutung wäre, daß die Netzkarte während der Nutzung den Link zum Modem verliert, und das halt immer/oft. Link verlieren wäre wie das Netzkabel ziehen, auch dann sind erstmal alle "Einstellungen" (IP,Routen,usw.) weg. Dafür sprechen würde das eben keine Routen gesetzt sind, aber manchmal der /e/resolv.conf noch DNS-Server hat.

Prüfen kannst du das u.a. (evtl. siehst du ja auch LEDs an Karte und Modem an/ausgehen): Du startest nach dem Boot (netzdaemons immer noch abgestellt) auf z.B. TTY1:

mii-tool -vw

Das zeigt dir nun ob ein link besteht, welche Geschwindigkeit usw.
Auf einem anderen TTY kannst du nun testen: ifconfig eth0 up bzw. down werden hier Ausgaben produzieren, auch ein Ab/Anstecken des Kabels. Zum Schluß bitte wieder mit ifconfig eth0 up einen Link herstellen.
Beobachte dochmal einige Minuten ohne das du die Netzkarte dann irgendwie "nutzt" ob der aktive Link stabil bleibt, oder ob es z.B. wegbricht, wieder da ist usw.

Danach (Der Link sollte immer noch da sein, ifconfig sollte eth0 UP zeigen) teste nochmal ein dhcpcd -d eth0 und beobachte, ob auf TTY1 während/nach des Aushandelns der IP der Link stabil bleibt oder auch wegbricht (dafür würde dein dmesg-Auszug zu b44 passen). Wenn der Link wegbricht/down dann mußt du halt wieder ifconfig eth0 up und nochmal dhcpcd. Schau mal. ob du das Wegbrechen(wenns denn passiert) reproduzieren kannst.

Ansonsten: Kernel ist wohl der 2.6.33 (uname -a)?
Die Ursache oder Abhilfe: Hmm, etwas ratlos. Es liegt soweit ich sehe auf jedenfall nicht an dir. Das dhcpcd eth0 machen ähnlich genauso Windows als auch Ubuntu, nur dort funktioniert es halt. Bei Ubuntu wäre die Kernelversion evtl. mal interessant...
Wir hatten hier die letzten Tage mehrere Threads mit Problemen mit Broadcom-Ethernet-Devices, die alle etwas ungewöhnlich waren (müßte eigentlich gehen, geht aber nicht). Ob es da einen Zusammenhang gibt kann ich nicht sagen, ich hatte noch nie ne Broadcom unter den Finger...

Ich sehe noch zwei Sachen, die ich auch testen würde:
a) Wenn obiger Test das öftere Wegbrechen des Links zeigen würde, dann probiere mal die Geschwindigkeit auf 10BaseT einzustellen und laß auf jedenfall mal FullDuplex weg. Das kann per mii-tool verändert werden (man mii-tool), bei Problemen melde dich dafür nochmal.

b) Teste mal, ob bei deiner Installation das Tool dhclient vorhanden ist(which dhclient). Wenn ja, nimm mal dieses anstatt dhcpcd um eine IP zu kriegen.

c) Schau mal im BIOS des Laptops, ob du dort eine Einstellung wie "Use PnP PlugAndPlay OS" hast und auf was diese steht. Diese würde ich einfach mal verändern und schauen ob es was bringt. Diese bewirkt lediglich, daß sich das BIOS weitgehend aus der IRQ/IO-Zuweisung für die Geräte raushält (bei PnP-OS ja) und es komplett dem Betriebssystem überläßt. Bei obskuren Problemen daran zu drehen hatte ich schon manchen Erfolg...

Zu IP/MAC-Adressen: Die werden bei dir wohl nirgendwo "registriert" oder in anderer Weise zur Überprüfung rangezogen. In der Software/Firmware deines Modem werden Daten drinstehen, die dich als berechtigten Kabelkunden ausweisen. Egal welches Gerät nun über Ethernet dranhängt bekommt eine Internetverbindung (mit wechselnden, eben dynamischen IPs aus diesem Segment). Der DHCP-Server steht im Internet (provider), das Modem hält nur ständig eine Verbindung/Link zu einem Providerzugangsrechner. Und außer per DHCP kannst du da nichts machen, mußt du auch nicht da DHCP angenehm ist (wenn es funktioniert <g>).

Ansonsten gehen mir die Ideen aus, v.a. wenn ich nicht selbst am Rechner sitze fallen mir Lösungen/Tests kaum ein die ich dir alle haarklein niederschreiben müßte (Allein dieser ewig lange Text, da hätte man alle Tests dreimal *machen* können...)

walter

Guten Abend,

ich habe am Wochenende die Ratschläge von GerBra getestet. Und es ist tatsächlich so das der Link zur Schnittstelle ständig weg bricht.

#mii-tool -vw
eth0: negotiated 100baseTx-FD flow-control, link ok
eth0: no link
...

Diese Ausgabe wiederholt sich dann aller fünf Sekunden.

Auch das Herabsetzen der Geschwindigkeit brachte keinen Erfolg. Kurz nach der Änderung wurde auch hier die Ausgabe no link ausgegeben, und die Verbindung automatisch in den ursprünglichen Zustand zurück versetzt, also 100baseTx-FD.

Also wenn ich es richtig verstehe, gibt es Probleme mit dem b44 Treiber.
Ich finde keine Lösung für das Problem. Ich habe jetzt zwei Tage vergeblich danach gesucht.
Weiß jemand Rat?

Gruß Walter

GerBra

Hattest du auch mal die anderen Vorschläge/Tips angetestet (außer mii-tool), die ich gemacht hatte? Also dhclient und diese Bios-Einstellung?

Ich sehe als einzige Möglichkeit einen anderen Kernel zu nutzen. Aktuell sind wir ja bei linux30, der Vorgänger war der 2.6.39.
Eine dieser versionen würde ich mir nun herunterladen für meine Architektur (i686 oder x86_64) und per Hand upgraden.
Internetzugang hast du ja (über einen anderen PC).

Für linux30 (plus firmware):
Gehe auf http://ftp.hosteurope.de/mirror/ftp.archlinux.org/core/os/ und suche dir für deine Architektur die Pakete:
module-init-tools
mkinitcpio
linux
linux-firmware

Diese Downloaden und auf ein Transfermedium(USB-Stick, CD,DVD) packen. Archlinux booten, Tranpiortmedium mounten und dann diese Pakete einzeln aktualisieren:
pacman -U /pfad/zum/jweweiligenPaket-versionblalbla.pkg.tar.gz
Upgraden in der Reihenfolge wie oben gelistet. Es kann sein, daß noch andere Pakete verlangt werden, die jetzt hier nicht dabei sind. Da müßtest du dann abbrechen und den Downloadweg von oben nochmal gehen.

Der ältere 2.6.39 ist auf den Mirrors wohl nicht mehr zu finden, da müßtest du ggf. mal bei www.schlunix.org/archlinux schauen, dieser Mirror hostet auch noch ältere Paketversionen.

Ganz andere Aletrnative wäre eine Neuinstallation mit aktuelleren (wohl noch nicht stable) Install-ISOs, diese bringen gleich aktuellere Kernel mit.
http://releng.archlinux.org/isos/