Netzwerkgeräterkennung

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Netzwerkgeräterkennung

    Hallo,

    ich habe die Aufgabe unter OSX ein Gerät, das an mein Netzwerk angeschlossen wurde, zu finden.
    Das Gerät hat typischerweise nicht die IP Adresse die in mein Netz passt.

    Wie könnte ich das tun?

    Wenn ich es gefunden habe, möchte ich es ansprechen ohne das der Benutzer die Netzwerkeinstellungen in der Systemsteuerung verändern muss, um es dann in das richtige Netz zu konfigurieren.


    Wie könnte ich das tun?


    Viele Grüsse
    Jürgen
  • Hum, wir haben hier GigE Kameras, da ist ein Tool dabei, das genau das macht (aber speziell für diese Kameras) - von daher geht es wohl irgendwie. Eventuell direkt über Ethernet und ohne IP? Damit sie funktionieren, müssen sie aber im gleichen Netz sein, aber man kann, wenn ich mich recht erinnere, über das Tool die IP# anpassen...
    C++
  • Könnte über einen Ethernet Broadcast gehen. Weiss aber nicht ob dir da irgendwelche Switche einen Strich durch die Rechnung machen.
    Wenn du dann die MAC hast kannst du die IP mit arp -s vorläufig eintragen und konfigurieren.

    Chris
    Man macht einfach solange irgendwelche Dinge, bis man tot ist.
    Und dann bekommen die anderen Kuchen.
  • zerm schrieb:

    Hum, wir haben hier GigE Kameras, da ist ein Tool dabei, das genau das macht (aber speziell für diese Kameras) - von daher geht es wohl irgendwie. Eventuell direkt über Ethernet und ohne IP? Damit sie funktionieren, müssen sie aber im gleichen Netz sein, aber man kann, wenn ich mich recht erinnere, über das Tool die IP# anpassen...


    Ich koennte mir vorstellen, dass die Kameras mit einer festen IP konfiguriert ausgeliefert werden und dann kann man sie ja auch ansprechen. Oder sie arbeiten mit DHCP. Dann muss ich nur 255 Adressen durch probieren wo jemand antwortet. Aber wenn ich gar nichts weiß wird es schwierig

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Thallius schrieb:

    Dann muss ich nur 255 Adressen durch probieren wo jemand antwortet.

    Nicht alle Netze haben die Subnetmask 255.255.255.0 ... es können durchaus ein paar Adressen mehr sein. Chris' Broadcast ist m. E. schon der richtige Weg, quasi selber DHCP spielen ... allerdings muss der Client schon im gleichen Netz sein, sonst ist er mangels korrektem Gateway gar nicht in der Lage, zu antworten ...

    Mattes

    Edit: ... und erhält natürlich auch erst gar nicht den Broadcast (war gestern wohl schon zu spät)
    Diese Seite bleibt aus technischen Gründen unbedruckt.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von MyMattes ()

  • MyMattes schrieb:

    Thallius schrieb:

    Dann muss ich nur 255 Adressen durch probieren wo jemand antwortet.

    Nicht alle Netze haben die Subnetmask 255.255.255.0 ... es können durchaus ein paar Adressen mehr sein. Chris' Broadcast ist m. E. schon der richtige Weg, quasi selber DHCP spielen ... allerdings muss der Client schon im gleichen Netz sein, sonst ist er mangels korrektem Gateway gar nicht in der Lage, zu antworten ...

    Mattes


    Stimmt, theoretisch hast du recht. Ist mir in der Prxis aber noch nie vorgekommen.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Chris schrieb:

    Könnte über einen Ethernet Broadcast gehen. Weiss aber nicht ob dir da irgendwelche Switche einen Strich durch die Rechnung machen.
    Wenn du dann die MAC hast kannst du die IP mit arp -s vorläufig eintragen und konfigurieren.

    Ja, das klingt sinnvoll. Ich glaube, wir hatten die Kameras auch mal hinter einem Switch und sie so trotzdem wieder konfigurieren koennen....Eventuell broadcasten die Devices auch, um sich mit dem Switch bekannt zu machen, so dass er weiss, welche MACs so rumhaengen? Aber alles nur Spekulation und auch schon eine Weile her..
    C++
  • Thallius schrieb:

    MyMattes schrieb:

    Thallius schrieb:

    Dann muss ich nur 255 Adressen durch probieren wo jemand antwortet.

    Nicht alle Netze haben die Subnetmask 255.255.255.0 ... es können durchaus ein paar Adressen mehr sein

    Stimmt, theoretisch hast du recht. Ist mir in der Prxis aber noch nie vorgekommen.

    Mir hingegen relativ häufig. Spaßig ist auch die Subnetzsmaske 255.255.192.0. Dann hast du nicht nur signifikant mehr als 253 Adressen (Die Network [192.168.1.0] und die Broadcast [192.168.1.255] geht man per se nicht durch*...), sondern auch noch vier unterschiedliche Subnetze...

    C-Quellcode

    1. 192.168. 0.1 - 192.168. 63.254
    2. 192.168. 64.1 - 192.168.127.254
    3. 192.168.128.1 - 192.168.191.254
    4. 192.168.192.1 - 192.168.255.254


    Wenn das Gerät nicht eigenständig herausfinden kann, in welches Netz es gehängt wurde, dann wird das Ganze äußerst kompliziert.

    Von der eigenen DHCP-Lösung rate ich dringend ab, weil das schlicht das komplette Netzwerk auseinandernehmen kann. Der Netzwerkadministrator wird ausrasten und der Enduser die Software verdammen.
    (DHCP in eigenes Subnetz: keiner kommt ins eigentliche Netzwerk. DHCP in eigentliches Netzwerk: IP-Adressenkonflikte; Offener Zugriff für Geräte, die dort nix zu suchen haben etc.pp.)

    Also einfach mal das Gerät ins Netz hängen und den Netzwerktraffic beobachten.
    Wie zerm schon sagte kann es durchaus sein, dass besagtes Gerät einmal die Ethernet broadcasted. Das würde ich als Erstes probieren. Doch ohne OSI Layer 3 wird das Ganze vermutlich haarig.

    Ich weiß nicht, ob man irgendwie einen eigenen Layer 3 implementieren kann, sofern Layer 2 bekannt ist.
    (Sprich: etwas Anderes als TCP/IP nutzen, wenn die MAC bekannt ist.)

    * Klar, für Broadcast-Anfragen wird natürlich die Broadcast-Adresse angefragt. Was man jetzt mit der Network-Adresse macht weiß ich nicht so genau.
    Jedenfalls sind gemäß TCP/IP Standard beide Adressen reserviert und nicht für Endgeräte nutzbar.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Lucas de Vil schrieb:

    Spaßig ist auch die Subnetzsmaske 255.255.192.0. Dann hast du nicht nur signifikant mehr als 253 Adressen (Die Network [192.168.1.0] und die Broadcast [192.168.1.255] geht man per se nicht durch*...), sondern auch noch vier unterschiedliche Subnetze...

    Das verstehe ich jetzt nicht: Bei 255.255.192.0 hast Du doch einfach nur die letzten 6 Bits 14 Bits für den Knoten, wobei 0x000 die Netzadresse und 0xFFF Broadcast wären. Bei einem Netz 192.168.0.0 wäre die Broadcast also 192.168.63.255 und es gibt eben Knoten-Adressen zwischen 192.168.0.1 und 192.168.63.254 ...

    C-Quellcode

    1. Subnetmask: 11111111.11111111.11000000.00000000 = 255.255.192.0
    2. Netz: 11000000.10101000.00000000.00000000 = 192.168.0.0
    3. Broadcast: 11000000.10101000.00111111.11111111 = 192.168.63.255
    4. Knoten liegen eben zwischen Netz- und Broadcastadresse

    Oder was bringe ich gerade durcheinander?

    Und der Hinweis mit DHCP war eher auf das Broadcasting zur Adressfindung gemeint, auch wenn hier der Server "ruft" ... Mehrere DHCPs in einem Netz sind bäh!

    Mattes

    Edit: Ups, nicht 6 Bits ... :rolleyes:
    Diese Seite bleibt aus technischen Gründen unbedruckt.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von MyMattes ()

  • Vielen Dank für den Input, damit ich bin etwas weiter gekommen in meinem Vorhaben.

    wenn ich im Term arp -al mache bekomme ich

    Quellcode

    1. Neighbor Linklayer Address Expire(O) Expire(I) Netif Refs Prbs
    2. 192.168.10.7 68:xx:xx:xx:xx:xx expired expired en1 1
    3. 192.168.10.14 68:xx:xx:xx:xx:xx (none) expired en1 1
    4. 192.168.10.250 68:xx:xx:xx:xx:xx 17s 17s en1 1
    5. 192.168.10.255 ff:ff:ff:ff:ff:ff (none) (none) en1


    Das gerät das die 192.168.1.1 hat wird nicht angezeigt. Scheinbar werden nur ARP Reponses die zu meinem Netz gehören aufgenommen.

    Ich habe nun eine Lib gefunden:
    libpcap.A.dylib die unter BSD 3 veröffentlicht ist.

    Mit dieser bekomme ich ( nicht vollständig )

    Quellcode

    1. 192.168.10.249 68:xx:xx:xx:xx:xx Cisco-Linksys, LLC
    2. 192.168.10.14 68:xx:xx:xx:xx:xx Apple Computer
    3. 192.168.10.250 68:xx:xx:xx:xx:xx Apple Computer
    4. 192.168.1.1 68:xx:xx:xx:xx:xx Apple, Inc


    Aber hier habe ich mein Gerät 192.168.1.1, das ich nun nach Vendor identifizieren kann und als nächstes mir ein SubInterface mit ipconfig einrichte.
    ifconfig en0 alias 192.168.1.2 netmask 192.0.0.0
    Mit meiner Mask dürfte dürfte mir die Maske des Gerätes egal sein.
  • MyMattes schrieb:

    Oder was bringe ich gerade durcheinander?

    Gar nichts bringst du durcheinander. :)
    Mein Beispiel in den Klammern bezog sich schlicht auf 192.168.1.0/24. ^^

    Wie dem auch sei, wenn mein Subnetz zufällig 192.168.178.0/18 wäre, das Gerät intern schon mal die 192.168.1.123/8 voreingestellt hat und damit rein theoretisch mit dem Netz kommunizieren könnte, passiert dennoch gar nichts.
    Die Anfrage auf die Broadcast läuft dann schlimmstenfalls im völlig falschen Netz auf, weil das 192.168.0.x und damit das Subnetz mit dem Gerät logisch vom 192.168.128.x und damit dem Subnetz des Rechners getrennt ist.

    Deshalb meinte ich, dass es für subnetzübergreifende Konfiguration irgend etwas Eigenes unterhalb TCP/IP geben muss, da dieses mit viel zu vielen variablen Größen verbunden ist.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Lucas de Vil schrieb:

    Mir hingegen relativ häufig. Spaßig ist auch die Subnetzsmaske 255.255.192.0. Dann hast du nicht nur signifikant mehr als 253 Adressen (Die Network [192.168.1.0] und die Broadcast [192.168.1.255] geht man per se nicht durch*...), sondern auch noch vier unterschiedliche Subnetze...

    C-Quellcode

    1. 192.168. 0.1 - 192.168. 63.254
    2. 192.168. 64.1 - 192.168.127.254
    3. 192.168.128.1 - 192.168.191.254
    4. 192.168.192.1 - 192.168.255.254

    Wieso nur vier Subnetze? Mit einer Subnetzmaske von 255.255.192.0 hast Du 18 Bits für den Netzanteil zur Verfügung, macht also 2^18 Subnetze (abzüglich der reservierten Bereiche). Du beschränkst Dich hier auf einen konkreten Adressbereich.

    Lucas de Vil schrieb:

    * Klar, für Broadcast-Anfragen wird natürlich die Broadcast-Adresse angefragt. Was man jetzt mit der Network-Adresse macht weiß ich nicht so genau.
    Jedenfalls sind gemäß TCP/IP Standard beide Adressen reserviert und nicht für Endgeräte nutzbar.

    Warum die Network-Adresse nicht für Endgeräte zur Verfügung steht, wissen viele nicht. Wenn man mal rum fragt, bekommt man fast immer sofort als Antwort: „na weil das das Netz ist.“ Und wenn man dann nachbohrt, was denn „das Netz“ ist, weil man trägt das ja nirgends ein, dann ist oft Achselzucken angesagt. Die richtige Antwort ist schlicht „das Netz“ (alles auf 0 im Hostanteil) wurde früher als Broadcast Adresse verwendet, ist also ebenfalls eine Broadcast Adresse.
    Bei Router-Router Kopplungen benutzt man übrigens heutzutage die beiden Broadcast Adressen auch als Hostadressen.

    Lucas de Vil schrieb:

    Deshalb meinte ich, dass es für subnetzübergreifende Konfiguration irgend etwas Eigenes unterhalb TCP/IP geben muss, da dieses mit viel zu vielen variablen Größen verbunden ist.

    Subnetzübergreifende Konfiguration ist doch irgendwie sinnfrei. Wenn ich ein Endgerät konfigurieren möchte, damit ich damit kommunizieren kann, dann sollte es schon in meinem Netz sein, sonst brauche ich einen Router.
    Ach ja, unterhalb von TCP/IP läuft heutzutage üblicherweise das Ethernet-Protokoll.

    Michael
  • Die Abfrage der Kameras wird sicherlich über UDP broadcast messages laufen. Es ist auch einfach das heraus zu finden.
    Wireshark starten und Netzwerkkommunikation aufzeichnen. Original Soft des Kameraherstellers die Kameras suchen lassen. Nach dem Finden einer Kamera, die Aufzeichnung der Netzwerkkommunikation stoppen.

    In den Daten ist dann sehr klar zu sehen welche Anfrage über welches Protokoll gesendet wurde und was die Kamera geantwortet hat.

    Das habe ich schon mal mit den Prosilica Kameras gemacht.
  • Wenn es wirklich GigE Vision Kameras sind, ist die Device Discovery im Standard spezifiziert (ja, über UDP Broadcast). In dem Fall würde ich auch nur das machen, was im Standard steht, alles andere dürfte eine ziemlich unzuverlässige Fummelei werden. Allerdings hatte ich im Ursprungspost nichts von Kameras gelesen.

    Um welche Geräte handelt es sich eigentlich? Wenn es für sie irgend eine Spezifikation gibt, würde ich als erstes mal da reinschauen, ob dort Discovery geregelt ist.
    Multigrad - 360°-Produktfotografie für den Mac
  • bachelor schrieb:

    Hallo mattik,

    da habe ich heute etwas in Eile durcheinander gebracht. Ich habe die Benutzer verwechselt.
    Bei dem Fragesteller geht es wahrscheinlich nicht um GigE Kameras.

    Hehe, ich wäre fast selbst drauf reingefallen, habe erst spät bemerkt, dass zerm das als Beispiel eingebracht hatte. Und dabei ist mir aufgefallen dass wir gar nicht wissen, was das überhaupt für Geräte sind.

    Eine allgemeine Lösung, wie man beliebige, beliebig konfigurierte Geräte in beliebigen Netzwerktopologien auffinden kann, kann ich mir nicht vorstellen. Vielleicht hat ja der Gerätehersteller diese Situation bedacht, dann könnte man da den Trick suchen. Aber allgemein wird das vermutlich wildes Gestocher.
    Multigrad - 360°-Produktfotografie für den Mac