Warum eine Notfall-IP ? Warum der Zwang mit "fritz.box" ?

[Benares]

Der ARP-Request geht mit meiner MAC und meiner IP (192....) als Broadcast raus. Von einer 169er-IP als Quelle kann ich nichts entdecken.
Bez. XP meinte ich folgende stelle: "APIPA is implemented in Windows 98 and later, and is used only if DHCP is activated"

 

[RalfFriedl]

Das ist ja erst seltsam. Ein Gerät, das nur eine Adresse aus 169.254.0.0/16 verwendet, würde auf den ARP evtl. reagieren, wüsste aber nicht, wie es die Antwort an 192.168.0.0/16 schicken sollte.

Ja, APIPA gibt es schon lange, aber normalerweise wird es verwendet, wenn DHCP zwar aktiv ist, aber kein DHCP Server geantwortet hat.

 

[Benares]

Das ist ja kein TCP/IP, sondern Ethernet pur. Das läuft alles über die MAC.

 

[koyaanisqatsi]

Das hier kann auch schon sehr ärgerlich sein, nur eine neue öffentliche IP durch reconnect. Ohne Passwort.

curl "http://fritz.box:49000/upnp/control/WANIPConn1" -H "Content-Type: text/xml; charset="utf-8"" -H "SoapAction:urn:schemas-upnp-org:service:WANIPConnection:1#ForceTermination" -d "<?xml version='1.0' encoding='utf-8'?> <s:Envelope s:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/' xmlns:s='http://schemas.xmlsoap.org/soap/envelope/'> <s:Body> <u:ForceTermination xmlns:u='urn:schemas-upnp-org:service:WANIPConnection:1' /> </s:Body> </s:Envelope>"

Und mit PHP simpel umzusetzen. Da freut man sich wenn viele Verbindungen am laufen sind: Konsole weg, Up- und Downloads, TS, laufende T-Gespräche, Online Spiele...
Und das beste hier: Kein anklickbarer Link, so auch nichts kaputtmach. Der JDownloader nutzt sowas wohl auch.

 

[scolopender]

Und mit PHP simpel umzusetzen.

Dann mach mal. Einfach irgendwas hinschreiben, ohne Nachweis, dass es auch so wirkt, wie Du glaubst, reicht hier nicht.

G., -#####o:

 

[koyaanisqatsi]

Ok, sorry, dann geb ich mich hier mal geschlagen.

Code zurückgezogen.

 

[scolopender]

Ach, was solls, ist ja auch irgendwie praktisch, wenn man eine neue IP braucht.

Funktioniert nur nicht:

Invalid Action. (0x80040207)

G., -#####o:

 

[Kabelallergie]

Wieso die Box über 169.254.1.1 bei gültiger DHCP Adresse erreichbar ist habe ich mich auch gefragt.
Ich bin direkt per LAN verbunden und bei mir geht auch gleich der Ping vom Mac durch und arp klappt auch.

$ ping 169.254.1.1
PING 169.254.1.1 (169.254.1.1): 56 data bytes
64 bytes from 169.254.1.1: icmp_seq=0 ttl=64 time=1.076 ms
64 bytes from 169.254.1.1: icmp_seq=1 ttl=64 time=0.555 ms
64 bytes from 169.254.1.1: icmp_seq=2 ttl=64 time=0.741 ms
^C
--- 169.254.1.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.555/0.791/1.076/0.216 ms

$ arp -a
? (169.254.1.1) at xx:xx:xx:xx:xx:xx on en0 [ethernet]
fritz.box (192.168.22.1) at xx:xx:xx:xx:xx:xx on en0 ifscope [ethernet]

/etc/hosts oder IP habe ich nicht verstellt. Nur DHCP aktiv.

Auch mit einem Android-Handy das per WLAN über einen AP am Lan der 7390 vebunden ist geht das Webinterface unter 169.254.1.1 auf.

Ein arp von Linux sieht übrigens anders aus, der hängt aber auch per DHCP dran:

$ arp -a
Claudia.fritz.box (192.168.22.20) auf xx:xx:xx:xx:xx:xx [ether] auf eth0
fritz.box (192.168.22.1) auf xx:xx:xx:xx:xx:xx [ether] auf eth0

aber auch von Linuxcomputer aus kommt der Ping zurück.

$ ping 169.254.1.1
PING 169.254.1.1 (169.254.1.1) 56(84) bytes of data.
64 bytes from 169.254.1.1: icmp_req=1 ttl=64 time=0.468 ms
64 bytes from 169.254.1.1: icmp_req=2 ttl=64 time=0.439 ms
64 bytes from 169.254.1.1: icmp_req=3 ttl=64 time=0.493 ms
64 bytes from 169.254.1.1: icmp_req=4 ttl=64 time=0.392 ms
^C
--- 169.254.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 0.392/0.448/0.493/0.037 ms

Ich dachte aus dieser Betrachtung könnte ich was über Netzwerke lernen aber bin nur ratloser.

Und natürlich kommt man vom Linux auf Webinterface:

FRAME: /logincheck.lua

Ihr Browser unterstützt keine XHTML-Frames.

Sie können die FRITZ!Box Benutzeroberfläche aber trotzdem ohne
Einschränkung nutzen.














Pfeiltasten zum Bewegen, '?': Hilfe, 'q': Programmende, '<-': zurück
Pfeile: Auf/Ab: andere Seite im Text. Rechts: Verweis folgen; Links: zurück.
H)ilfe O)ptionen P) Druck G)ehe zu M) Hauptseite Q) Beenden /=Suche <-=History

 

[koyaanisqatsi]

Moin

Wenn du deine Klienten via DHCP mit IP-Adressen der Fritz!Box versorgen tust,
Bekommen sie Gateway und DNS der Fritz!Box, normalerweise: 192.168.178.1
Diese hat wiederum eine interne Route auf das 169.254.0.0er Netz:
route

169.254.0.0     *               255.255.0.0     U     0      0        0 lan

Wird also eine Anfrage auf 169.254.1.1 abgesendet, schaut die Friz!Box auf ihre Routingtabelle,
findet die route und leitet dann richtig weiter.
Das könntest du Klientseitig verhindern, indem du bei den Eigenschaften der Netzwerkkarte,
Den/die DNS-Server manuell eintragen tust, also nicht automatisch von der Fritz!Box beziehen.
Sehr beliebt, und deswegen zum Testen geeignet, sind die Google-DNS-Server: 8.8.8.8 und 8.8.8.4
Trag die mal manuell ein (Eigenschafften des Netzwerkadapters, Protokoll: IPv4),
und schau mal nach ob die Notfall-IP danach noch geht.

 

[RalfFriedl]

Das könntest du Klientseitig verhindern, indem du bei den Eigenschaften der Netzwerkkarte,
Den/die DNS-Server manuell eintragen tust, also nicht automatisch von der Fritz!Box beziehen.

Der erste Teil stimmt, die Box ist Default Gateway und leitet deswegen und bekommt deswegen die Pakete und reagiert darauf, weil es ihre eigene Adresse ist.
Der zweite Teil, dass es irgend etwas mit den DNS EInstellungen zu tun hätte, wird auch nicht richtiger davon, dass es häufig hier wiederholt wurde.

Trag die (Google-DNS-Server) mal manuell ein (Eigenschafften des Netzwerkadapters, Protokoll: IPv4), und schau mal nach ob die Notfall-IP danach noch geht.

Mach Du das doch zuerst selbst und schau nach, ob es tatsächlich so ist, bevor Du hier diese Empfehlung gibst.

@Kabelallergie
Wie schon geschrieben, ist es normal, dass angeschlossene Geräte die Box über die Adresse erreichen können, wenn die Box als Default Gateway eingetragen ist. Android verwendet übrigens auch einen Linux Kernel.
Bei den anderen Geräten, die per ARP nach der Box fragen, ist offensichtlich explizit oder implizit eine direkte Route für 169.254.0.0/16 aktiv. Wie weiter oben festgestellt, senden mache Windows Versionen oder Windows in manchen Konfigurationen ARP Pakete für 169.254.1.1 aus, senden die nachfolgenden IP Pakete dann aber von der 192.168.178/24 Adresse aus.

Beim MAC sollte es möglich sein, die tatsächlich konfigurierten Adressen und die Routing Tabelle auszulesen, möglicherweise mit "route -n" und "ifconfig".

 

[Kabelallergie]

Ich hab mal im Wikipedia nachgeschaut, da wird ARP mit IP4 so erklärt: solange der andere Rechner mit welcher IP auch immer im gleichen Netz erreichbar ist antwortet er selber auf den ARP Request des Rechners der seine Adresse aufruft noch bevor irgendwas geroutet wird, weil sie ja im gleichen Netz hängen. "Gleiches Netz" heißt hier wohl "soweit die ARP Requests tragen". Das deckt sich dann ja auch mit dem was gmeyer bei XP mit wireshark gesehen hat und wäre also normal.

 

[RalfFriedl]

"Gleiches Netz" heißt dass sich die IP Adresse im gleichen Netzwerk befindet wie die des Absender, also ((Adresse & Maske) == Maske). Sonst müsste für jede Adresse erst einmal ein ARP gesendet werden, es könnte ja sein, dass jemand im darauf antwortet.

 

[Benares]

Das habe ich doch weiter oben schon beschrieben.

Moderne Betriebssysteme (Windows & Linux) senden bei bestimmten Ziel-IP-Ranges, erstmal ein ARP-Broadcast-Request ins (lokale) Netz ("Who has 169....?"). Diese Broadcasts werden nicht geroutet. Das ist nacktes Ethernet und hat mit TCP/IP noch garnichts zu tun. Wenn darauf eine Station mit ihrer MAC antwortet (und Fritzboxen tun das bei Anfragen an die "Notfall-IP"), kann anschließend direkt kommuniziert werden, egal wie die IP lautet. Routing (Routing-Tabelle, Default-Gateway, ...) kommt erst dann ins Spiel, wenn keiner antwortet. Das kann man z.B. mit Wireshark wunderbar nachvollziehen.

 

