Gleiche IP für 2 Geräte möglich?

[xexex]

Das Stichwort heißt Zeroconf, offiziell ist das aber tot.

Der Bereich ist weiterhin von IANA ausschließlich dafür reserviert. Kein Gerät hat so eine Adresse fest zu nutzen. In meinen Augen hat irgendein "Idiot" seinerzeit selbst der Kamera diese Adresse fest konfiguriert, weil er die Kamera direkt an seinen PC angeklemmt hat und einfach das genommen hat was sich die Kamera dabei selbst gesucht hat.

@ xexex: Meinst du der zeitliche Aufwand VLAN und deren NAT einzustellen wäre so hoch und deshalb unsinnig? Aber die Mühe wäre ich bereit einmal auf mich zu nehmen und dann per backup file auf mehrere Router diesen Workaround zu "flashen".

Unsinn deshalb weil es ein Pfusch wäre um einen anderen Pfusch noch weiter zu verpfuschen. Irgendjemand wird die Kamera auf die Adresse gesetzt haben, die er gar nicht fest nutzen darf und weil sie jemand gesetzt hat, kann sie auch jemand ändern..... Das Adresse ist nicht in Hardware gegossen, egal welches Gerät es ist. Entweder wartet das Teil auf einen DHCP Server, lässt sich per RARP ändern oder hat eine Schnittstelle um die Adresse anzupassen.

Was du bräuchtest um es trotzdem weiter zu pfuschen wäre ein Router der mindestens irgendwas in der Form kann.
https://www.dd-wrt.com/wiki/index.php/One-to-one_NAT

EDIT:

Spendierst du jeder Kamera eine eigene Netzwerkkarte im PC, könntest du aber natürlich auch um den Aufwand herumkommen. Du kannst mit dem Befehl arp unter Windows selbst Zuweisungen von IP zu MAC Adressen durchführen (ARP -s Inet-Adr. Eth-Adr. [Schnittstelle]). Dann gibst du den Kameras unterschiedliche IP Adressen und natürlich auch Netzbereiche zu.

 

[DunklerRabe]

Ich weiß, dass der Bereich immer noch reserviert ist. Und das ist auch gut so, weil da eben immer noch einige ihr eigenes Süppchen kochen. Ich wollte nur mal darauf hinweisen, dass IPs aus dem Netz nicht immer auf APIPA zurückzuführen sind, weil der Begriff dafür ist eben Zeroconf. Und außerdem macht es eben nicht unbedingt jedes Gerät.

Aber ich stimme dir zu, da hat jemand beim Design der Kameras ganz offensichtlich Mist gebaut. ODER er hat sie für einen sehr speziellen Use Case konstruiert, den wir gerade nicht nachvollziehen können. UND dabei dann offensichtlich Mist gebaut!

 

[andreas_monyer]

Auf jedem "Kamerarouter" konfigurierst du dann ein Forwarding von der IP des Routers und dem Port auf dem du ankommst auf die 169.254.0.1 und dem Zielport, auf dem die Kamera die Verbindung erwartet. Das kann auch der gleiche Port sein. Damit ist dann jede Kamera über eine eigene IP erreichbar und das sollte dann funktionieren. Die Router übernehmen dann die Traffic zu den Kameras mit den immer gleichen IPs und nach außen hin kommunizieren die mit dir mit unterschiedlichen IPs, sodass die Endgeräte, also die Kameras, wieder unterscheidbar sind.

Internetanschluss kann man getröst vergessen. Sind Messrechner im Auto die nur rein lokal arbeiten.
Nur damit ich dich korrekt verstehe füge ich noch die commands an:
Wenn ich z.B. den UDP Datenstrom von Kamera 1 empfangen möchte baue ich eine Verbindung zu "Kamerarouter #1": 192.168.0.100 und nutze z.B. den Port 1023 dafür. Der Kamerarouter 1 hat Port forwarding von Port 1023 auf IP 169.254.0.1:4747 eingestellt.
Stimmts so?

Müssen die Kamerarouter per WAN mit dem Hauptrouter verbunden werden?
Würde es auch ohne Hauptrouter gehen? Also PC an Kamerarouter 1 den 1. LAN Port, 2. Lan Port Kamera 1 und von 3. LAN Port zu WAN des 2. Kamerarouters und hier wiederrum an LAN Port 1 die 2. Kamera.

 

