IP von eth0 'Fehlerhaft'

Moin Leute,

ich hab ein verzwicktes Problem, was mich nahezu zur Verzweiflung treibt. Die IP von eth0 ist fehlerhaft :wink: Also mal langsam von Anfang an:

System: Debian etch
Ich sitze hier in einem kleinen WG-Netzwerk mit einer statischen IP (192.168.0.6) Es funktioniert auch alles wunderbar aber ich bekomme beim booten die IP 169.254.134.162 zugewiesen.
Fragt mich nicht wie … es funktioniert einfach :smile:. Das war die vergangenen Jahre (c.a. 3 Jahre existiert das System schon so) nie ein Problem. Nun hab ich aber einen IPsec-Tunnel zu meiner Firma aufgebaut, und der funktioniert nur wenn eth0 die 192.168.0.6 hat.
Da ich keine Lust hab ewig sudo ifconfig eth0 192.168.0.6 nach dem booten einzugeben wollte ich das Problem jetzt mal angehen, komme jedoch nicht weiter.
Hat jemand eine Idee wo sich der Rechner diese IP herzieht?

Zur Info ein paar quotas. Wenn ihr noch was braucht sagt bescheid:

Auszug aus ifconfig

eth0 Protokoll:Ethernet Hardware Adresse 00:C0:26:24:88:1C
 inet Adresse: **169.254.134.162 Bcast:169.254.255.255 Maske:255.255.0.0**
 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
 RX packets:32 errors:0 dropped:0 overruns:0 frame:0
 TX packets:42 errors:0 dropped:0 overruns:0 carrier:0
 Kollisionen:0 Sendewarteschlangenlänge:1000
 RX bytes:9836 (9.6 KiB) TX bytes:5915 (5.7 KiB)
 Interrupt:177 Basisadresse:0xec00

Auszug aus /etc/interfaces:

iface eth0 inet static
 address **192.168.0.6**
 netmask **255.255.255.0**
 broadcast 192.168.0.255
 network 192.168.0.0
 gateway 192.168.0.1

netstat -r

hafux@elessar:~$ netstat -r
Kernel IP Routentabelle
Ziel Router Genmask Flags MSS Fenster irtt Iface
192.168.0.0 \* 255.255.255.0 U 0 0 0 eth0
link-local \* 255.255.0.0 U 0 0 0 eth0
default router 0.0.0.0 UG 0 0 0 eth0

ABER (192.168.32.79 ist ein Rechner in der Firma):

hafux@elessar:~$ ping www.heise.de
PING www.heise.de (193.99.144.85) 56(84) bytes of data.
64 bytes from www.heise.de (193.99.144.85): icmp\_seq=1 ttl=249 time=65.4 ms
..SNIP..
--- www.heise.de ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 65.441/66.714/67.625/0.974 ms
hafux@elessar:~$ ping 192.168.32.76
PING 192.168.32.76 (192.168.32.76) 56(84) bytes of data.
From **169.254.134.162** icmp\_seq=1 Destination Host Unreachable
..SNIP..
--- 192.168.32.76 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4017ms
, pipe 3
hafux@elessar:~$ sudo ifconfig eth0 192.168.0.6
hafux@elessar:~$ sudo /etc/init.d/ipsec restart
..SNIP..
hafux@elessar:~$ ping 192.168.32.79
PING 192.168.32.79 (192.168.32.79) 56(84) bytes of data.
64 bytes from 192.168.32.79: icmp\_seq=1 ttl=127 time=135 ms
..SNIP..
--- 192.168.32.79 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 106.224/116.380/135.288/13.382 ms
hafux@elessar:~$ ping www.heise.de
PING www.heise.de (193.99.144.85) 56(84) bytes of data.
64 bytes from www.heise.de (193.99.144.85): icmp\_seq=1 ttl=249 time=70.3 ms
..SNIP..
--- www.heise.de ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 70.292/70.307/70.323/0.265 ms
hafux@elessar:~$ 

Bin für jeden Hinweis Dankbar :smile:

Servus.

Also die IP-Adresse sieht doch so aus, als ob ein DHCP fehlgeschlagen wäre. Aber deine config setzt eine static IP. Witzig ist auch, dass ein paar kB sowohl übertragen als auch empfangen wurden.

Was passiert, wenn du das interface neustartest und vielleicht nebenbei mit ‚pstree | grep dhcp‘ nebenher nachprüfst, ob sich da was tut? Bzw. mit wireshark (aka etheral) oder tcpdump mitsniffst?

mfg.

Moin,

erstmal ein Dankeschön an dich. Du hast mir noch neue Ideen gebracht. Weitergeholfen hat es indes nicht… :smile:

Das Phänomen ist merkwürdig. Ich hab eth0 jetzt aus dem Autostart genommen um es manuell hochzufahren und per tcpdump mitzuschneiden was auf dem interface passiert.

Ich denke folgendes log sagt mehr als Tausend Worte. sorry dass es so lang ist! Zwischen den einzelnen Eingaben am Promt sind nur wenige Sekunden vergangen:

elessar:/home/hafux# ifconfig
lo Protokoll:Lokale Schleife
 inet Adresse:127.0.0.1 Maske:255.0.0.0
 UP LOOPBACK RUNNING MTU:16436 Metric:1
 RX packets:8 errors:0 dropped:0 overruns:0 frame:0
 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
 Kollisionen:0 Sendewarteschlangenlänge:0
 RX bytes:560 (560.0 b) TX bytes:560 (560.0 b)

elessar:/home/hafux# ifup eth0
elessar:/home/hafux# ifconfig
eth0 Protokoll:Ethernet Hardware Adresse 00:C0:26:24:88:1C
 inet Adresse:192.168.0.6 Bcast:192.168.0.255 Maske:255.255.255.0
 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
 RX packets:5 errors:0 dropped:0 overruns:0 frame:0
 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
 Kollisionen:0 Sendewarteschlangenlänge:1000
 RX bytes:684 (684.0 b) TX bytes:576 (576.0 b)
 Interrupt:169 Basisadresse:0xec00

lo Protokoll:Lokale Schleife
 inet Adresse:127.0.0.1 Maske:255.0.0.0
 UP LOOPBACK RUNNING MTU:16436 Metric:1
 RX packets:8 errors:0 dropped:0 overruns:0 frame:0
 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
 Kollisionen:0 Sendewarteschlangenlänge:0
 RX bytes:560 (560.0 b) TX bytes:560 (560.0 b)

Bis hierhin ist also alles in Ordnung. Wenige Sekunden später sieht das ganze aber schon anders aus:

elessar:/home/hafux# ifconfig
eth0 Protokoll:Ethernet Hardware Adresse 00:C0:26:24:88:1C
 inet Adresse:169.254.134.162 Bcast:169.254.255.255 Maske:255.255.0.0
 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
 RX packets:6 errors:0 dropped:0 overruns:0 frame:0
 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
 Kollisionen:0 Sendewarteschlangenlänge:1000
 RX bytes:744 (744.0 b) TX bytes:756 (756.0 b)
 Interrupt:169 Basisadresse:0xec00

lo Protokoll:Lokale Schleife
 inet Adresse:127.0.0.1 Maske:255.0.0.0
 UP LOOPBACK RUNNING MTU:16436 Metric:1
 RX packets:8 errors:0 dropped:0 overruns:0 frame:0
 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
 Kollisionen:0 Sendewarteschlangenlänge:0
 RX bytes:560 (560.0 b) TX bytes:560 (560.0 b)

elessar:/home/hafux#

TCPdump sagt dazu:

elessar:/home/hafux# tcpdump -v
tcpdump: WARNING: Promiscuous mode not supported on the "any" device
tcpdump: listening on any, link-type LINUX\_SLL (Linux cooked), capture size 96 bytes
00:17:37.064730 arp who-has 169.254.134.162 tell 0.0.0.0
00:17:37.146319 arp who-has router tell elessar
00:17:37.146771 arp reply router is-at 00:0f:b5:7a:87:24 (oui Unknown)
00:17:37.146785 IP (tos 0x0, ttl 64, id 41578, offset 0, flags [DF], proto: UDP (17), length: 74) 
 elessar.32769 \> router.domain: 35605+ PTR? 162.134.254.169.in-addr.arpa. (46)
00:17:37.320926 IP (tos 0x0, ttl 60, id 49490, offset 0, flags [DF], proto: UDP (17), length: 151)
 router.domain \> elessar.32769: 35605 NXDomain 0/1/0 (123)
00:17:37.321525 IP (tos 0x0, ttl 64, id 41622, offset 0, flags [DF], proto: UDP (17), length: 66)
 elessar.32769 \> router.domain: 52716+ PTR? 0.0.0.0.in-addr.arpa. (38)
00:17:37.367409 IP (tos 0x0, ttl 60, id 49605, offset 0, flags [DF], proto: UDP (17), length: 133)
 router.domain \> elessar.32769: 52716 NXDomain 0/1/0 (105)
00:17:38.070349 arp who-has 169.254.134.162 tell 0.0.0.0
00:17:38.071346 IP (tos 0x0, ttl 64, id 41810, offset 0, flags [DF], proto: UDP (17), length: 74)
 elessar.32769 \> router.domain: 1214+ PTR? 162.134.254.169.in-addr.arpa. (46)
