Netzwerk-Schnittstellen / fail-safe bzw. Not-IP (169.254.1.1 bei FB 7170)

[ao]

Hallo,

auf meiner FB 7170 mit freetz-devel-3604 habe ich mal mit ifconfig gecheckt, welche für Netzwerk-Schnittstellen existieren (da ich in rrdstats etwas eintragen möchte):

cpmac0    Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:132032 errors:16 dropped:0 overruns:0 frame:0
          TX packets:32992 errors:16 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:15658925 (14.9 MiB)  TX bytes:9605586 (9.1 MiB)

dsl       Link encap:Point-to-Point Protocol
          inet addr:169.254.2.1  P-t-P:169.254.2.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:22686 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16532 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:2331023 (2.2 MiB)  TX bytes:6896275 (6.5 MiB)

eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:24593 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16033 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:128
          RX bytes:7211149 (6.8 MiB)  TX bytes:2151639 (2.0 MiB)

eth0:1    Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet addr:192.168.178.253  Bcast:192.168.178.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1

lan       Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet addr:192.168.178.11  Bcast:192.168.178.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:24593 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16033 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:6768475 (6.4 MiB)  TX bytes:2151639 (2.0 MiB)

lan:0     Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet addr:169.254.1.1  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1

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:458 errors:0 dropped:0 overruns:0 frame:0
          TX packets:458 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:47812 (46.6 KiB)  TX bytes:47812 (46.6 KiB)

wan       Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:107439 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16789 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:8447776 (8.0 MiB)  TX bytes:7216226 (6.8 MiB)

Kann mir bitte jemand erklären, was das für Schnittstellen im einzelnen sind?
Alle mit xx: xx: xx: xx: xx: xx haben dieselbe MAC-Adresse.

Meine "Vorschläge"/Vermutungen habe ich hier schonmal dazugeschrieben:

1. cpmac0 = Name vom Kernelmodul
2. dsl = DSL interface; bei mir nicht genutzt, da FB hinter Kabelmodem - trotzdem "RX bytes:2331023 (2.2 MiB) TX bytes:6896275 (6.5 MiB)"
3. eth0 = LAN2/3/4?
4. eth0:1 = virtualip
5. lan = bridged network interface
6. lan:0 = virtual network interface with fail-safe IP
7. lo = local loopback
8. wan = LAN1; s.o.: FB hängt über LAN1 am Kabelmodem (sog. ATA-Modus)

PS:
Meine Frage mag Freetz-unspezifisch sein, aber da ich nicht weiß, ob einige der o.g. Schnittstellen nur mit Freetz existieren, habe ich den Thread im Freetz-Unterforum gestartet. Wenn das stört, bitte ich die Moderatoren um Verschiebung eine Ebene rauf. Vielen Dank.

 

[olistudent]

cpmac ist der Name vom Kernelmodul. Da sollte sich über google vielleicht was finden lassen.
lan ist das gebrückte (bridged) Netzwerkinterface. Wenn du alle Geräte im selben Netzwerk hast, dann kannst du über lan alle IPs erreichen. lan:0 ist ein virtuelles Interface mit der fail-safe IP.
Das wan Interface gibts nur bei deiner WAN Einstellung. Wie du vermutet hast.

AVM macht da ganz komische Sachen. Also wunder dich nicht über das DSL Interface...

Gruss,
Oliver

 

[ao]

Danke, Oliver, hab's oben ergänzt, aber zu cpmac über diverse Suchmaschinen nichts wirklich Verständliches gefunden, aber egal, ich belasse es dabei.

Zur fail-safe IP habe ich noch eine Frage:
Wenn die bei lan0 steht und ifconfig mir zu lan0 "inet addr:169.254.1.1 Bcast:169.254.255.255 Mask:255.255.0.0" anzeigt, ist dann 169.254.1.1 die IP, mit der ich immer auf meine FB 7170 zugreifen kann, auch wenn sie über die übliche 192.168.178.1 nicht erreichbar ist? (natürlich mit der Maske 255.255.0.0, nicht 255.255.255.0)

 