[Uridium]

Die Adresse erscheint mir dennoch irgendwie zu "Windows typisch". Ich könnte mir eher vorstellen, dass jemand fälschlich GLAUBT, die Kamera hätte diese Adresse. Das Ding könnte genau so gut die Daten via Broadcasts an alle Rechner gleichzeitig senden.

Wie wird denn die Verbindung aufgebaut? Musst du dich mit einem Programm verbinden oder sendet die Kamera automatisch? Wie sieht die Netzwerktopologie genau aus?

 

[andreas_monyer]

Wenns Broadcast wäre, wie könnte man dann die Datenherkunft unterscheiden?
Die Kamera sendet von sich aus automatisch sobald die Strom bekommt.

Normalerweise wird die Kamera direkt mit dem PC verbunden, welcher die IP 169.254.0.2 eingestellt hat.

 

[Uridium]

Und dort läuft Windows und ein bestimmtes Programm? Schon ausprobiert, was passiert, wenn man die IP z.B. auf 169.254.0.3 stellt?

 

[DunklerRabe]

Internetanschluss kann man getröst vergessen. Sind Messrechner im Auto die nur rein lokal arbeiten.

Ok, macht aber nichts, der Internetzugang ist ja nicht nötig.

Nur damit ich dich korrekt verstehe füge ich noch die commands an:
Wenn ich z.B. den UDP Datenstrom von Kamera 1 empfangen möchte baue ich eine Verbindung zu "Kamerarouter #1": 192.168.0.100 und nutze z.B. den Port 1023 dafür. Der Kamerarouter 1 hat Port forwarding von Port 1023 auf IP 169.254.0.1:4747 eingestellt.
Stimmts so?

Ist richtig so, ggf. musst du bei der Forwarding Regel auch noch angeben, dass es explizit UDP sein soll.

Müssen die Kamerarouter per WAN mit dem Hauptrouter verbunden werden?
Würde es auch ohne Hauptrouter gehen? Also PC an Kamerarouter 1 den 1. LAN Port, 2. Lan Port Kamera 1 und von 3. LAN Port zu WAN des 2. Kamerarouters und hier wiederrum an LAN Port 1 die 2. Kamera.

Per WAN sowieso nicht, du hast ja gesagt Internet gibt es nicht. WAN ist typischerweise das Internet.
Es geht auch ohne Hauptrouter und stattdessen mit einem Switch oder aber auch mit Direktverbindungen vom PC zu den Kameraroutern.

Aber warum willst du die Kamerarouter verbinden? Weil du nur einen Ethernetport am PC hast? Ist natürlich machbar, der Traffic zu Kamerarouter 2 läuft dann über Kamerarouter 1. Die Verbindung würde aber zwischen den LAN Ports der Router passieren, nicht über den WAN Port.

Normalerweise wird die Kamera direkt mit dem PC verbunden, welcher die IP 169.254.0.2 eingestellt hat.

Mit DIESEM Rechner, wenn die IP auch fest eingetragen ist, wirds aber langsam richtig fies. Benutzt du da einen anderen bzw. ist die IP da änderbar? Weil sonst hast du zwei oder drei physikalisch getrennte Netze mit den selben IP Ranges. Ob die Router da noch ein Forwarding erlauben wage ich zu bezweifeln.

So langsam dämmert es mir dann auch was da abgeht. Kann es sein, dass der Use Case fix auf einen Rechner und eine Kamera pro "Umgebung" begrenzt war?

Ich muss da grundsätzlich noch mal drüber schlafen. Ich bin mir gar nicht mehr so sicher, ob das grundsätzlich mit einfachen Heimroutern umzusetzen ist, so wie ich das ursprünglich mal dachte.
Deine WAN Überlegungen haben mir darauf gebracht, normalerweise machen die Router ja WAN to LAN bzw. LAN to WAN Routing. Bei dir wäre es LAN to LAN, dafür sind die natürlich meistens nicht gedacht.

 

[HominiLupus]

Nicht wirklich. Schau mal nach wie bzw. wofür 169.254.0.0/16 definiert ist!

