Beispielsweise bei zwei USVs mit NMC (Network Management Card), gebraucht über Ebay gekauft, hatte ich keinerlei Dokumentation und musste sogar das Passwort per serieller Konsole (Minicom), und zweimal Resettaster entsprechend den Blink-Codes drücken, zurücksetzen. Deshalb wäre mal interssant zu wissen wie man die unbekannte IP von Geräten ermitteln kann, um erstmal festzustellen ob die überhaupt irgendwie im LAN sind oder defekt/deaktiviert. Gefunden habe ich nur eine Lösung bei bekannter MAC (http://blog.stromzoo.info/hardware/gerate-mit-unbekannter-ip-trotzdem-erreichen-ip-per-mac-adresse-andern/), aber was macht man bei unbekannter MAC? Mein erster Ansatz war "arp -a", aber das zeigte nichts.
wenn das gerät von sich aus etwas sendet kann man es einfach mitlesen. Wenn das gerät nichts senden, kann man einen Broadcast-Ping versuchen. Wenn das auch nicht geht, hat man keine Möglichkeit.
Durchprobieren... Bei völlig unbekannter IP und ohne DHCP (und damit zumindest der Info übers Netz) wirds allerdings mühsam. Oliver
Angry IP Scanner. Macht aber nur Sinn, wenn man das Subnetz ungefähr kennt :)
Rolf F. schrieb: > Gefunden habe ich nur eine Lösung bei bekannter MAC Diese Lösung funktioniert IMHO nur mit extrem kaputten embedded IP Stacks. Mit embedded Linux dürfte das nicht funktionieren, da die Antwort dann an das nicht vorhandene Gateway gehen würde.
Jim M. schrieb: > Mit embedded Linux dürfte das nicht funktionieren, da die > Antwort dann an das nicht vorhandene Gateway gehen würde. das kann man aber mitlesen und schon kennt man den Absender.
ARP wird wohl jedes Netzwerkgerät unterstützen. Versuchs mit "Microsoft Network Monitor" oder "Microsoft Network Analyzer". Dort LAN sniffen und im Filter einfach "ARP" eingeben. Wenn dort kein Reply vom USV zu sehen ist, vermute ich mal einen defekt.
Reginald L. schrieb: > ARP wird wohl jedes Netzwerkgerät unterstützen. Versuchs mit "Microsoft > Network Monitor" oder "Microsoft Network Analyzer". Dort LAN sniffen und > im Filter einfach "ARP" eingeben. Wenn dort kein Reply vom USV zu sehen > ist, vermute ich mal einen defekt. nur weil es ARP unterstützt sendet es doch nicht ungefragt Daten.
Wahrscheinlich weil's in dem Fall wenig bringt. Erster Versuch wär mal 'n DHCP-Server dranzuflanschen und zu gucken ob die Dinger sich 'ne IP-Adresse holen wollen. Nach einem Factory-Default-Reset gar nicht so unmöglich. Wenn das nicht hilft, mal in alle Subnetze die die RFC 1918 hergibt 'n broadcast brüllen und gucken ob was antwortet. Alternative wär natürlich auch noch zu schauen ob's im Internet wo 'n Manual zu dem Ding gibt das vielleicht Aufschluß bietet welche IP-Adresse standardmäßig eingestellt ist. Ganz andere Frage, Du hast Zugriff über die serielle Konsole, da geht nix?
Peter II schrieb: > nur weil es ARP unterstützt sendet es doch nicht ungefragt Daten. Gehört zum OSI-Layer 1. Also bevor du eigentlich mit der Kommunikation anfängst, teilen sich die Geräte auf diese Weise zuvor die MAC Adressen mit.
Reginald L. schrieb: > Peter II schrieb: >> nur weil es ARP unterstützt sendet es doch nicht ungefragt Daten. > > Gehört zum OSI-Layer 1. Also bevor du eigentlich mit der Kommunikation > anfängst, teilen sich die Geräte auf diese Weise zuvor die MAC Adressen > mit. richtig, aber dafür muss das gerät erst mal eine Kommunikation starten.
Peter II schrieb: > richtig, aber dafür muss das gerät erst mal eine Kommunikation starten. Ohne MAC Adressen findet keine "Kommunikation" im eigentlichen Sinne statt.
Oder direkt ohne an den PC und mim WireShark schauen ob du was empfängst. Gruß JackFrost
Reginald L. schrieb: > Peter II schrieb: >> richtig, aber dafür muss das gerät erst mal eine Kommunikation starten. > > Ohne MAC Adressen findet keine "Kommunikation" im eigentlichen Sinne > statt. irgendwie reden wir an einander Vorbei. Ein IP-Gerät was eine IP hat sendet nicht selber einfach einen ARP aus, wenn es keine Verbindung zu jemand aufbauen will. Wenn das Gerät also nur eine "Client" ist, dann sendet es auch keine ARPs wenn es nicht gefragt wird.
Peter II schrieb: > irgendwie reden wir an einander Vorbei. Ein IP-Gerät was eine IP hat > sendet nicht selber einfach einen ARP aus, wenn es keine Verbindung zu > jemand aufbauen will. Wenn das Gerät also nur eine "Client" ist, dann > sendet es auch keine ARPs wenn es nicht gefragt wird.
1 | s/Client/Server/ |
Das Gerät ist wahrscheinlich ein Server, nämlich ein Webserver. Es wird solange still sein, bis es aufgefordert wird zu reden. Daher wird ARP allein nicht reichen, um dem Gerät die nötigen Infos zu entlocken. Außer das Ding telefoniert nach Hause...
:
Bearbeitet durch Moderator
Meist steht auf den Embedded Teilen ja die ARP-Adresse irgendwo drauf. Dann kannst du manuell einen Eintrag in die ARP-Tabelle auf deinem Rechner machen und der HW-Adresse eine beliebige IP-Adresse zuordnen. Und wundersamerweise klappt dann die Verbindung.
Heinz L. schrieb: > Ganz andere Frage, Du hast Zugriff über die serielle Konsole, da geht > nix? Doch, das hat geklappt, aber erst nachdem ich diese speziellen Adapterkabel von APC hatte. Und es wäre ja interessant ohne Spezial-Hardware nachzusehen, im LAN.
Rolf F. schrieb: > Doch, das hat geklappt, aber erst nachdem ich diese speziellen > Adapterkabel von APC hatte. > Und es wäre ja interessant ohne Spezial-Hardware nachzusehen, im LAN. Und Du kannst darüber nicht die IP-Adresse einstellen?
Rolf F. schrieb: > Doch, das hat geklappt, aber erst nachdem ich diese speziellen > Adapterkabel von APC hatte. APC hat doch eigene Software Tools, die suchen doch auch nach bekannten Geräten. Das mit der seriellen Schnittstelle kommt mir auch bekannt vor, die wollen ihre Kabel verkaufen. Da ist glaube ich sogar etwas Hardware im Stecker.
Frank M. schrieb: > Rolf F. schrieb: >> Doch, das hat geklappt, aber erst nachdem ich diese speziellen >> Adapterkabel von APC hatte. >> Und es wäre ja interessant ohne Spezial-Hardware nachzusehen, im LAN. > > Und Du kannst darüber nicht die IP-Adresse einstellen? Doch, aber erst nachdem ich diese Spezial-Hardware hatte. Und allgemein hat man ja keine serielle Konsole.
aus dem APC Manual: 'Sie können den APC Konfigurationsassistenten für Geräte-IPAdressen auf einem Computer mit dem Betriebssystem Microsoft® Windows® 2000, Windows 2003 oder Windows XP verwenden, um unkonfigurierte Netzwerkmanagement- Karten aufzufinden und deren TCP/IP-Einstellungen nacheinander über das Netzwerk zu konfigurieren. 1. Legen Sie die CD mit dem Dienstprogramm für APC Netzwerkmanagement-Karten an einem Computer im Netzwerk ein. 2. Wählen Sie im Hauptmenü den Assistenten für die Konfiguration von Geräte-IP-Adressen. 3. Folgen Sie den Anweisungen am Bildschirm, sobald der Assistent die erste unkonfigurierte Netzwerkmanagement-Karte entdeckt hat. Hinweis Die meisten Software-Firewalls müssen vorübergehend deaktiviert werden, damit der Assistent unkonfigurierte Netzwerkmanagement- Karten auffinden kann. Hinweis Wenn Sie die Option Start a Web browser when finished (Nach Fertigstellung einen Web-Browser starten) aktiviert lassen, können Sie mit Ihrem Web- Browser auf die Netzwerkmanagement-Karte zugreifen. Dazu müssen Sie in der Grundeinstellung als Benutzername apc und als Kennwort ebenfalls apc eingeben.'
Jojo S. schrieb: > Das mit der seriellen Schnittstelle kommt mir auch bekannt vor, die > wollen ihre Kabel verkaufen. Da ist glaube ich sogar etwas Hardware im > Stecker. Ja, Drähte und Plastik, so verdrahtet das beim Anschließen eines Crossover-Kabels (Nullmodem-Kabel) die USV sich plötzlich abschaltet. Die Verdrahtung findet man z. B. hier: http://serverfault.com/questions/524443/is-apcs-smart-signaling-cable-940-0024-really-proprietary
:
Bearbeitet durch User
Jojo S. schrieb: > aus dem APC Manual: > > 'Sie können den APC Konfigurationsassistenten für Geräte-IPAdressen > auf einem Computer mit dem Betriebssystem > Microsoft® Windows® 2000, Windows 2003 oder Windows > XP verwenden, um unkonfigurierte Netzwerkmanagement- > Karten aufzufinden und deren TCP/IP-Einstellungen > nacheinander über das Netzwerk zu konfigurieren. Ja, aber ich hatte unbekannt konfigurierte NMCs und die lassen sich so nicht finden.
Peter II schrieb: > irgendwie reden wir an einander Vorbei. Ein IP-Gerät was eine IP hat > sendet nicht selber einfach einen ARP aus, wenn es keine Verbindung zu > jemand aufbauen will. Wenn das Gerät also nur eine "Client" ist, dann > sendet es auch keine ARPs wenn es nicht gefragt wird. Glaube auch, dass wir aneinander vorbei reden ;) IP etc. befinden sich im OSI-Layer Modell ziemlich weit oben. Sobald du dein Netzwerkkabel einsteckst (ich rede ausschließlich von Ethernet und Windoof), sendet Windows ein ARP Request. Hatte bisher noch kein Ethernet-fähiges Gerät, dass darauf nicht mit seiner MAC-Adresse geantwortet hat. Das ist meinerseits nur ein Tipp, zum Rausfinden der MAC-Adresse, die laut dem 1. Post gesucht ist. Wenn der nicht replied, glaube ich ja fast, dass das Teil defekt ist.
Frank M. schrieb: > Peter II schrieb: >> irgendwie reden wir an einander Vorbei. Ein IP-Gerät was eine IP hat >> sendet nicht selber einfach einen ARP aus, wenn es keine Verbindung zu >> jemand aufbauen will. Wenn das Gerät also nur eine "Client" ist, dann >> sendet es auch keine ARPs wenn es nicht gefragt wird. >
1 | > s/Client/Server/ |
2 | > |
> > Das Gerät ist wahrscheinlich ein Server, nämlich ein Webserver. Es wird > solange still sein, bis es aufgefordert wird zu reden. Daher wird ARP > allein nicht reichen, um dem Gerät die nötigen Infos zu entlocken. Außer > das Ding telefoniert nach Hause... der webserver ist aber ein ganz anderer layer... bei einschalten des gerätes wird es hoffentlich mal im netzwerk guten tag sagen, und nachschauen, ob die zugewiesene adresse schon vergeben ist... alles andere wäre übler murks
Steven M. schrieb: > der webserver ist aber ein ganz anderer layer... bei einschalten des > gerätes wird es hoffentlich mal im netzwerk guten tag sagen, und > nachschauen, ob die zugewiesene adresse schon vergeben ist... alles > andere wäre übler murks Ok, dann muss ich wohl dirket anschließen, ohne Switch dazwischen, und mit einem Sniffer wie Wireshark alles aufzeichnen.
Steven M. schrieb: > der webserver ist aber ein ganz anderer layer... bei einschalten des > gerätes wird es hoffentlich mal im netzwerk guten tag sagen, und > nachschauen, ob die zugewiesene adresse schon vergeben ist... alles > andere wäre übler murks nein ist es nicht. Die Prüfung macht überhaupt keinen sinn, es kann ja gerade das Netzwerk an irgendeinem Switch unterbrochen sein. Da würde man auch keine Kollision mitbekommen. So etwas ist er mit https://de.wikipedia.org/wiki/Zeroconf eingeführt wurden. Windows sendet wegen seiner Netbios-Altlasten von sich aus, das kann man aber nicht auf andere Geräte übertragen. Ethernet stamm aus einer Zeit, wo man sparsam mit Ressourcen umgegangen ist, so eine "guten Tag" hat man da nicht gemacht. ARPs werden gesendet, wenn man zu einer IP die MAC wissen will.
Peter II schrieb: > Windows sendet wegen seiner Netbios-Altlasten von sich aus, das kann man > aber nicht auf andere Geräte übertragen. Andere Geräte, andere Altlasten. Ich würde auch wetten der sendet zyklisch irgendeinen Murks. Vielleicht LLDP o.ä. Mindestens aber beim einschalten wird was kommen.
Peter II schrieb: > Ethernet stamm aus einer Zeit, wo man sparsam mit Ressourcen umgegangen > ist, so eine "guten Tag" hat man da nicht gemacht. ARPs werden gesendet, > wenn man zu einer IP die MAC wissen will. Laut APC Doku machen die aber genau das was Steven beschreibt, bei statischer Adresse prüfen ob die schon vergeben ist. Das ist also ein ARP den man nach dem Einschalten sehen müsste.
Peter II schrieb: > Steven M. schrieb: >> der webserver ist aber ein ganz anderer layer... bei einschalten des >> gerätes wird es hoffentlich mal im netzwerk guten tag sagen, und >> nachschauen, ob die zugewiesene adresse schon vergeben ist... alles >> andere wäre übler murks > > nein ist es nicht. Die Prüfung macht überhaupt keinen sinn, es kann ja > gerade das Netzwerk an irgendeinem Switch unterbrochen sein. Da würde > man auch keine Kollision mitbekommen. > So etwas ist er mit https://de.wikipedia.org/wiki/Zeroconf eingeführt > wurden. > > Windows sendet wegen seiner Netbios-Altlasten von sich aus, das kann man > aber nicht auf andere Geräte übertragen. > > Ethernet stamm aus einer Zeit, wo man sparsam mit Ressourcen umgegangen > ist, so eine "guten Tag" hat man da nicht gemacht. ARPs werden gesendet, > wenn man zu einer IP die MAC wissen will. zum einen ist zeroconf mal windowskram, und zum anderen kommt es nur zum tragen, wenn da ein DHCP-client auf dem gerät läuft, und dieser keinen DHCP-server erreichen kann... (was im übrigen sowieso schon mal broadcast-pakete erzeugt) ist es aber kein windowsfriendly system, oder mal würgt ihm eine statische konfiguration rein, gibts da einfach kein zeroconf (mit ipv6 evtl... aber andere geschichte) sei es drum... ACP hat keinen grund ihr gerät im netzwerk zu verstecken... das wird sich schon irgendwie bemerkbar machen
Man kann ja auch mal ein IDS ans Netz hängen, einmal ohne die Kiste und einmal mit. Wenn dann neue Adressen und Pakete auftauchen und das wiederholbar ist hat man was man braucht. Ansonsten braucht's halt die erwähnte BruteForce Methode, kann man ja ein Sctipt schreiben und über's WE laufen lassen ;-)
Steven M. schrieb: > zum einen ist zeroconf mal windowskram klar doch: > Dieser Text wurde von Mitarbeitern der Unternehmen Apple, Microsoft und > Sun Microsystems verfasst schon spannend was alles MS zugeschrieben wird.
Steven M. schrieb: > sei es drum... ACP hat keinen grund ihr gerät im netzwerk zu > verstecken... das wird sich schon irgendwie bemerkbar machen Richtig. Es wird das genau dann tun, wenn man ihm die richtige Frage per Broadcast stellt. Die Gemeinheit ist eigentlich nur, dass diese Frage nicht dokumentiert ist... (Der Grund ist natürlich: Profitmaximierung, was denn sonst). Für Leute, die wissen, was sie tun, ist sowas natürlich kein Hindernis: man beobachtet einfach, was die Tools des Herstellers denn so an Broadcasts absondern, wenn sie auf der Suche nach "ihren" Geräten sind. Gearscht sind (wie immer) nur die Doofen...
Als erstes die Geräte genau ansehen. Eventuell auch von innen. Vielleicht steht ja doch irgendwo eine Hardwareadresse drauf. Ansonsten den PC und die USV mittels Ethernet-Crossover-Kabel verbinden - ohne Switch! Ein Hub ist aber erlaubt, da braucht man auch kein Crossover. Dann auf dem PC Wireshark starten und die USV einschalten. Du wirst auf jeden Fall die Datenpakete des PCs sehen. Die kannst Du ignorieren. Dich interessieren erst einmal nur DHCP-Requests und Whois ARP-Anfragen. Kommt ein DHCP-Request, der nicht die MAC des PC beinhaltet, kann es nur die USV sein. Ebenfalls sind ARP-Requests interessant, die ebenfalls nicht vom PC kommen. Vielleicht hast Du ja Glück und die USV macht DHCP (die IP kannst Du dann auch einfach in Deinem Router finden, wenn die USV mit diesem verbunden ist). ARP kommt immer, wenn die USV versucht nach irgendwo zu telefonieren. Es ist ja möglich, dass ein Zeitserver oder DNS konfiguriert ist. Es ist auch möglich, dass die USV versucht, das eingetragene Gateway aufzulösen. Wenn Du die MAC der USV kennst, machst Du einen statischen ARP-Eintrag auf Deinem PC. Die IP muss aus dem Bereich Deines Netzes sein. Danach kannst Du die USV mit dieser IP ansprechen, auch wenn sie tatsächlich eine andere hat. Bringt das ganze nichts. Brauchst Du die Software. Denn die USV wird sich nur auf ein spezielles Broadcast-Paket hin bemerkbar machen.
Christian H. schrieb: > Ansonsten den PC und die USV mittels Ethernet-Crossover-Kabel verbinden > - ohne Switch! Ein Hub ist aber erlaubt, da braucht man auch kein > Crossover. > Dann auf dem PC Wireshark starten und die USV einschalten. > > Du wirst auf jeden Fall die Datenpakete des PCs sehen. Die kannst Du > ignorieren. Dich interessieren erst einmal nur DHCP-Requests und Whois > ARP-Anfragen. und wozu der HUB? DHCP und ARP sind Broadcast, die sieht jeder auch bei einem Switch.
Peter II schrieb: > und wozu der HUB? DHCP und ARP sind Broadcast, die sieht jeder auch bei > einem Switch. Stimmt auffallend. Hatte nebenbei irgendwie an etwas anderes gedacht. Übrigens: All APC devices have a MAC address that begin with 00 C0 B7 which may help while reviewing your DHCP Client List. By default, all of APC's Network Management Card 1 based devices are configured for a boot mode of DHCP/BOOTP. If using DHCP, a vendor cookie (DHCP Option 43) is required by default. If it is not configured on your DHCP server, the card will not accept an IP address. You can use the methods below to configure/access the card if you do not wish to use DHCP/BOOTP.
Christian H. schrieb: > Hatte nebenbei irgendwie an etwas anderes gedacht. Ach ja. Das ist nötig, falls die USV Unicast-Anfragen nach irgendwo stellt. Aber davor wird immer ein ARP kommen.
Gibts etliche Programme oder sogar apps fürs ipad, die wunderbar funktionieren. da brauchts kein terminal. aufmachen, scannen drücken, fertig
Tomas schrieb: > da brauchts kein terminal. aufmachen, scannen drücken, Du musst aber schon den Netzbereich kennen, in dem die USV zu finden ist.
Peter II schrieb: > Ethernet stamm aus einer Zeit, wo man sparsam mit Ressourcen umgegangen > ist, so eine "guten Tag" hat man da nicht gemacht. ARPs werden gesendet, > wenn man zu einer IP die MAC wissen will. Dir ist aber bewusst, dass nicht alle Geräte Broadcast MACs akzeptieren? EDIT: Zumindest nicht durchgehend.
:
Bearbeitet durch User
Reginald L. schrieb: > Dir ist aber bewusst, dass nicht alle Geräte Broadcast MACs akzeptieren? > EDIT: Zumindest nicht durchgehend. was willst du damit sagen?
c-hater schrieb im Beitrag #4480831: > Nein. Es gibt keinen Zwang für irgendein Gerät, Adresskonflikte auf > IP-Ebene (Layer3) aufspüren zu müssen. wer hat das behauptet? Lesen scheint nicht deine Stärke zu sein und Flussdiagrame verstehst du offensichttlich auch nicht. Das Dokument das ich gepostet habe ist aus der original Doku von APC und die machen es so wie genannt.
Etwas missverständlich habe ich mich schon ausgedrückt: Damit meinte ich, dass ohne aufgelöste MAC Adresse die Broadcasts dann einfach verworfen werden.
Jojo S. schrieb: > wer hat das behauptet? Lesen scheint nicht deine Stärke zu sein und > Flussdiagrame verstehst du offensichttlich auch nicht. > Das Dokument das ich gepostet habe ist aus der original Doku von APC und > die machen es so wie genannt. und woran sollten wir das erkennen? Das kann von irgendeinem Gerät sein, was es eventuell so macht.
vielleicht an dem Satz: 'Laut APC Doku machen die aber genau das was Steven beschreibt' ?
Jojo S. schrieb: > vielleicht an dem Satz: 'Laut APC Doku machen die aber genau das was > Steven beschreibt' ? also ob es nur ein APC-Gerät gibt. Im Dokument steht etwas von 2006 - ich kenne APC seit 1999. Keine Ahnung ab wann und bei welchen Geräte sie es so machen.
ich weiß ja nicht woran sich hier einige hochziehen... es ist kein gerät von ´84... mit gerade so laufendem tcp/ip stack es ist eine USP mit netzwerkzugang die wird sich halbwegs vernünftig verhalten, den anderen geräten guten tag sagen, und sie wird sich im netzwerk bemerkbar machen. meine güte....
Steven M. schrieb: > es ist eine USP mit netzwerkzugang > die wird sich halbwegs vernünftig verhalten, den anderen geräten guten > tag sagen, und sie wird sich im netzwerk bemerkbar machen. sich ungebeten zu melden ist kein vernünftiges Verhalten
Dass das Internet relativ gut funktioniert verdankt es u.v.a. der Vielzahl an möglichen Adressen. Solltest Du zufällig die richtige Adresse erwischen, so müsstest Du auch noch wissen, wie die "richtige" Antwort, auf Deine Anfrage, lautet. Sonst kann es sein, dass Du den richtigen fragst, der aber nicht reagiert. In diesem Sinne: Viel Spaß.
Moin, freundliche Netzteilnehmer senden auch mal ein Gratuitous ARP, um sich dem Netz bekannt zu machen. (https://wiki.wireshark.org/Gratuitous_ARP). Ich finde, es gibt genug Vorschläge in Richtung Crossover-Cable (naja, heute wohl eher nicht mehr nötig) und Wireshark. Auf geht's! Gruß Jens (Die APC-Karten haben doch auch noch so nette DIP-Switches, um Default-Zustände herzustellen, Details habe ich verdrängt...)
PC mit NIC im Promicious Mode mit Wireshark/tcpdump hinhängen, dann Gerät anschalten. Irgendwas kommt dabei relativ sicher, denn es gibt viele Dienste die auf einer USV laufen - ntp für Zeit, ggf. SNMP Traps, Updatesuche, Broadcast für Verwaltungssoftware, rsyslog, notfalls nach einem Reset sollte eigentlich immer ein DHCP Request kommen. Wenn man seriell rankommt bekommt man auch relativ leicht Informationen. Handbuch lesen hilft auch, genauso Recherche, manchmal gibt es "versteckte" Befehle/Codes (z.B. Anzeige der IP auf dem Display der USV nach Drücken der Taste X für 10s). Hub ist in diesen Zeiten übrigens etwas angestaubt wenn man doch für wenig Geld einen kleinen Switch mit Port Mirroring bekommt - das sogar Gigabit tauglich - da wird es mit einem Hub doch schon etwas schwer.
Nachdem die Ursprungsfrage inzwischen soweit ausdiskutiert ist noch eine Zusatzfrage: Angenommen ich habe mit Wireshark und Crossconnect die IP Adresse herausgefunden wie komme ich dann an die passende Subnetmask? Also unbekanntes Gerät hat IP 192.168.0.10 und Subnetmask 255.255.255.240(unbekannt) und ich stelle meinen Rechner auf IP 192.168.0.1 und Subnetmask 255.255.255.0 dann habe ich es bis jetz nicht geschafft eine Kommunikation herzustellen. Habe ich mich nur zu doof angestellt oder geht das wirklich nicht? Wenn es nicht geht wie finde ich die Subnetmask dann raus?
was anderes als /24 werden die doch auch nicht gehabt haben... spielt es in dem fall überhaupt eine rolle? portscanner hast du probiert? evtl spricht es nur snmp...?
Moin, ich denke, wenn Du eine unmittelbar benachbarte IP nimmst, kann nicht viel schiefgehen. Die kleinste sinnvolle Netzmaske ist 255.255.255.252. Teile also die letzte Stelle der IP durch 4. Ist der Rest 1, erhöhst Du Deine eigene Adresse um 1, sonst verringerst Du um 1. Deine eigene Netzmaske ist beliebig, solange sie zumindest 255.255.255.252 ist. Hmmm, das oben beschriebene Verfahren habe ich mir gerade ausgedacht, mich würden Kommentare dazu interessieren... Die eingestellte Maske lässt sich dann ggf. durch Versuche herausfinden - fällt Deine eigene raus, könnte die USV versuchen, über das Standard-Gateway zu antworten - dann würdest Du das auch erkennen (an einem ARP-request für die Gateway-Adresse). Aber das ist vermutlich nicht immer so... Gruß Jens
Nochmal kurz zu klarstellung: Ich bin nicht der TO mit der USV aber ich dachte meine Frage passt hier rein. >was anderes als /24 werden die doch auch nicht gehabt haben Ist mir leider schon öfters untergekommen. Hauptsächlich bei kleinen Fillialen oder Home Offices. >spielt es in dem fall überhaupt eine rolle? wie schon geschrieben, mit falscher Subnetmask hat es bei mir bis jetzt nicht funktioniert auch wenn beide IPs im sich eigentlich sehen sollten. >Deine eigene Netzmaske ist beliebig, solange sie zumindest >255.255.255.252 ist. So habe ich auch gedacht, vielleicht hatte ich bis jetzt nicht genug Geduld oder immer einen Fehler gemacht, das nächste mal nehme ich mir mehr Zeit wenn es wieder heisst "Änder mal Parameter XY an dem Gerät von dem wir nichts wissen ausser das es Blau ist" >mich würden Kommentare dazu interessieren... so ähnlich habe ich mir das auch gedacht, einfach eine Nummer höher oder tiefer, mit einer von beiden Adressen muss ich im gleichen Netz sein. Leider ist mir auch schon ein paarmal untergekommen dass das GW nicht die 1. IP im Netz war(wer auch immer sich das einfallen lassen hat) >evtl spricht es nur snmp...? Die Geräte um die es mir geht haben normalerweise eine WEB Oberfläche. Wenn der Ping mal geht dann gibt es nur noch das Problem dass nicht jeder Browser funktioniert wegen irgendwelcher https Zertifikate, aber das ist ein anderes Thema..
:
Bearbeitet durch User
aber mal davon abgesehen... es muss doch eine möglichkeit vorgesehen sein, die einstellungen zurück zu setzen...
Mann ist das ein Text hier... Einfach mal Apc oder deren Handbuch befragen, welche IP-Einstellungen nach einem Werksreset Default sind. Da wird hier ein Drama daraus gemacht.. Viele Grüße! Sven
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.