[doc456]

..ist dann 169.254.1.1 die IP, mit der ich immer auf meine FB 7170 zugreifen kann, auch wenn sie über die übliche 192.168.178.1 nicht erreichbar ist? (natürlich mit der Maske 255.255.0.0, nicht 255.255.255.0)

Korrekt! Das ist seit den neueren FW's eine zweite Not-IP nach der 192.168.178.254...

 

[RalfFriedl]

Wirklich nach der 192.168.178.254 und nicht statt dessen? Denn die 192.168.178.254 taucht ja nicht mehr auf, und AVM verwendet hier die normalen Mechanismen im Kernel, sonst würde man auch die 169.254.1.1 nicht sehen.

Hintergrund zur 169.254.1.1:
Wenn kein DHCP Server verfügbar ist, sucht sich Windows eine zufällige IP-Adresse im Bereich 169.254.x.x. (RFC 3927). Unter Linux kann man das mit zcip auch tun.
Die 169.254.1.1 ist von dieser Adresse aus erreichbar, die 192.168.178.254 nicht.

 

[doc456]

@RalfFriedl, das die .254 nicht mehr funktioniert ist mir neu, aber gut zu Wissen!

 

[ao]

Ich bin zum Äußersten geschritten und habe es einfach ausprobiert (7170):

• 169.254.001.001: geht (ohne die Netzmaske ändern zu müssen)
• 192.168.178.254: geht nicht

Die 169.254.1.1 habe ich gleich mal in meine Signatur übernommen - falls ich mal nicht auf meine Box komme. ;-)

PS:
Was passiert eigentlich, wenn man 2 Fritzboxen 7170 hat und die IP 169.254.1.1 im Browser aufruft?
Von welcher FB wird dann das WebGUI angezeigt?
.

 

[doc456]

Was passiert eigentlich, wenn man 2 Fritzboxen 7170 hat und die IP 169.254.1.1 im Browser aufruft?
Von welcher FB wird dann das WebGUI angezeigt?

Hmmm, ich vermute mal von der, auf der der DNS-Server läuft...

 

[cuma]

Wenn man direkt eine IP eingibt, braucht man keinen DNS-Server. Wenn sich 2 gleiche IPs im selben Netz befinden, kann man keine von beiden erreichen. Eine IP wird immer zuerst zur MAC aufgelöst, was dann nicht funktionieren kann

 

[ao]

D.h., dass man im Falle einer nicht via 192.168.178.1 erreichbaren FB die noch erreichbare FB erst einmal vom Netz abtrennen muss (sofern diese 2. FB dieselbe Not-IP wie die 1. FB hat), bevor man versuchen kann, die 1. FB via Not-IP (z.B. 169.254.1.1 für die 7170) zu erreichen. Interessant.

 

[Silent-Tears]

Nun, am besten alles vom Netz nehmen und nur die starten, um die es geht, damit es nicht zu verwirrungen kommt.
cuma nämlich hat nicht zwangsläufig recht, ein ip-adresskonflikt hat seltsame Ursachen, und nicht nur, dass beide Geräte nicht erreichbar sind. Man weiss einfach nicht wirklich, was passiert, vor allem, wenn Windows-Geräte noch mit dazwischenfunken, die sowieso nicht das tun, was sie sollen, wenn das Netzwerk in einem nicht-definiertem Zustand ist.

 

[doc456]

@Silent-Tears, in der Tat, da passieren schon mal seltsame Dinge..
Aber ich Teste das heute Abend mal @Home...

 

[lone star]

Wenn man direkt eine IP eingibt, braucht man keinen DNS-Server. Wenn sich 2 gleiche IPs im selben Netz befinden, kann man keine von beiden erreichen. Eine IP wird immer zuerst zur MAC aufgelöst, was dann nicht funktionieren kann

Hmm,

bei mir funktioniert es aber:

Konstellation FBF 7270 als Router, FBF 7170 als Client, beide Boxen haben die Not-IP 169.254.1.1.