Ja ich weiß daß die IP lokal funktionieren würde. Es ist aber in aller Regel trotzdem ein Fehler im Netzwerk und keine gute Idee diese IP als gottgegeben hinzunehmen. Tust du ja aus gutem Grund auch nicht.
Du hast natürlich Recht wenn du 2 Router a la RPi vorzuschalten vorschlägst, damit würde es dann gehen, aber das ist wiederum imho kein reale Lösung.

Wenn du am Router auf iptables rankommst sollte das schon gehen, da musst du nicht drüber schlafen
Ob ein Routing WAN-LAN oder verschiedene LAN-LAN Subnetze geht ist irrelevant. Einfaches Portforwarding reicht da.
RPi1 mit 192.168.0.101, RPi2 mit 192.168.0.102 und jeder hat an einem 2. Interface ein 169.254.0.0/16 Subnetz hängen. Portfordward auf die jeweils richtige IP von 192.168.0.101 zu 169.254.0.1 und fertig.
Der Client verbindet sich dann eben auf 192.168.0.101 und wird weitergeleitet. Beide 169.254.0.0/16 Geräte sind in ihrem eigenen Subnetz und stören sich nicht mehr.

Man muss aber 2 RPis verwenden weil ein RPi ja nicht gut 2 verschiedene Subnetze mit der gleichen IP im gleichen Linux haben kann.

 

[conf_t]

Wenns Broadcast wäre, wie könnte man dann die Datenherkunft unterscheiden?

An der Source-IP im IP-Header.

z.B: Source-IP 192.168.0.5 Destination IP 192.168.0.255 bei einer /24 Subnetmask

Mir scheint hier ein erhebliches Defizit beim IP- / Netzwerkverständnis vorzuliegen, die man so einfach mit einem Thread nicht beheben kann, so dass es auch verstanden wurde, so sehr sich auch alle bemühen.
Alleine die Idee des Aufbaus halte ich für Pfusch, wie man es richtig macht? Dazu muss man dein Projekt sehr gut kennen. Einfach nur Teilaspekte zu betrachten und hier im Forum nach einer Lösung zu fragen wird für das Projekt nicht zielführend sein. Da hier keiner dein Projekt genau kennt und die Informationen bislang auch wenig hilfreich waren. Aber ein sollte klar sein, zwei Geräte mit der gleichen Adresse anzusprechen geht nicht. Selbt mit PAT musst du mindestens den Portunterscheiden. Du führst das Prinzip der Adressierung (egal ob Real Life oder IT) ad absurdum. Ein Adresse ist da, etwas eindeutig zu identifizieren und du willst Zweideutigkeit. Alleine deshalb ist das Unterfangen mit diesem Ansatz zum Scheitern verurteilt.

Ich rate, dir setze dich mit einem Netzwerkexperten, der dich vor Ort unterstützt kann, zusammen. Oder bilde dich in der Materie fort.

 

[DunklerRabe]

Wenn du am Router auf iptables rankommst sollte das schon gehen, da musst du nicht drüber schlafen
Ob ein Routing WAN-LAN oder verschiedene LAN-LAN Subnetze geht ist irrelevant. Einfaches Portforwarding reicht da.
RPi1 mit 192.168.0.101, RPi2 mit 192.168.0.102 und jeder hat an einem 2. Interface ein 169.254.0.0/16 Subnetz hängen. Portfordward auf die jeweils richtige IP von 192.168.0.101 zu 169.254.0.1 und fertig.
Der Client verbindet sich dann eben auf 192.168.0.101 und wird weitergeleitet. Beide 169.254.0.0/16 Geräte sind in ihrem eigenen Subnetz und stören sich nicht mehr.

Man muss aber 2 RPis verwenden weil ein RPi ja nicht gut 2 verschiedene Subnetze mit der gleichen IP im gleichen Linux haben kann.

Hm ja, mit einem Pi würde das natürlich gehen, aber soweit ich das verstanden habe will er das ja möglichst mit simplen Heimbedarf Plastik Routern machen. Und da bin ich mir nach einer Nacht voll Schlaf ziemlich sicher, dass das mit den meisten nicht geht

 

[chrigu]