00:17:38.116933 IP (tos 0x0, ttl 60, id 51603, offset 0, flags [DF], proto: UDP (17), length: 151)
 router.domain \> elessar.32769: 1214 NXDomain 0/1/0 (123)
00:17:38.117602 IP (tos 0x0, ttl 64, id 41821, offset 0, flags [DF], proto: UDP (17), length: 66)
 elessar.32769 \> router.domain: 40566+ PTR? 0.0.0.0.in-addr.arpa. (38)
00:17:38.163224 IP (tos 0x0, ttl 60, id 51746, offset 0, flags [DF], proto: UDP (17), length: 133)
 router.domain \> elessar.32769: 40566 NXDomain 0/1/0 (105)
00:17:39.079794 arp who-has 169.254.134.162 tell 0.0.0.0
00:17:41.086417 arp who-has 169.254.134.162 tell 169.254.134.162
00:17:42.318993 arp who-has elessar tell router
00:17:42.319031 arp reply elessar is-at 00:c0:26:24:88:1c (oui Unknown)
00:17:43.094458 arp who-has 169.254.134.162 tell 169.254.134.162

17 packets captured
17 packets received by filter
0 packets dropped by kernel
elessar:/home/hafux# 

Für mich sieht das so aus, als wenn das Interface hochgefahren wird mit den Einstellungen aus /etc/network/interfaces und kurz darauf wird ein Broadcast durchs Netz geschickt wer die Adresse 169.254.134.162 hat. Darauf scheint (soweit ich das entschlüsseln kann) keine Antwort zu kommen, oder die falsche :stuck_out_tongue: also nimmt der Rechner an er kann eth0 diese Adresse zuweisen. Soweit richtig?
Also kein DHCP soweit bin ich schon mal :smile:

syslog sagt übrigens folgendes dazu:

Jul 4 00:17:36 localhost kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
Jul 4 00:17:37 localhost kernel: eth0: Promiscuous mode enabled.
Jul 4 00:17:37 localhost kernel: device eth0 entered promiscuous mode
Jul 4 00:17:37 localhost kernel: audit(1183501057.614:2): dev=eth0 prom=256 old\_prom=0 auid=4294967295
Jul 4 00:18:26 localhost kernel: device eth0 left promiscuous mode
Jul 4 00:18:26 localhost kernel: audit(1183501106.225:3): dev=eth0 prom=0 old\_prom=256 auid=4294967295

Sieht für mich erst mal in Ordnung aus. Oder nicht?

btw:

hafux@elessar:~$ whois 169.254.134.162

OrgName: Internet Assigned Numbers Authority
OrgID: IANA
Address: 4676 Admiralty Way, Suite 330
City: Marina del Rey
StateProv: CA
PostalCode: 90292-6695
Country: US
..SNIP..

Ist mir Vollkommen undverständlich das ganze :frowning:

MfG Micha

Moin,

kleiner Nachschub. Wenn ich das interface wieder deaktiviere funktioniert das deaktivieren erstmal. Ein daran anschließendes ifup zeigt jedoch einen Fehler(SIOCSIFADDR: File exists). Danach bleibt die IP aber die gewünschte!

elessar:/home/hafux# ifdown eth0
elessar:/home/hafux# ifconfig
lo Protokoll:Lokale Schleife
 inet Adresse:127.0.0.1 Maske:255.0.0.0
 UP LOOPBACK RUNNING MTU:16436 Metric:1
 RX packets:8 errors:0 dropped:0 overruns:0 frame:0
 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
 Kollisionen:0 Sendewarteschlangenlänge:0
 RX bytes:560 (560.0 b) TX bytes:560 (560.0 b)

elessar:/home/hafux# ifup eth0
SIOCSIFADDR: File exists
Failed to bring up eth0.
elessar:/home/hafux# ifconfig
eth0 Protokoll:Ethernet Hardware Adresse 00:C0:26:24:88:1C
 inet Adresse:192.168.0.6 Bcast:192.168.0.255 Maske:255.255.255.0
 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
 RX packets:615 errors:0 dropped:0 overruns:0 frame:0
 TX packets:605 errors:0 dropped:0 overruns:0 carrier:0
 Kollisionen:0 Sendewarteschlangenlänge:1000
 RX bytes:490602 (479.1 KiB) TX bytes:125031 (122.1 KiB)
 Interrupt:169 Basisadresse:0xec00
..SNIP..

Aha… sie mal einer an… eth0 trotz Fehler da.

elessar:/home/hafux# ifdown eth0
ifdown: interface eth0 not configured

Aha nicht configuriert… soso…

elessar:/home/hafux# ifup eth0
elessar:/home/hafux#

Ui und jetzt gehts trotzdem…

Ihr merkt vielleicht: ich bin mit meinem bescheidenen Latein am Ende. Noch irgendwelche Hinweise?
Ich geh ins Bett.

