Arch Linux

PC bekommt oft keine IP

excamo

Hi,

langsam nervts, daher wollte ich euch mal zu eurer Meinung fragen..

Unsere IP Adressen in der Firma werden von den Admins an die MAC Adresse vom PC gebunden. Dieser holt sich dann immer dieselbe IP via DHCP..

Nun das Problem: Mein Arch bekommt beim 3. oder 4. neustart erst eine IP. Ich hab in der rc.conf normal DHCP aktiviert und in der resolv.conf stehen die DNS Server. Dann hab ich noch die config vom dhcp angepasst sodass die resolv.conf nicht immer neu generiert wird. Das funktioniert auch.. nur halt meistens erst beim 3. oder 4. anlauf...

hat von euch jemand eine Idee an was das noch liegen kann?!

archeologist

Hi,

keine Ahnung warum dein DHCP spinnt. Aber vielleicht hilft eine statische IP?
http://wiki.archlinux.org/index.php/Configuring_Network#For_Static_IP

stigmayta

Du könntest versuchen das Timeout von dhcpcd erhöhen, ... ich sehe aber gerade, dass das standardmäßig 30 Sekunden sind. Das ist schon ziemlich viel. Um das zu ändern, musst du in der Datei /etc/conf.d/dhcpcd in den Parameter DHCPCD_ARGS den Schalter "-t <Anzahl_Sekunden>" eintragen. Also für eine Minute würde das dann so aussehen:

#
# Arguments to be passed to the DHCP client daemon
#

DHCPCD_ARGS="-t 60 -q"

Ein Wert von 0 bedeutet das dhcpcd ewig auf ein IP-Angebot wartet.

Ansonsten sollten sich die Admins das mal anschauen, normal ist das nicht.

[gelöscht]

excamo schrieb Nun das Problem: Mein Arch bekommt beim 3. oder 4. neustart erst eine IP. Ich hab in der rc.conf normal DHCP aktiviert und in der resolv.conf stehen die DNS Server. Dann hab ich noch die config vom dhcp angepasst sodass die resolv.conf nicht immer neu generiert wird. Das funktioniert auch.. nur halt meistens erst beim 3. oder 4. anlauf...

Das sieht mir a) nach einem sehr überlasteten Netzwerk oder b) falsch konfigurierten DHCP aus. Was übernimmt bei euch eigentlich die DHCP-Funktionalität? Also Linux- oder Windows-Server? Ich weiß aus eigener Erfahrung das die Windows-DHCP-Server ab und an mal der Meinung sind, sie kennen einen nicht.

Auch wären die Logs mal interessant, so dass man nachverfolgen kann was eigentlich passiert ... also ob bsp. der DHCP überhaupt antwortet.

Einen Hardware-Defekt auf deiner Seite möchte ist erstmal außen vor lassen.

excamo

also danke erstmal für die reichliche Hilfe 😉

- Hab zunächst mal, wie vorgeschlagen, den DHCP timeout auf 60 gestellt. Hat aber nix gebracht
- Dann hab ich einfach mal meine IP Statisch vergeben (obwohl meine Adminkollegen gemeint haben das es immer über diese Omminöse DHCP-MAC-Adressen Datei geregelt wird), und siehe da.. läuft

Ich muss dazu sagen ich arbeite erst 2 Wochen in dem Laden und kenn die Infrastruktur noch nich wirklich.. aber über diese DHCP Geschichte hat er sich unverändert alle 3-4 Neustarts erst ne IP geholt.

Hier ein Auszug aus der /var/log/messages.log