ich würde zuerst mal den hersteller dieser kamera in die mangel nehmen, danach kannst du dir gedanken über das anschliessen einer so kastrierten netzwerk-kamera den kopf zerbrechen... ich vermute, ein umprogrammieren der netzwerkkamera ist viel einfacher als du denkst... wahrscheinlich kannst du das sogar selber machen... mit ensprechendem kommunikations-tool

 

[ah_frankfurt]

Auch wenn es mir keiner glauben mag die IP ist unveränderlich. [...]

Auch wenn du es nicht glauben magst: die IPs, die du hast, werden von APIPA vergeben wenn du keine feste IP vergeben hast oder der DHCP-Server (i.A. der Router bei Heimanwendern) dem Gerät aus irgendwelchen Gründen keine IP vergeben kann. siehe hier:
http://www.computerlexikon.com/definition-apipa

 

[Raijin]

ich würde zuerst mal den hersteller dieser kamera in die mangel nehmen, danach kannst du dir gedanken über das anschliessen einer so kastrierten netzwerk-kamera den kopf zerbrechen...

Ganz meine Meinung. Es ist zwar klasse, dass hier Lösungsansätze .. .. besser gesagt Workaounds diskutiert werden, aber wenn man die Ursache aus der Welt schafft - falsche/doppelte IP in den Kameras - wird es aus dem Stand heraus funktionieren. Ich würde in jedem Fall mit dem Hersteller sprechen.

Das ist im übrigen nicht so abwegig wie man denkt. Einer unserer Lieferanten (Laser-Distanz-Sensoren) hat auf meinen Anruf hin binnen kürzester Zeit die Firmware der Sensoren aktualisiert, weil man dort ursprünglich kein Default-Gateway angeben konnte (nur IP+Subnetzmaske).

Ein Anruf bzw. eine eMail kann also nicht schaden. Wenn's klappt, hat man das Problem in einem Bruchteil der Zeit aus der Welt geschafft, die es dauern würde einen der Workarounds ohne fundierte Netzwerkkenntnisse umzusetzen.

Alternativ besorgt man sich eben richtige Kameras und nicht so einen Schund.

 

[DunklerRabe]

Auch wenn du es nicht glauben magst: die IPs, die du hast, werden von APIPA vergeben wenn du keine feste IP vergeben hast oder der DHCP-Server (i.A. der Router bei Heimanwendern) dem Gerät aus irgendwelchen Gründen keine IP vergeben kann. siehe hier:
http://www.computerlexikon.com/definition-apipa

Wie oft denn noch?
Es ist mit Sicherheit kein APIPA. Damit es APIPA wäre müsste auf den Kameras ein Microsoft Produkt laufen. Eventuell ist es Zeroconf, ja. Das Computerlexikon ist an der Stelle einfach falsch. APIPA ist kein Begriff, der gleichwertig zu Zeroconf zu verwenden ist. Es ist nur eine Implementation von Zeroconf. Und nicht jedes Gerät macht zwingend Zeroconf nach einem fehlgeschlagenen DHCP Request.

Wir sind uns ja alle einig, dass da ordentlich was schief läuft bzw. irgendwann mal schief gelaufen ist. Sei es beim Hersteller oder bei wem auch immer. Aber immer wieder zu behaupten, dass hier ja offensichtlich ein Problem vorliegt, weil genau so offensichtlich APIPA Adressen vergeben wurden, ist nicht zielführend. Das ist einfach nur falsch.

 

[xexex]

Es ist mit Sicherheit kein APIPA. Damit es APIPA wäre müsste auf den Kameras ein Microsoft Produkt laufen. Eventuell ist es Zeroconf, ja.

Wenn du schon an den Begriffen weiterhin rumreiten möchtest, dann ist deine Aussage auch nicht richtig. Zeroconf ist mehr als nur Aushandlung der Adressen, sondern ist ein Oberbegriff für alle Techniken wie APIPA, UPnP, mDNS oder Bonjour.
http://www.zeroconf.org/

Die reine Aushandlung der Adressen wird unter dem RFC3927 geführt und heißt offiziell "Dynamic Configuration of IPv4 Link-Local Addresses" bzw."link-local address autoconfiguration". Microsoft nennt diese Technik in letzter Zeit unter dem weit besser zu merkenden Begriff "Automatic Private IP Addressing (APIPA)".

