Ich betreibe mehrere Lantronix Xport per DHCP in einem Netz und muss
anhand ihrer MAC die jeweils gültige IP-Adresse zwecks Kommunikation
finden.
Bei entsprechender Googel-Suche findet man immer wieder den Hinweis, man
solle das mit "ARP -a" machen.
Das ist aber Humbug, denn in der lokalen ARP-Tabelle findet sich nur
dann ein Eintrag, wenn bereits einmal eine Kommunikation bestand - und
das ist in meinem Falle eben genau nicht der Fall. Gibts da irgend einen
Trick, im Netz ein "allgemeines ARP-Brüllen" auszulösen? Danke für Tips.
Du könntest herausfinden, was das Lantronix-eigene Tool macht, das im
Netzwerk nach vorhandenen XPorts sucht. Mit Wireshark o.ä. könnte sich
da etwas protokollieren lassen.
Man könnte einen Durchgang Port-Connect (und gleich wieder trennen)
durch das gesamte Segment machen ... wird aber bei Supernetting
kompliziert zu berechnen. Danach könnte die IP im Arp-Cache stehen, aber
ist das cool?
Frank schrieb:> Ich betreibe mehrere Lantronix Xport per DHCP in einem Netz und muss> anhand ihrer MAC die jeweils gültige IP-Adresse zwecks Kommunikation> finden.
es gibt keine standardisierte Möglichkeit von der MAC auf die IP zu
kommen. Man müsste den DHCP server befragen denn er weiss es ja.
A) den in frage kommenden Bereich mittels diversen Tools (Superscan),
durchpingen, dann hast du mit arp -a die MAC.
oder
B) auf dem DHCP nachschauen.
oder
C) mit Wireshark lauschen
Frank schrieb:> Habe da etwas gefunden. Die Pingen vorher auf die Broadcast-Adresse (zu> errechnen aus IP-Adresse und Subnetzmaske) und dann ist der Arp-Cache> gut gefüllt ...
nur wenn das system auf der Broadcast-Adresse antwortet, was aber nicht
alles System machen.
Frank schrieb:> Ich betreibe mehrere Lantronix Xport per DHCP in einem Netz und muss> anhand ihrer MAC die jeweils gültige IP-Adresse zwecks Kommunikation> finden
Ich meine die letzten 4 Stellen der MAC (steht im Userguide) sind der
Name unter welchem sich die Teile beim DHCP anmelden, dann kannst du
diesen nutzen um die Teile anzusprechen.
Läubi .. schrieb:> Ich meine die letzten 4 Stellen der MAC (steht im Userguide) sind der> Name unter welchem sich die Teile beim DHCP anmelden, dann kannst du> diesen nutzen um die Teile anzusprechen.
Mag sein, aber dann muss ich mich ja noch zusätzlich mit dem DHCP-Server
unterhalten, oder habe ich da etwas missverstanden? Ich bin gerade
dabei, ein par passende Routinen (Broadcast-Adresse errechnen, Pingen
und Arp parsen) in RealStudio (ehem. RealBasic) umzusetzen ... scheint
zu klappen.
Frank schrieb:> Mag sein, aber dann muss ich mich ja noch zusätzlich mit dem DHCP-Server> unterhalten, oder habe ich da etwas missverstanden?
nein mit dem DNS server.
Wenn du z.b. eine FritzBox hast dann kannst du die Geräte unter
AABBCCDD.fritz.box erreichen. Dann der DHCP server macht einen passenden
eintrage in den DNS server. den DNS server musst du nicht wissen, da
kannst du einfach eine verbindung aufbauen - nur nicht zu der IP sondern
zu dem DNS namen.
Peter II schrieb:> Wenn du z.b. eine FritzBox hast dann kannst du die Geräte unter> AABBCCDD.fritz.box erreichen.
Es reicht am Ende einen '.' also z.B.
1
AABBCCDD.
und die Namensauflösung macht Windows dann ganz allein für dich...
Hi Frank,
Du ordnest mit arp -s der bekannten MAC eine IP-Adresse aus Deinem
Subnetz hinzu und kannst dann über diese Adresse das Gerät ansprechen.
VG
Volker
Läubi .. schrieb:> Es reicht am Ende einen '.' also z.B.AABBCCDD. und die Namensauflösung> macht Windows dann ganz allein für dich...
nein macht es nicht (immer). Die windows namens auflösung funktion auf
SMB Basis, ich glaube kaum das der Xport das hat.
eine FQN mit . am ende ist sogar falsch, dann der domain teil fehlt
damit. Ohne den . würde windows nach die eigene Domaine mit anhängen
wenn sie verfügbar ist.
Das ganze ist dann aber auch abhängig vom Router. ein Richtiger
eindeuter FQN ist immer noch AABBCCDD.fritz.box. also der Punkt am ende
aber mit domaine.
Volker G. schrieb:> Du ordnest mit arp -s der bekannten MAC eine IP-Adresse aus Deinem> Subnetz hinzu und kannst dann über diese Adresse das Gerät ansprechen.
auch dan geht nur bei einigen geräten, man kann nicht jedes Gerät mit
jeder IP so einfach ansprechen. Wenn der IP -Stack die eigene IP Prüft
dann geht das auch nicht.
Ich möchte so wenig wie möglich auf die Mitwirkung von fremden Geräten
und Diensten angewiesen sein. Im Moment experimentiere ich zuhause, aber
wenn es mal reif ist, soll es auch "extern" (Firmennetze) genutzt
werden.
Es handelt sich übrigns um einfache Kommt-Geht-Terminals zur
Zeiterfassung, bestehend aus einem RFID-Reader verbunden mit einem
Xport. Zusätzlich hängen an den GPIOs noch zwei LEDs (rot, grün) und ein
Piezopiepser ...
Frank schrieb:> Ich möchte so wenig wie möglich auf die Mitwirkung von fremden Geräten> und Diensten angewiesen sein. Im Moment experimentiere ich zuhause, aber> wenn es mal reif ist, soll es auch "extern" (Firmennetze) genutzt> werden.
dann mach es auch so, wie es andere machen. Das Gerät wird mit einer
Standard IP ausgeliefert und wird dann passend zum firmennetzt
angepasst. In der Software wird dann die IP ingegetragen.
Firmennetze habe auch schnell mal mehre SubNetzte dort kommst du mit
deinem Verfahren eh nicht mehr weiter.
Hallo Frank,
darf man fragen wo du die X-Port besorgt hast und was die gekostet haben
?
Bin gerade auf der Suche nach einem X-Port der RS485 kann, aber 30-40
US$ Versandkosten sind mir bei Lantronix zu viel.
Danke
Gruß Matthias
DirkB schrieb:> Das Protokoll dafür gibt es bereits: RARP> Ob das in deinem Netz unterstützt wird weiß ich allerdings nicht.
hast du dir mal durchgelesen was RARP macht? Das ist der Vorgänger von
DHCP oder BootP. Es hilft hier überhaupt nicht weiter.
OSI schrieb:> Werft einen Blick ins OSI Modell. Die Schichten 1 und 2 mit MAC Adresse> können die IP auf 3 nicht sehen.
und was willst du damit sagen?
Es hätte ja drozdem jemand das das gegenteil "Get-MAC-For-IP" definieren
können.
Peter II schrieb:> und was willst du damit sagen?
Der IP Kram ist für die unteren Schichten reine Nutzdaten. Inhaltlich
gibt's da nichts zu bewerten. Es müssen ja nicht IP Daten sein.
OSI schrieb:> Der IP Kram ist für die unteren Schichten reine Nutzdaten. Inhaltlich> gibt's da nichts zu bewerten. Es müssen ja nicht IP Daten sein.
er will aber mit dem Gerät über IP Kommunizieren, und da ist die frage
wie man zu einer MAC die vergebenene IP rausbekommt. Und dafür gibt es
leider kein Standard. Ich hatte schon selber oft das Problem das ich ich
Geräte ans Netzt angeschlossen habe und dann erstmal die IP ermitteln
musste. Ich hatte aber immer zugriff auf den DHCP Server und da konnte
man es abfragen.
Peter II schrieb:> Gerät über IP Kommuniziere
Liest Du auch bevor Du antwortest?
Du kannst über Ethernet oder auch ein serielles Kabel per IP
kommunizieren. Dem IP sind die unteren Schichten sch... egal. Die
unteren Schichten wissen nicht, was sie übertragen. IP-Pakete inkl.
Header und Co. sind für sie nur Nutzdaten.
Was ich damit sagen will: Die Protokolle wissen nichts von einander.
Matthias schrieb:> darf man fragen wo du die X-Port besorgt hast und was die gekostet haben> ?
Die gibts bei Ebay zu 19 Euro das Stück, man muss sie aber von einer
Plaine herunterlöten.
OSI schrieb:> Was ich damit sagen will: Die Protokolle wissen nichts von einander.
nein, dann man kann die MAC zu einer IP über ARP abfragen. Also wissen
sie doch etwas voneinandern.
Peter II schrieb:> Läubi .. schrieb:>> Es reicht am Ende einen '.' also z.B.AABBCCDD. und die Namensauflösung>> macht Windows dann ganz allein für dich...>> nein macht es nicht (immer). Die windows namens auflösung funktion auf> SMB Basis, ich glaube kaum das der Xport das hat.
Also bei mir klappt es unter Win einwandfrei auf diese Weise, ob das
jetzt Windows, der DHCP, oder wer auch immer macht ist doch unerheblich,
Versuch macht klug.
> eine FQN mit . am ende ist sogar falsch, dann der domain teil fehlt> damit. Ohne den . würde windows nach die eigene Domaine mit anhängen> wenn sie verfügbar ist.
s.o. ohne Punkt wollte er bei mir nicht sich zur Zusammenarbeit bewegen
lassen.
> Das ganze ist dann aber auch abhängig vom Router. ein Richtiger> eindeuter FQN ist immer noch AABBCCDD.fritz.box. also der Punkt am ende> aber mit domaine.
Das ganze ist von vielem Abhängig, der TE schrieb ja leider nicht gleich
was es werden soll für ein privates Netzt und Eigengebrauch hätte man es
ja einfach mal probieren können.
Ansonsten kann man die IP auch per seriell aus dem XPORT auslesen und
z.B. im Servicemenü anzeigen lassen.
es gibt ja geräte die das können
meiner meinung nach gibt es 2 möglichkeiten:
man bleibt bei TCP/IP und sendet eine Broadcast message, woraufhin die
terminals ihre IP adresse + mac zurückschicken..
was natürlich den nachteil hat, dass DHCP vorhanden sein muss..
ipv6 würde IMHO einige möglichkeiten bieten ..
(scheidet aber wohl aus)
oder (meine WLAN antenne kann das IMHO, für FIrmware reparatur)
und noch irgend ein gerät habe ich, dem man so die TCP/IP adresse
einstellen kann (IMHO ein NAS buffalo, weis ich jetzt aber nicht mehr
genau..)
man bleibt eine schicht drunter, kommuniziert also erstmal einfach OHNE
tcp/ip (also schreibt sich selber eine propritäre MAC to IP
geschichte..)
IMHO sollte man aber garnichts von dem machen, sondern so wie "Peter
II" vorschlägt: der sysadmin soll es eintellen..
(die haben das nämlich garnicht so gern, wenn man in deren
Firmennetzwerk irgendwelche "spielchen spielt"...) und wissen auch gerne
was "abläuft"
Robert L. schrieb:> IMHO sollte man aber garnichts von dem machen, sondern so wie "Peter> II" vorschlägt: der sysadmin soll es eintellen..
Die ganze Diskussion ist theoretisch interessant, aber bei XPorts
eigentlich überflüssig: bei realen Anwendungen wird einmal mit den
mitgelieferten Tools die IP-Adresse des XPorts eingestellt, und mit
dieser wird es von der Kontroll-Software zukünftig angesprochen. Dazu
benötigt man überhaupt keinen Server irgendeiner Art im Netz.
Ich würde sowieso empfehlen darüber nachzudenken, ob man dafür nicht ein
eigenes Netz verwenden sollte - die Sysadmins von Firmennetzen in
grossen Firmen schätzen es überhaupt nicht, wenn man "ihrem" Netz
hardwarenahe Messknoten zufügt und i.A. kann man die auch ohne den
Sysadmin überhaupt nicht in Betrieb nehmen. Nach meiner Erfahrung ist es
aber sehr schwierig, einen Kundendiensttechniker, den zuständigen
Abteilungsleiter und einen Firmen-Sysadmin zur gleichen Zeit am gleichen
Ort zusammenzubringen. Und in einem geschützten Firmennetz auf eigene
Faust rumzuarpen o.ä. trifft auf wenig Gegenliebe.
Gruss Reinhard