Jul 29 07:25:11 iwi-w-bach01-a kernel: sky2 0000:02:00.0: eth1: disabling interf
ace
Jul 29 07:25:13 iwi-w-bach01-a kernel: sky2 0000:02:00.0: eth1: enabling interfa
ce
Jul 29 07:25:13 iwi-w-bach01-a kernel: ADDRCONF(NETDEV_UP): eth1: link is not re
ady
Jul 29 07:25:13 iwi-w-bach01-a dhcpcd[2101]: version 5.2.5 starting
Jul 29 07:25:13 iwi-w-bach01-a dhcpcd[2101]: eth1: waiting for carrier
Jul 29 07:26:28 iwi-w-bach01-a kernel: sky2 0000:02:00.0: eth1: disabling interf
ace
Jul 29 07:26:30 iwi-w-bach01-a kernel: sky2 0000:02:00.0: eth1: enabling interfa
ce
Jul 29 07:26:30 iwi-w-bach01-a kernel: ADDRCONF(NETDEV_UP): eth1: link is not re
ady
Jul 29 07:26:30 iwi-w-bach01-a dhcpcd[2125]: version 5.2.5 starting
Jul 29 07:26:30 iwi-w-bach01-a dhcpcd[2125]: eth1: waiting for carrier
Jul 29 07:28:30 iwi-w-bach01-a kernel: sky2 0000:02:00.0: eth1: disabling interf
ace
Jul 29 07:28:32 iwi-w-bach01-a kernel: sky2 0000:02:00.0: eth1: enabling interfa
ce
Jul 29 07:28:32 iwi-w-bach01-a kernel: ADDRCONF(NETDEV_UP): eth1: link is not re
ady
Jul 29 07:28:32 iwi-w-bach01-a dhcpcd[2158]: version 5.2.5 starting
Jul 29 07:28:32 iwi-w-bach01-a dhcpcd[2158]: eth1: waiting for carrier
Jul 29 07:36:08 iwi-w-bach01-a kernel: sky2 0000:02:00.0: eth1: disabling interf
ace
Jul 29 07:36:10 iwi-w-bach01-a kernel: sky2 0000:02:00.0: eth1: enabling interfa
ce
Jul 29 07:36:10 iwi-w-bach01-a kernel: ADDRCONF(NETDEV_UP): eth1: link is not re
ady
Jul 29 07:36:10 iwi-w-bach01-a dhcpcd[2189]: version 5.2.5 starting
Jul 29 07:36:10 iwi-w-bach01-a dhcpcd[2189]: eth1: waiting for carrier
Jul 29 07:38:26 iwi-w-bach01-a kernel: sky2 0000:02:00.0: eth1: disabling interf
ace
Jul 29 07:38:28 iwi-w-bach01-a kernel: sky2 0000:02:00.0: eth1: enabling interfa
ce
Jul 29 07:38:28 iwi-w-bach01-a kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready
Jul 29 07:38:28 iwi-w-bach01-a dhcpcd[2213]: version 5.2.5 starting
Jul 29 07:38:28 iwi-w-bach01-a dhcpcd[2213]: eth1: waiting for carrier

fs4000

Jul 29 07:25:13 iwi-w-bach01-a dhcpcd[2101]: eth1: waiting for carrier

Du scheinst keinen Link zum Netzwerk zu bekommen. Wenn du so grüne/orange Kontrolleuchten am LAN-Port hast, beobachte die mal, die grüne zeigt den Link an.

excamo

link hab ich, wie gesagt wenn ich die ip statisch vergebe funktioniert alles 😉

fs4000

Dann ists ein Treiberfehler. In dem Fall wird dir ein -K oder --nolink für den dhcpcd weiterhelfen.

mannohneschuh

fs4000 schrieb
Jul 29 07:25:13 iwi-w-bach01-a dhcpcd[2101]: eth1: waiting for carrier
Du scheinst keinen Link zum Netzwerk zu bekommen. Wenn du so grüne/orange Kontrolleuchten am LAN-Port hast, beobachte die mal, die grüne zeigt den Link an.

Irgendwo hab ich mal von meinem schlechten Router berichtet (der immmer mal wieder abstürzt). Wenn er neustartet kann es vorkommen das ich auch keinen 'carrier signal' bekomme, und das obwohl sowohl am Router als auch am PC die LED leuchtet und das Kabel definitiv nicht kaputt ist. Bei mir liegts am Router... (ziehe ich das Kabel stecke es wieder rein passiert auch nix, außer das die LEDs dann aus gehen und beim Einstecken wieder an).
Ich wollte damit nur darauf hinweisen das die LED nicht unbedingt so aussagekräftig ist.

[gelöscht]

Es könnte aber auch der Switch sein, der ab und an mal der Meinung sei, excamo den Stinkefinger zeigen zu müssen. Speziell die "Billig"-Switche haben das Problem, dass diese bei hoher Belastung mal kurzerhand sich weigern irgendetwas zu machen. Die LED's zeigen nur die physikalische aber nicht die logische Verbindung an ... kurz gesagt: Wenn LED leuchtet = Kabel angeschlossen. Ob man aber nun wirklich ein Trägersignal (Carrier Signal) bekommt, weiß man spätestens erst wenn man das System fragt.