Und wenn ich schon dabei bin...

Das Stichwort heißt Zeroconf, offiziell ist das aber tot.

Das "halbe" IPv6 Protokoll basiert auf Zeroconf. Automatische Adressvergabe, automatische Routersuche, Präfixerkennung etc. Diese Aussage ist einfach Quatsch.

Die Geräte verhalten sich so oder so falsch und dürfen diese Adressen nicht für sich beanspruchen.

2.1. Link-Local Address Selection


When a host wishes to configure an IPv4 Link-Local address, it
selects an address using a pseudo-random number generator with a
uniform distribution in the range from 169.254.1.0 to 169.254.254.255
inclusive.

The IPv4 prefix 169.254/16 is registered with the IANA for this
purpose. The first 256 and last 256 addresses in the 169.254/16
prefix are reserved for future use and MUST NOT be selected by a host
using this dynamic configuration mechanism.

2.2. Claiming a Link-Local Address


After it has selected an IPv4 Link-Local address, a host MUST test to
see if the IPv4 Link-Local address is already in use before beginning
to use it. When a network interface transitions from an inactive to
an active state, the host does not have knowledge of what IPv4 Link-
Local addresses may currently be in use on that link, since the point
of attachment may have changed or the network interface may have been
inactive when a conflicting address was claimed.

https://tools.ietf.org/html/rfc3927

 

[DunklerRabe]

Keine Sorge, meine Aussage ist schon richtig. Zeroconf als Oberbegriff und APIPA als ein Beispiel einer Zeroconf Implementation habe ich hier schon erwähnt. Das originale Zeroconf der entsprechenden Arbeitsgruppe ist tot, da musst du in der Zeit etwas zurückgehen. Es war als übergreifender Standard gedacht, dein Link erklärt es. Das die Idee nicht aufgegeben wurde ist ja offensichtlich, aber das hat auch nie jemand bezweifelt.

Worüber ich mich ärgere ist das hier Leute offensichtlich nicht lesen was bisher geschrieben wurden und ganz selbstverständlich annehmen, dass die Kameras hier ein APIPA "Problem" haben.
Das wir es hier mit ranziger Hardware zu tun haben und so ein Problem gar nicht existieren sollte ist ja auch unstrittig.

 

[xexex]

Keine Sorge, meine Aussage ist schon richtig. Zeroconf als Oberbegriff und APIPA als ein Beispiel einer Zeroconf Implementation habe ich hier schon erwähnt.

Nö! Du bringst den Begriff in einen absolut falschen Kontext! Zeroconf ist NICHT APIPA nicht unter Apple und auch nicht unter Linux.

Das Zusammenspiel von Link-Local-Adressen, MDNS und Service Discovery hat die IETF unter dem Namen Zeroconf Networking spezifiziert [5]. Dessen Umsetzung durch Apple heißt Bonjour (anfangs Rendezvous), die Open-Source-Implementierung von Lennart Poettering und Trent Lloyd nennt sich Avahi [6]. Sie unterstützt mittlerweile Link-Local-Adressen sowohl unter IPv4 als auch unter IPv6. Standardmäßig ist die Version 6 aber deaktiviert, weil die meisten lokalen Netzwerke IPv4 verwenden. http://www.linux-magazin.de/Ausgaben/2013/01/Zeroconf

Avahi und Bonjour sind Zeroconf Implemetierungen, APIPA hingegen nicht weil es nur die reine automatische Adressvergabe im Microsoft Sprachwerk bezeichnet und keine Diensterkennung oder sonstiges beinhaltet. Microsoft hat sich mit UPnP an einer eigenen Zeroconf Implementierung versucht und setzt mittlerweile auf Standards wie IPv6, LLDP und WS-Discovery. Wenn du APIPA nicht "magst" dann solltest du von der automatischen Adressvergabe reden und nicht von Zeroconf.

Zurück zum Thema

Worüber ich mich ärgere ist das hier Leute offensichtlich nicht lesen was bisher geschrieben wurden und ganz selbstverständlich annehmen, dass die Kameras hier ein APIPA "Problem" haben.