[RalfFriedl]

Natürlich wird ein ARP Broadcast nicht geroutet, wohin auch. Mit IP hat es insoweit zu tun, als die MAC Adresse bestimmt werden muss, an die das IP Paket geschickt werden soll. Ein ARP Broadcast ist für jedes zu sendende IP Pakete notwendig, es sei denn, die MAC Adresse befindet sich bereits im ARP Cache.
Folglich bei einer normalen Fritz Konfiguration:
Adresse 192.168.167.25 -> ARP für 192.168.167.25 (Empfänger)
Adresse 1.2.3.4 -> ARP für 192.168.167.1 (Default Gateway)

Mein Linux System sendet genau dann ein ARP für 169.254.1.1 statt ein ARP für das Default Gateway, wenn ich auf der Netzwerkkarte eine Adresse aus 169.254.0.0/16 konfiguriert habe. Und es wird dann auch das IP Paket mit dieser 169.254.0.0/16 Adresse senden, damit der Empfänger darauf auch antworten kann. Die Routing Tabelle kommt nicht erst dann ins Spiel, wenn keiner auf das ARP antwortet, die Routing Tabelle entscheidet darüber, an wen das ARP gesendet wird. Anderenfalls hättest Du bei jedem Paket, das für einen Empfänger außerhalb des Netzes bestimmt ist, zuerst den ARP Timeout.

Mal angenommen, ich habe ein Gerät (nicht die Fritz Box), das aus welchem Grund auch immer sich eine 169.254.0.0/16 ausgewählt hat. Windows (in manchen Versionen/Konfigurationen) sendet ein ARP für diese Adresse, bekommt eine Antwort. Dann wird das IP Paket dorthin gesendet, mit der Adresse 192.168.178.0/24 als Absender. Das Zielgerät weiß nichts von 192.168.178.0/24 und kann nicht antworten.

Mir ist klar, dass man mit Wireshark wunderbar nachvollziehen kann, was da passiert. Das heißt nicht, dass es auch richtig ist.

 

[Benares]

Hallo RalfFriedl,

ich bin der Meinung, deine Aussage stimmt so nicht ganz. Teste es mal mit Wireshark.
Auch wenn keine der Netzwerkkarten eine 169er IP hat und auch die Routing-Tabelle keine Route zu einer 169er IP hat erfahren die APIPA-Adressen 169.254.0.0/16 eine Sonderbehandlung. Da wird erstmal ein ARP-Broadcast gesendet und bei einer Antwort im ARP-Cache eingetragen, auch beim Antwortenden (Bei Wireshark steht dann so schön "Who has 169.254.x.y, please tell 192.x.y.z"). Die weitere Kommunikation erfolgt dann auf MAC-Ebene, da beide Stationen sich bereits "kennen", egal wie die IP lautet.

Natürlich unterstützt das nicht jedes Zielgerät, es würde dann ja auch nicht antworten. Die Fritzbox tut das aber.

 

[RalfFriedl]

Nun, meine Windows Versionen/Konfigurationen senden kein ARP für 169.254.1.1, ich habe es gerade nochmal getestet. Deswegen kann ich auch nicht ausprobieren, wie ein Gerät reagieren würde. wenn es so wäre. Ich glaube Dir, dass Dein System sich so verhält, trotzdem ist es meiner Meinung nach falsch, dass es das tut.

Die Fritzbox kennt auf jeden Fall eine Route nach 192.168.178.0/24, daher ist es zu erwarten, dass sie antwortet.

 

[Benares]

Ich nutze übrigens Win7 Ultimate 64-Bit. Ich meine, ich hätte irgendwo gelesen, das macht Windows auch nur, wenn Windows seine IP über DHCP zieht.

 

[RalfFriedl]

Mein Windows bekommt sein IP Adresse auch über DHCP. Aber wer weiß, was da noch alles einen Einfluss darauf hat.

 

[qwertz.asdfgh]

... Aber wer weiß, was da noch alles einen Einfluss darauf hat.

Hmm, z.B. ob als privates oder öffentliches Netzwerk konfiguriert, die Windows-Firewall ein- oder ausgeschaltet ist, Firewall eines Drittanbieters (z.B. von einer Security Suite) zum Einsatz kommt usw.?
Keine Ahnung was das sonst noch so beeinflussen könnte, kenne mich mit Windows nicht so gut aus.

 

[xrated]

Da wird erstmal ein ARP-Broadcast gesendet

Seh ich auch keinen und ARP-Broadcast funktioniert eben nur in dem Subnet wo auch der Client drin ist. Im Log sieht man das der PC von dem ganzen gar nichts mitbekommt (was auf der FB geroutet wird), ping raus und von der FB wieder zurück.

lan:0 Link encap:Ethernet HWaddr 00:1C:4A:93: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

route:
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 lan

wozu dienen eigentlich 192.168.180.1/2 ? ist das ein Alias auf externe DNS Server?