Das es ggf. solche Router gibt habe ich auch schon gehört, war jedoch bisher verschont. Könnte aber auch daran liegen, dass ich bei meinen Eltern nen Linksys (Cisco) Router einsetze.

mannohneschuh

Ich warne an dieser Stelle mal vor der Benutzung des Arcor WLAN 200 (heißt eigentlich: P660HW-T7C ist aber von Arcor äußerlich umgelabelt worden. Und die Pfuscher haben noch nichtmal die Weboberfläche mitangepasst. Da gibts an der Stelle mal ein kleines Lob an den lila Riesen, wenn der bei AVM einkauft siehts Otto Norml nicht gleich).
Dieses Arcor Ding ist übrigens der 3. seiner Art bei dem ich dieses Problem erleben durfte!

Um aml wieder on topic zu kommen: Meinst du die Admins merkens, und wenn, nehmens dir übel wenn du dir ne feste IP suchst? Scann das netzwerk such dir ne freie IP schlag noch 50 drauf. Oder du bist lieb und fragst in welchem Bereich der DHCP-Server IPs verteilt und suchst dir eine außerhalb dieses Bereichs. Und achte am Besten auch darauf das du nicht die von irgendeinem lokalen Firmenserver nimmst.

excamo

Also, is ja sehr lustig - wobei eigentlich nicht.

An dem Switch hängt noch ein Debian PC von mir und ein Windoof PC von ner Kollegin - alle ohne Probleme. Wenn ich die Windoof Partition boote, hab ich auch keine Probleme damit. Wenn ich aber vor dem starten vom Arch den Power Stecker aus dem Switch ziehe und wieder reinsteck, läuft alles wunderbar..?! Kann sich das jemand erklären? 😃

mannohneschuh

Könnte vielleicht noch am Treiber für den Netzwerkchip liegen. Ähnliches Problem hatte ich mit meinem Rechner als das GBit Ethernet noch recht jung war (im Homebereich) und mein Distributor noch einen älteren Kernel verwendete in dem der Treiber für diesen neuen Chip noch nicht ausgereift war. Aber damals habe ich halt nie eine IP bekommen obwohl sowohl physikalisch als auch logisch alles ok schien. (Und dann frag mal $SUCHMASCHIENE nach ner Lösung).

Lad deinen Admin doch auf ne Tasse guten Kaffee ein und bitte ihn um eine feste IP. Oder sind die eher vom Typ BOFH?

Dirk

mannohneschuh schriebIch wollte damit nur darauf hinweisen das die LED nicht unbedingt so aussagekräftig ist.

Doch, ist sie. Allerdings nicht im Sinne von „Es funktioniert alles, wie es soll", sondern nur im Sinne von „Es besteht hardwareseitige eine Verbindung (Layer 1)".

mpausch

welche Netzwerkkarte hast Du denn genau (lspci -v)?
Evtl hilft ja der Treiber von Marvell http://extranet.marvell.com/drivers/driverDisplay.do?driverId=153

mannohneschuh

Achtung Off-Topic:
Ja Dirk, leider steht an den meisten LEDs jedoch nicht "Link (Layer 1)", geschweige denn "Link" (für Link muss man schon echt Glück haben). Dadurch ist es dem Anwender/Betrachter überlassen sie zu interpretieren. (Ja ich weiß Zeichen und Codes sind da um interpretiert zu werden). Und die häufigste, weil doch recht naheliegende Interpretation ist nunmal: grüne Lampe -> alles gut! Vor allem wenn man dann zwei LEDs hat eine grüne für LINK eine orange/gelbe für RX/TX

Wirklich komisch finde ich jedoch die Tatsache das du nur meinen letzten Satz zitierst und kommentierst. Und damit den Kontext in dem dieser Satz geschrieben steht zerstörst, wo doch da drüber steht was los ist: physikalisch ja, logisch scheinbar nein ergo …

Dirk

mannohneschuh schriebWirklich komisch finde ich jedoch die Tatsache das du nur meinen letzten Satz zitierst …

Ich zitiere nur das, auf das ich mich beziehe.