Der Punkt ist folgender.

Bisher hat der TE nicht einmal versucht die Kameras an einen Router mit DHCP zu hängen, noch hat er genaueres zu den Systemen gesagt. Gepaart mit dem beschränkten Fachwissen des TE und dem beharren auf einer Pfuschlösung entstehen nun mal unnötige Spekulationen.

ICH kann mir nicht vorstellen, dass ein Hersteller seiner Kamera eine Adresse aus dem für Autokonfiguration reservierten Bereich fest zuweist. So dumm sollte kein Hersteller sein und es gibt keinen sinn diesen Bereich zu benutzen. Fest "verdrahtete" Adressen nimmt man immer aus den bekannten privaten Adressbereichen, was die Sache nicht besser aber wahrscheinlicher machen würde.

Hier hat also jemand gepfuscht und solange nicht geklärt wurde welche Geräte es sind und kein Versuch unternommen wurde diese Geräte an einen DHCP Server zu hängen, ihnen per RARP eine Adresse zu verpassen oder per Wireshark zu prüfen wie sie zu kommunizieren versuchen bin ich hier auch raus.

 

[Raijin]

Ruhig Blut Leute. Eine Diskussion über die Feinheiten und Zusammenhänge zwischen APIPA und ZeroConf sind alles andere als zielführend und müllen den Thread nur zu. Lasst uns mal wieder zum Problem des TE zurückkommen.

Ich persönlich halte nichts von Workarounds, weil ich eigentlich fest davon ausgehe, dass man den Kameras eben doch eine IP geben kann. Sei es durch statische Eingabe oder eben via DHCP. Gerade im industriellen Bereich kann ich mir solch einen Pfusch nämlich nicht vorstellen. China-Consumer-Ware ist etwas anderes, aber wenn das wirklich industrietaugliche Geräte sind, dann tippe ich stark auf Fehlbedienung - sorry @TE.

Wenn man Hersteller und Typ wüsste, könnte man ja recherchieren... ...

 

[DunklerRabe]

Ich ging ja auch davon aus, dass diese IPs nicht fest sind. Er ist sich aber sicher, dass sie es sind. In meiner Vorstellung existiert so ein Murks nicht, denn das wäre wirklich ein Ding. Was soll man da sagen? Ich werde nicht anfangen das in Frage zu stellen, es ist immerhin sein Problem. Wenn jemand sein Problem beschreibt und nach mehrmaligem Hinweis auf die Unwahrscheinlichkeit bei der ursprünglichen Variante bleibt, dann kann ich damit leben. Vielleicht ist es ja auch wahr und wir liegen alle falsch, dann braucht man so einen ranzigen Workaround wirklich.

 

[t-6]

Um noch mal einen Level zurück zu gehen:
-exakt dieselbe IP bei beiden Geräten fix vergeben ist unwahrscheinlich; Wäre es eine halbwegs korrekte APIPA/Zeroconf/Schlagwort-Implementation, würden die beiden Geräte sich jeweils im Bereich 169.254.1.1 - 169.254.254.255 eine IP herholen (minus 256 am Anfang und am Ende dieses Bereiches); tun sie aber nicht; die Geschichte ist nicht sauber implementiert bzw. gar nicht implementiert da die IP 169.254.0.1 ist - also außerhalb des Zerconf-Bereiches.

1) Die Cams wurden mit dieser Konfiguration so übergeben (Hersteller?) & müssen manuell umkonfiguriert werden; TE findet Konfiguration nicht
2) Es handelt sich nur um die zusätzliche Fallback-Adresse für diese Cams & die "korrekte" IP-Adresse wird an anderer Stelle eingestellt; möglicherweise warten die Cams auf einen DHCP-Server & anhand der MAC kann beim DHCP-Server die IP der jeweiligen Cam identifiziert werden
3) Es ist wirklich die einzige, fix eingestellte IP und es lässt sich nicht ändern -> an dieser Stelle den Hersteller anrufen und ob des Blödsinns zusammenstauchen

===

Die Geschichte mit zwei Routern nur für die beiden Kameras ist Pfusch, der Pfusch hinterhergeworfen wird, sofern 3) stimmen sollte.