Gebe ich jetzt im PC/Notebook die Not-IP ein, wird immer die Benutzeroberfläche von der Clienten-Box (7170) geöffnet.

mfg Holger

 

[Feuer-Fritz]

bei mir gehts auch, allerdings öffnet der Browser dann die Master-Box, obwohl ich per LAN-Kabel am Repeater hänge

 

[doc456]

Jepp, so bei mir: per LAN die Master, per WLAN die Slave (7050)...

 

[MaxMuster]

Also ich würde auf jeden Fall so handeln, wie Silent-Tears es gesagt hat (nur die eine Box anschließen, die man erreichen will), das Verhalten in der Situation ist einfach nicht deterministisch.
Und wenn ihr mehrere Boxen habt und darauf zurückgreifen wollt, dann stellt die doch die IP's von lan:0 (oder eth:0 ...) bei den anderen Boxen in der ar7.cfg auf andere "Notfall-IP's" um, so dass ihr dann z.B. 169.254.1.2 , 169.254.1.3 nutzen könnt. Das wäre dann "sauber".


Jörg

 

[Feuer-Fritz]

Klar, aber wenn ich eine Box per Not-IP erreichen muss, kann ich sie auch per Kabel an den Rechner hängen, das wäre die sicherste Lösung. Interessant ist es dennoch, wie sich das Ganze so verhält.

 

[RalfFriedl]

bei mir funktioniert es aber:

Es gibt keine Garantie, daß nichts funktioniert, wenn zwei Geräte die gleiche Adresse haben, es gibt nur keine Garantie, daß etwas funktioniert.

Wenn ein Rechner eine Verbindung zu einem anderen aufbauen will, muß er zunächst dessen MAC-Adresse herausfinden. Dazu sendet er einen ARP-Request ins gesamte Netzwerk. Dieses hat ungefähr die Bedeutung "Wer da draußen hat die IP-Adresse xy?". Normalerweise meldet sich dann einer und alles ist gut.

Wenn mehrere Rechner auf die gleiche IP konfiguriert sind, melden sich beide. Zwangsläufig kommt die Antwort von einem der Beiden zuerst an. Wenn die erste Antwort gespeichert wird und die zweite ignoriert wird (es könnte auch eine Warnmeldung kommen, evtl. in einem Protokoll verborgen), dann kann man mit diesem Rechner die Verbindung aufbauen. Nach einigen Minuten wird die ARP-Antwort ungültig und es wird wieder ein ARP-Request gesendet. Wenn wieder vom Gleichen die Antwort zuerst kommt, ist alles gut, ansonsten wird der andere Rechner kontaktiert, der von der bestehenden Verbindung nichts weiß und diese zurücksetzt, meistens zur Verwunderung des Benutzers.

Wenn einer der Rechner (oder Router) die ARP-Anfragen jedesmal schneller beantworten kann als der andere, dann sollte es relativ zuverlässig funktionieren, bis er einmal aufgrund hoher Belastung einmal doch nicht der schnellere ist.

 

[MaxMuster]

Auch wenn ich Ralf nur ungerne widerspreche, eigentlich ist es nach meinem Verständnis genau "andersrum" beim ARP: Die meisten Geräte nehmen eine ARP Antwort immer an (sogar, wenn sie garkeinen Request geschickt haben, das nutzt z.B. ARP-Poisoning aus) und machen ein Update ihrer Tabellen. Deshalb müsste eigentlich "die letzte Antwort gewinnen"???

Die Konsequenz ist aber die gleiche: Eine zuverlässige Kommunikation ist nicht sichergestellt...

Jörg

 

[doc456]

@MaxMuster, die Idee ist super, Thx! So wird das gut...

@RalfFriedl, jedoch "normaler" Weise bei M$ wird der nächste ARP-Request völlig geblockt und ein Adresskonflikt gemeldet, der sich nur noch durch einen Reboot der zweiten Nic lösen läßt. Zumindest im C/S-Netz, bei den Fritten wohl nicht, da es nur gebridged ist, oder?