Bis morgen :wink:
Micha

Hallo,

ich hab ein verzwicktes Problem, was mich nahezu zur
Verzweiflung treibt. Die IP von eth0 ist fehlerhaft :wink:

Reicht so, als wenn irgendein Automatismus wie Zeroconf (APIPA) an der Konfiguration herumfummelt.

Hast Du zeroconf installiert? Irgendwelche „komischen“ Settings in avahi-*?

HTH,

Sebastian

Reicht so, als wenn irgendein Automatismus wie Zeroconf
(APIPA) an der Konfiguration herumfummelt.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=307480

Hast Du zeroconf installiert? Irgendwelche „komischen“
Settings in avahi-*?

http://wiki.debian.org/ZeroConf

1 Like

Servus.

Und läuft jetzt nebenher ein dhcp programm oder nicht? Denn interessanterweise ist ja diesbezüglich anscheinend nichts übers netz gelaufen, wie du schon geschrieben hast.

Kannst du ein

watch -d -n 0.5 ifconfig

und ein

watch -d -n 0.5 'pstree | grep dhcp'

bzw.

watch -d -n 0.5 'pstree'

(da dir das -d ohnehin die Differenzen rot markiert. Dann siehst du die Prozesse, die neu erzeugt werden nachdem das interface hoch kommt)

und paranoiderweise vielleicht ein

watch -d -n 0.5 'cat /etc/network/interfaces'

in zwei Konsolen nebenher laufen lassen? Oder hast du schon und ich habs nicht gelesen? Dann siehst du nämlich auch gleich, wie das Zeitlich mit dem tcpdump zusammenpasst. Ich vermute folgendes: Es wird en DHCP-Request gesendet, nichts zurückbekommen. Jetzt will er aber eine IP setzen. Such sich aus der Default Range eine IP (169.254.*.*) und muss jetzt natürlich überprüfen, ob die schon in Verwendung ist. Ist sie nicht, und daher setzt er diese.

Du könntest dir einen Spass machen und einen zweiten Rechner diese IP geben. Dann müsste er sich eine weitere aus der Range suchen und eine weitere ARP Anfrage machen.

Das wegen dem whois ist mir (denk ich) schon klar: Das sind Standard-IP-Adressen, wenn DHCP fehlschlägt. Das kenn ich von früher von Windows.

mfg.

Reicht so, als wenn irgendein Automatismus wie Zeroconf
(APIPA) an der Konfiguration herumfummelt.

http://wiki.debian.org/ZeroConf

Moin,

Bullseye!
Zeroconf deinstalliert und jetzt fummelt das nicht mehr an der Konfiguration herum.

Sebastian manchmal frage ich mich was du den ganzen Tag machst ausser an Linux-Kisten herumzuspielen und Bugreports zu lesen. :wink:

Besten Dank!

Micha

Moin,

hab die Lösung gefunden. Wir haben an der falschen Stelle gesucht :smile:
(Siehe Antwort von Sebastian)

Trotzdem auch an dich ein dickes Dankeschön

Micha

Sebastian manchmal frage ich mich was du den ganzen Tag machst
ausser an Linux-Kisten herumzuspielen und Bugreports zu lesen. :wink:

Frag besser nicht, sonst denke ich wieder an „gewisse Zustände“ auf Arbeit.

Hat jemand eine Idee wo sich der Rechner diese IP herzieht?

Von sich selber. Er findet keinen DHCP-Server und vergibt sich dann eine IP aus
dem 169.254-Bereich.

Siehe:
http://de.wikipedia.org/wiki/Zeroconf

Stefan

Er findet keinen DHCP-Server und vergibt sich
dann eine IP aus dem 169.254-Bereich.

Siehe:
http://de.wikipedia.org/wiki/Zeroconf

Stefan

Das stimmt so nicht! Die Automatische IP-Allokation wie es in dem Artikel heisst, hat nichts mit DHCP-Servern zu tun. Es geht ja gerade darum, eine IP ohne zentralen Server zu beziehen.

Siehe:
http://de.wikipedia.org/wiki/Zeroconf

Micha

Er findet keinen DHCP-Server und vergibt sich
dann eine IP aus dem 169.254-Bereich.

Die Automatische IP-Allokation wie es in
dem Artikel heisst, hat nichts mit DHCP-Servern zu tun. Es
geht ja gerade darum, eine IP ohne zentralen Server zu
beziehen.

Stimmt nicht!1!!

Zeroconf ist dazu gerade da, trotzdem IP-Adressen zu verteilen, wenn kein DHCP-Server vorhanden ist.

Siehe http://de.wikipedia.org/wiki/Zeroconf

Ach, bevor ich es vergesse: SCNR