Hallo Fachleute! Ich schildere hier ein kleines Problem, das ich mit einem RADStudio-XE7-Programm habe. Mit der Komponente TIdTrivialFTP habe ich eine LAN-Kommunikation mit einer Elektronik (ARM-Cortex-Controller und DP83484 PHY) realisiert. Das klappt soweit auch. In das Windows-Programm habe ich auch eine Scan-Funktion eingebaut, die das Gerät, mit dem die Kommunikation laufen soll, im Netzwerk finden soll (IP-Adresse der Elektronik wurde per DHCP vergeben). Dazu klappere ich einfach einen IP-Adressbereich (z.B. 192.168.10.1 bis 192.168.10.254) ab und versuche, eine Datei zu lesen (Aufruf von TIdTrivialFTP->Get()). Das Gerät ist gefunden (= IP-Adresse ermittelt), wenn das Lesen der Datei geklappt hat. Dieses scannen läuft auf manchen PC's (vornehmlich mit Windows XP, aber auch Windows 7/64) sehr flott, d.h. der Get()-Aufruf kehrt schnell zurück, auch wenn es die IP-Adresse oder Datei nicht gibt. Der gesamte Scan-Vorgang ist innerhalb weniger Sekunden abgeschlossen! Auf anderen PC's (bisher nur auf Windows 7/64-Systemen festgestellt) dauert es extrem lange (ca. 2 Sekunden), bis Get() zurück kehrt. Der gesamte Scan-Vorgang benötigt also mehrere Minuten! Nun die Frage: Woran könnte es liegen, dass "Get()" bei manchen PC's sehr lange braucht und auf anderen PC's schnell zurück kehrt, wenn es die Datei nicht gibt? Ich vermute, dass hier irgend eine Timeout-Einstellung im Spiel ist, aber wo kann ich da was einstellen? Registry? Hat jemand eine Idee? Für Eure Lösungsvorschläge schon mal Danke!
Das kommt wahrscheinlich drauf an ob er den TCP Handshake schafft oder nicht, sprich, wie die Firewall auf die Verbindungsaufnahme reagiert. Schickt also die Kiste "nach Spezifikation" ein Reset auf einen Sync, kommt er natürlich fix mit einem "der läßt mich nicht rein" zurück. Weil er ja Antwort bekommen hat. Läuft auf der Kiste eine Firewall die stillschweigend einfach alles unter den Tisch kippt (um einem potentiellen Angreifer nicht mal zu sagen dass da wer da ist), dann wartet der natürlich bis zum Timeout. Kann ja nicht wissen wie weit der andere Rechner da entfernt ist und wie lang das dauern soll/kann. Da jeder, der auch nur für 10 cents Verstand in die Konfiguration seiner Netzwerkverbindungen investiert (~5% der Internetnutzer, optimistische Schätzung) die Firewall für Version 2 konfiguriert hat, solltest Du Dir 'n Weg suchen das timeout runterzusetzen. Sonst wartest Dir 'n Wolf.
Hallo Heinz! Danke für Deine Antwort. Die Firewall ist gerade bei Trivial-FTP ein großer Stolperstein, das trifft hier jedoch nicht zu! Das Problem besteht auch bei abgeschalteter Firewall! Das Problem ist ja nicht, dass keine Verbindung zustande kommt. Das Problem ist, dass TIdTrivialFTP->Get() auf manchen PCs viel Zeit vertrödelt, wenn KEINE Verbindung zustande kommt!
grusel Danke, damit hat sich das mit dem Schlafen heute Nacht auch erledigt. Wie das funktionieren soll will ich nicht mal so genau wissen. Unterm Strich dürfte die Antwort die gleiche bleiben: Ohne Antwort wartet er aufs Timeout.
Rainer Reusch schrieb: > Dazu klappere > ich einfach einen IP-Adressbereich (z.B. 192.168.10.1 bis > 192.168.10.254) ab und versuche, eine Datei zu lesen (Aufruf von > TIdTrivialFTP->Get()). Das Gerät ist gefunden (= IP-Adresse ermittelt), > wenn das Lesen der Datei geklappt hat. finde ich ein ziemliche Unart. Du geht doch auch nicht an jede Haustür und schaust wo dein Schlüssel passt. sende eine Broadcast an die Broadcastadresse und dein Controller antwortet. Schon hast du die IP.
@Peter II: Na ja, wenn es nicht zu viele Haustüren sind (lokales Netzwerk), kann man das schon machen, denke ich. Und wenn es auf jedem PC so flott funktionieren würde, wie auf meinem Entwicklungs-PC, wäre diese Lösung nicht schlecht und einfach umsetzbar. Aber Danke für den Hinweis mit dem Broadcast! Ich muss jetzt mal schauen, wie sowas mit dem RADStudio zu realisieren ist und ich muss auch schauen, ob mein Gerät das unterstützt. Ich verwende den lwIP-Stack für Cortex-M (STM32F407). Da funktioniert schon mal ein Ping, ohne dass ich in meiner Firmware was machen musste. Gibt es ein fertiges Windows-Progrämmchen (zum testen), mit dem sich Broadcast absetzen lassen? Manche habe es vielleicht schon gemerkt: Ganz so sattelfest bin ich bei diesen spezielleren LAN-Geschichten nicht gerade.
Rainer Reusch schrieb: > Gibt es ein fertiges Windows-Progrämmchen (zum testen), mit dem sich > Broadcast absetzen lassen? kann jedes Programm was auch UDP senden kann, einfach als Zieladresse 255.255.255.255 eingeben.
Peter II schrieb: > sende eine Broadcast an die Broadcastadresse und dein Controller > antwortet Naja, das ist kaum sauberer. Sauberer wäre es, sich Gedanken zu machen, wie man das ohne trial&error implementiert. Beispielsweise könnte „die Elektronik“ einen eigenen Hostnamen im DHCP mitliefern, und der DHCP-Server trägt diesen in einen bestimmten (lokalen) DNS-Namensraum ein. Fritzboxen erledigen sowas beispielsweise standardmäßig (in den Pseudo-Namensraum “.fritz.box”). Der Client ermittelt dann die IP-Adresse über diesen Namen und baut die Verbindung genau dahin auf. Noch sauberer wäre es, wenn man eine Zeroconf-Technik benutzt (bspw. Bonjour/mDNS/DNS-SD), um solche Dienste im Netzwerk zu verkünden.
:
Bearbeitet durch Moderator
Jörg Wunsch schrieb: > Noch sauberer wäre es, wenn man eine Zeroconf-Technik benutzt > (bspw. Bonjour/mDNS/DNS-SD), um solche Dienste im Netzwerk zu > verkünden. und was soll daran anders sein als, die Broadcast Lösung? Bonjour/mDNS basiert auch nur auf Multicast. Dazu noch der Overhead für das offizielle Protokoll. Dann braucht man unter Windows (wie vermutlich auch unter Linux) auch noch Dienste/Pakete damit es funktioniert. Das sehe ich mehr Nachteile als Vorteile.
Peter II schrieb: > und was soll daran anders sein als, die Broadcast Lösung? Dass du nicht einfach auf der Portnummer des Dienstes selbst herum-broadcastest. Das ist doch in keiner Weise besser oder sauberer, als alle IP-Adressen einzeln abzufragen, ob sie den Dienst vielleicht zufällig anbieten. > Bonjour/mDNS basiert auch nur auf Multicast Multicast ist aber erstens was anderes als Broadcast: Broadcast ist Spam, Multicast ist „ich trage mich bei diesem Anbieter für die Zusendung der Werbung ein“. Außerdem ist es ein separater Dienst, der rein für die Organisation des Netzwerkes zuständig ist, statt dass man per Bruteforce versucht, die Zieldienste alle rumzuprobieren.
Man könnte auch dem DHCP Server beibringen, dass das Gerät mit der MAC xyz immer dieselbe IP bekommt. Diese IP wird auf dem Windows Programm einmalig eingestellt (oder meinetwegen auch durch scannen ermittelt), gemerkt (Registry?) und das Windows Programm probiert diese IP dann vor allen anderen um seine Daten loszuwerden. Kann es auf dieser IP das Gerät nicht mehr erreichen, kann es ja wieder einen Scan anleiern, sollte aber (wegen der DHCP Fixierung) nicht notwendig sein. Dann hat man die 'Einrichtungskosten' bei nach wie vor voller FLexibilität nur einmalig, was normalerweise kein Problem darstellt.
Dann kannste „der Elektronik“ aber auch genausogut gleich eine feste IP-Adresse eintragen. ;-)
Jörg Wunsch schrieb: > Dann kannste „der Elektronik“ aber auch genausogut gleich eine feste > IP-Adresse eintragen. ;-) Auch wieder wahr.
Jörg Wunsch schrieb: >> und was soll daran anders sein als, die Broadcast Lösung? > > Dass du nicht einfach auf der Portnummer des Dienstes selbst > herum-broadcastest. Das ist doch in keiner Weise besser oder > sauberer, als alle IP-Adressen einzeln abzufragen, ob sie den > Dienst vielleicht zufällig anbieten. doch ist es, weil es extra dafür da ist. > Bonjour/mDNS basiert auch nur auf Multicast > Multicast ist aber erstens was anderes als Broadcast: Broadcast ist > Spam, Multicast ist „ich trage mich bei diesem Anbieter für die > Zusendung der Werbung ein“. Außerdem ist es ein separater Dienst, > der rein für die Organisation des Netzwerkes zuständig ist, statt > dass man per Bruteforce versucht, die Zieldienste alle rumzuprobieren. wenn ich das richtig verstanden habe, dann schicken diese Geräte auch an das gesamte Netzwerk eine Broadcast. Nur das diese vom Gerät ausgeht und nicht vom PC. Damit hat man sogar mehr Trafik, weil es ständig gemacht wird und nicht nur wenn es gebraucht wird. Schon das Punkt das man es extra installieren muss spricht doch schon dagegen. Warum sollte ich mir Apple Software auf den Windows PC installieren nur um ein gerät einzurichten?
Peter II schrieb: > wenn ich das richtig verstanden habe, dann schicken diese Geräte auch an > das gesamte Netzwerk eine Broadcast. Nochmal: eine Multicast-Message ist keine Broadcast. Für eine Multicast trägst du dich explizit ein, und ordentliche Switches leiten die Pakete auch nur an die Teilnehmer weiter, die teilnehmen wollen. > Damit hat man sogar mehr Trafik, weil es ständig gemacht > wird und nicht nur wenn es gebraucht wird. Mein Argument war ja, dass deine Broadcast erstmal nicht irgendwie eleganter oder weniger „Holzhammer“ ist, als an jeder Türklinke klinken zu gehen. Was ist denn, wenn mehr als einer dann antwortet? Und was, wenn der erste, der antwortet, gar nicht der ist, den du haben wolltest (das trifft natürlich genauso gut auf die Methode des TE selbst zu)? Richtig Sinn hat so ein Zeroconf-System natürlich nur, wenn man es generell nutzt, das ist richtig. Andererseits sollte man in einem ordentlichen Netz auch eine ordentliche Administration haben, dann braucht man auch kein Zeroconf, sondern beantragt einen Hostnamen und die zugehörige IP-Adresse von seinem Netzwerk-Admin. Inwiefern man dann trotzdem noch DHCP macht (damit man die Konfiguration nicht im Gerät speichern muss) oder nicht, ist dann eher ein Absprache-Detail. Zeroconf ist ja nur für Netze da, die eben keine explizite Administration haben. > Schon das Punkt das man es extra installieren muss spricht doch schon > dagegen. Warum sollte ich mir Apple Software auf den Windows PC > installieren Weil Windows nichts vergleichbares anbietet? Wobei ich mir da nichtmal so sicher bin, kann sein, dass Windows auch irgendein Zeroconf mit dabei hat.
Grrr! Und ich dachte, Geräte die darauf angewiesen sind, sich in der selben Broadcast Domain zu befinden wie ihr Partner im Netz, gehören endlich mal der Vergangenheit an! Zeroconf und co. dagegen haben die Möglichkeit, auch über link local hinaus auffindbar zu sein. Und wenn das zu viel ist, wenigstens nen einfachen Multicast (mit TTL > 1!) dann hat der Admin auch eine Chance, das Gerät ohne Gekrampfe in die Netzstruktur zu integrieren. EDIT: oops, einige Beiträge während meiner Schreinerei dazugekommen...dennoch sollte das Obige einen weiteren Grund außer Broadcastspamvermeidung liefern: bitte mach das routebar. Danke.
:
Bearbeitet durch User
Schön, dass sich hier so eine Diskussion entwickelt hat -- auch wenn die eigentliche Frage (warum TIdTrivialFTP->GetID auf manchen Rechnern viel Zeit braucht, wenn es den Kommunikationspartner nicht gibt) noch garnicht beantwortet wurde. Meine Elektronik, um die es hier eigentlich geht, soll in der Grundeinstellung "DHCP" ausgeliefert werden. Der Kunde selbst soll dann über einen Konfigurationsdialog im Windows-Programm eine feste IP-Adresse festlegen können. Da das Gerät keine visuelle Ausgabe hat, soll dem Anwender ein für ihn praktikables Mittel in die Hand gegeben werden (nämlich sowas wie eine Scan- oder "automatisch finden"-Funktion), weil er die IP-Adresse zunächst ja nicht kennt. Diese Lösung hat den Vorteil, dass ich als Lieferant des Geräts die Infrastruktur des Kunden nicht zu kennen brauche und er selbst auch nur zu einem gewissen Grad. Bei den Lösungsvorschlägen sollte man im Hinterkopf behalten, dass auf der Elektronik-Seite lediglich ein Cortex-M4-Controller sitzt, der kein Betriebssystem, sondern lediglich eine anwendungsspezifische (und echtzeittaugliche) Firmware besitzt. Die Implementierung komplexerer Lösungen, wie man sie von Windows- und Linux-Systemen kennt, dürfte daher nicht so einfach sein!
Naja, manchmal wäre es hilfreich, die Infos am Anfang alle mitzuliefern. Hat das Gerät denn irgendeine Form von Interaktionsmöglichkeit, beispielsweise einen Knopf? Dann könnte man eine Art „Button-Konfiguration“ realisieren: man startet eine spezielle Anwendung auf dem PC, die auf einem bestimmten Port hört. Auf Knopfdruck am Gerät sendet dieses ein Paket, das die PC-Applikation empfängt. Damit kennt sie nunmehr die Adresse des Geräts und kann von da beginnend weiterarbeiten. Malte S. schrieb: > bitte mach das routebar. Was allemal dafür spricht: wie ist es, wenn das Gerät beispielsweise an einem Ethernet hängt, der PC aber an einem WiFi? Schon da kann es in vielen Umgebungen erforderlich sein, dass das entsprechende Paket routebar ist.
Hi Rainer, ich hab früher gerne mit den Indy Komponenten gearbeitet, das waren aber noch zu VC++ 6 Zeiten.(schon laaange heeerrrr, Indy V8 - V9) Hast du einen Link zur aktuelle Doku der Indy Komponenten??? (Version?) Bei mir hatte ich damals die Events der Komponenten abgefragt, um den Status der Komponenten zu erfahren. (OnStatus) Auch die Events OnWork, OnWorkBegin und OnWorkEnd usw. können beim Entwickeln hilfreich sein. Das drunter liegende 'TIdUDPClient.ReceiveTimeout' hast schon geprüft?!? Wie steht der Globale Timeout im Stack?(gabs früher eine Variable) Bei mir gabs noch eine Funktion: function ReceiveString(var VPeerIP: string; var VPeerPort: integer; const AMSec: Integer = IdTimeoutDefault): string; overload; Damit konnte man den Timeout für eine Verbindung kontrollieren. Die MAC-Adresse steht auf deinem Gerät? Was ist mit Reverse ARP? Ist recht schnell selbst zu implementieren.
Stephan schrieb: > Was ist mit Reverse ARP? Dann pfuschst du aber dem Netzwerkadministrator im Geschäft herum.
Jörg Wunsch schrieb: > Für eine Multicast trägst du dich explizit ein, und ordentliche > Switches leiten die Pakete auch nur an die Teilnehmer weiter, die > teilnehmen wollen. was wohl leider auf einen Großteil der Switchs nicht zutrifft und damit ist es doch wieder identisch zu Broadcast. > Mein Argument war ja, dass deine Broadcast erstmal nicht irgendwie > eleganter oder weniger „Holzhammer“ ist, als an jeder Türklinke > klinken zu gehen. Was ist denn, wenn mehr als einer dann antwortet? > Und was, wenn der erste, der antwortet, gar nicht der ist, den du > haben wolltest (das trifft natürlich genauso gut auf die Methode > des TE selbst zu)? dann kommen mehre Pakete an und er kann eine Auswahl der Geräte anzeigen - ist doch sogar sinnvoll.
Peter II schrieb: > damit ist es doch wieder identisch zu Broadcast. Bis auf die schon genannte fehlende routeability einer Broadcast. Außerdem geht's ja hier offenbar nicht vorrangig um Heimnetzwerke mit popeligen 3-Euro-fuffzig-Switches, sondern um Firmennetze mit einer ordentlichen Implementierung (zumindest habe ich das so verstanden). Die sollten auch alle sauberes Multicast beherrschen, gibt's ja nicht erst seit vorgestern.
Jörg Wunsch schrieb: > Peter II schrieb: >> damit ist es doch wieder identisch zu Broadcast. > > Bis auf die schon genannte fehlende routeability einer Broadcast. was bei Bonjour auch nicht selbstverständlich ist und Probleme macht http://www.grouplogic.com/Knowledge/PDFUpload/Info/WanBonjour_1.pdf http://www.heise.de/ix/meldung/Apple-hat-Aerger-mit-Uni-Administratoren-1746990.html
Peter II schrieb: > was bei Bonjour auch nicht selbstverständlich ist und Probleme macht Dass Bonjour kein Thema ist, war ja klar, seitdem der TE seine eigentliche Aufgabe mal genauer beschrieben hat.
Warum beim Abklappern warten, und dann erst die Adresse nächste testen? Warum nicht alles gleichzeitig? Einfach 254 Threads erzeugen die jeweils eine Adresse testen. Das sollte auf PCs einigemaßen schnell laufen. Kurzfristig ist dann mal viel Netzwerkverkehr da, aber das sollte auch kein Problem sein.
PittyJ schrieb: > Das sollte auf PCs einigemaßen schnell laufen. > Kurzfristig ist dann mal viel Netzwerkverkehr da, aber das sollte auch > kein Problem sein. könnte sein das Windows da nicht "will". Es gibt ein paar Schutzmaßnahmen gegen vieren die bei TCP zu viele halboffene Verbindungen verhindert, kann mir vorstellen das es auch bei UDP einschreitet. Und wer sagt das ein netzt nur eine 24 Netzwerkmaske hat und keine 16er.
@ Jörg Wunsch Na ja, dass es sich um einen ARM-Cortex handelt, hatte ich schon erwähnt. Und zuviel (unnötige) Information lenkt die Diskussion in eine Richtung, die ich eigentlich nicht haben will. Ein gutes Beispiel ist dieser Thread (nichts für Ungut) @ Stephan Eine, wenn auch dürftige Doku zu den Indy-Komponenten ist beim RADStudio dabei. Ich denke, dass Events und Statusabfragen hier nicht weiter helfen. "Get" lässt sich einfach zu viel Zeit -- auf manchen Systemen. Die Eigenschaft ReceiveTimeout ist in der Tat wichtig. Beim Wert Null geht schlichtweg nichts. Selbst bei einem zu kleinen Wert besteht das Risiko, dass sich der lwIP-Stack im Controller aufhängt. Auf das hier erwähnte Problem hat diese Eigenschaft jedoch keinen Einfluss (leider). @PittyJ > Warum beim Abklappern warten, und dann erst die Adresse nächste testen? Diese Idee ist eigentlich auch nicht so dumm! In einem Klasse-C-Netz wären das 254 Threads. Das wäre sogar noch machbar. Und hier noch meine eigene Idee: Der Broadcast-Vorschlag von Peter II hat mich darauf gebracht und ich habe das gestern Abend mal kurz probiert. Mein Gerät hat (beispielsweise) irgend eine Adresse zwischen 192.168.10.1 und 192.168.10.254. Ich versuche, eine Datei zu lesen und verwende dabei die Adresse 192.168.10.255! Das scheint zu funktionieren! Ich frage auf diesem Weg einfach eine Datei ab (die ich im Controller definiert habe), die mir die richtige IP-Adresse liefert (der Controller kennt sie ja). Die Frage an euch: Kann man davon ausgehen, dass das immer funktioniert? Noch eine Anmerkung zur Firewall (speziell Windows 7 und höher) Es ist mir bis jetzt noch nicht gelungen, eine funktionierende allgemeine Regel für das hier verwendete Trivial-FTP zu erstellen. Was hingegen tadellos funktioniert: Der Firewall explizit das Programm nennen, das diese LAN-Kommunikation benötigt.
Rainer Reusch schrieb: > Ich versuche, eine Datei zu lesen und verwende dabei die > Adresse 192.168.10.255! Das scheint zu funktionieren! naja, das halte ich nun wirklich für murks. Was macht dein Programm, wenn mehre deiner Geräte aktiv sind?
Rainer Reusch schrieb: > In einem Klasse-C-Netz wären das 254 Threads. Das wäre sogar noch machbar. Umm... Klasse C? Wie war das nochmal mit CIDR? Deine Software sollte auf allerhand Präfixe ungleich /24 gefasst sein und entsprechend IPs ableiten können. Was machst du bei /16? 65534 Threads? Bist du auf /22 oder /26 vorbereitet? Rainer Reusch schrieb: > Es ist mir bis jetzt noch nicht gelungen, eine funktionierende > allgemeine Regel für das hier verwendete Trivial-FTP zu erstellen. Was > hingegen tadellos funktioniert: Der Firewall explizit das Programm > nennen, das diese LAN-Kommunikation benötigt. Weil TFTP in Hinsicht auf seine verwendeten Ports nicht ganz so trivial ist wie der Name suggerieren mag :) Der Server antwortet nicht VON Port 69.
Rainer Reusch schrieb: > Eine, wenn auch dürftige Doku zu den Indy-Komponenten ist beim RADStudio > dabei. Ich hab leider kein RadStudio. Früher hatten die noch eine eigene HP. > Ich denke, dass Events und Statusabfragen hier nicht weiter helfen. > "Get" lässt sich einfach zu viel Zeit -- auf manchen Systemen. Die sollen dir helfen den 'Fehler'- Zustand weiter einzukreisen. Finde doch mal raus wo die Funktion hängen bleibt. Wenn die Get-Funktion schon bei der ARP Auflösung auf manchen PCs nicht richtig arbeitet, oder das Binding(siehe Indy) nicht richtig läuft, kann man besser das Problem angehen. Vielleicht kann dir das noch helfen:
1 | TIdLogDebug is an implementation of the ancestor class TIdLogBase, and |
2 | extends the framework for logging information about Indy communication |
3 | components. |
> Die Eigenschaft ReceiveTimeout ist in der Tat wichtig. Achtung es gibt noch globale Timeouts > Beim Wert Null geht schlichtweg nichts. > Selbst bei einem zu kleinen Wert besteht das > Risiko, dass sich der lwIP-Stack im Controller aufhängt. Also mit UDP-Paketen musst du deinen Controller zuschmeißen können, der darf dabei nicht abstürzen!!!! Selbst wenn deine Buffer voll sind, macht das nichts, dann verlierst du zwar Telegramme aber es darf zu keinen Absturz kommen!!!!!
@ Peter II > naja, das halte ich nun wirklich für murks. > Was macht dein Programm, wenn mehre deiner Geräte aktiv sind? Ja, sauber ist diese Lösung nicht! Aber in meinem Anwendungsfall garnicht mal schlecht. Die zu erwartende Antwort passt locker in ein einzelnes IP-Paket. Wenn mehrere Geräte im Netzwerk vorhanden sind, werden natürlich alle antworten. Nur die erste eintreffende Antwort wird verarbeitet. Das kann natürlich die Antwort eines Gerätes sein, das garnicht gesucht wird. Antworten werden allerdings nur "meine" Geräte, denn das Protokoll ist TFTP und abgefragt wird eine bestimmte Datei. Lösung des Problems: Bei der Inbetriebnahme darf eben nur eines meiner Geräte am Netzwerk hängen! Und genau um die Inbetriebnahme geht es! Das Gerät soll mit der Grundeinstellung "DHCP" ausgeliefert werden. Der Endanwender selbst soll dann eine fixe IP-Adresse eintragen. Damit er das kann, muss er zuerst mal über die per DHCP vergebene Adresse auf das Gerät zugreifen. Um die heraus zu finden, findet der Anwender einen Dialog mit einem Button im PC-Programm, der ihm beim Draufklicken die gesuchte Adresse liefert. @ Malte S. > Weil TFTP in Hinsicht auf seine verwendeten Ports nicht ganz so trivial > ist wie der Name suggerieren mag :) Der Server antwortet nicht VON Port > 69. Das ist richtig! Mehr zu TFTP verrät z.B. die folgende Wikipedia-Seite: http://de.wikipedia.org/wiki/Trivial_File_Transfer_Protocol Aber auch wenn ich die darin aufgeführten Ports in die Regel mit aufnehme, klappt es nicht. Man müsste wohl mit einem Sniffer analysieren, welche Ports tatsächlich genutzt werden. @ Stephan > Achtung es gibt noch globale Timeouts Nach genau solchen Stellschrauben habe ich eigentlich gefragt, als ich diesen Thread aufgemacht habe.
Rainer Reusch schrieb: > Antworten werden allerdings nur "meine" Geräte, denn das Protokoll ist > TFTP und abgefragt wird eine bestimmte Datei. Wenn der Entwickler deines Nachbargeräts mit ähnlichen Krücken arbeitet wie du, wie kommst du dann zu so einer Aussage? Er könnte es sich ja („ich habe hier zu wenig Resourcen, das richtig zu machen“) auch gleich mal noch leichter machen und den Dateinamen im TFTP Request gleich komplett ignorieren …
Hallo Jörg! Diese Aussage verstehe ich jetzt nicht ganz. Das PC-Programm "lädt eine Datei" von meinem Gerät -- also eine ganz bestimmte. Wenn man so will, kennt nur mein PC-Programm den Namen dieser Datei (mein einfacher TFTP-Server im Controller beherrscht nicht mal die Abfrage eines Verzeichnisses!). Wie soll da jetzt der Dateiname ignoriert werden? Ein Problem gibt es meiner Ansicht also nur, wenn zwei oder mehr "meiner" Geräte im Netz hängen. Sollte ein anderer Entwickler auch diesen Trick mit der Adresse xxx.xxx.xxx.255 verwenden, wäre das nicht problematisch. Selbst wenn er auch auf TFTP setzt (Port 69 usw.), müsste er genau diese spezielle Datei abfragen, um einen Konflikt zu provozieren. Das ist wohl sehr unwahrscheinlich!
Rainer Reusch schrieb: > Ein Problem gibt es meiner Ansicht also nur, wenn zwei oder mehr > "meiner" Geräte im Netz hängen. Sollte ein anderer Entwickler auch > diesen Trick mit der Adresse xxx.xxx.xxx.255 verwenden, wäre das nicht > problematisch. Selbst wenn er auch auf TFTP setzt (Port 69 usw.), müsste > er genau diese spezielle Datei abfragen, um einen Konflikt zu > provozieren. Das ist wohl sehr unwahrscheinlich! ich finde so ein Tool generell für Geräte Sinnvoll, damit kann man sich auch alle Geräte im Netz anzeigen lassen und ihre aktuelle IP. Warum sollte man das Tool nur verwenden um das Gerät einzurichten. Was ist wenn man die IP vergessen hat oder nicht mehr weiß welchen Gerät welche IP hatte? Wenn man das Tool startet, sollte alles Geräte angezeigt werden. Und dann kann man auswählen welches Gerät man Konfigurieren will. Diese Möglichkeiten verbaust du dir komplett, wenn du nur dein einfaches Verfahren umsetzt.
Rainer Reusch schrieb: > Wie soll da jetzt der Dateiname ignoriert werden? Die Auswertung des Dateinamens obliegt dem Server, also besagtem Gerät. Wenn nun jemand anders ein ähnlich einfach gestricktes Gerät ins Netz stellt, zufällig dabei auch deine Idee von TFTP verfolgt, aber den Dateinamen ignoriert, dann wird er dir trotzdem antworten – du hast dann aber den falschen gefunden.
Rainer Reusch schrieb: > Wenn man so will, > kennt nur mein PC-Programm den Namen dieser Datei (mein einfacher > TFTP-Server im Controller beherrscht nicht mal die Abfrage eines > Verzeichnisses!). Wie soll da jetzt der Dateiname ignoriert werden? Und jetzt kommt ein anderer Hersteller daher und hat die (fast) gleiche Idee, möchte es aber noch simpler, verzichtet auf die Abfrage des Dateinamens und schon stören sich eure Geräte. Dann ist zwar der andere den entscheidenden Schritt zu weit gegangen, ändert aber nichts daran, dass du TFTP für einen Mechanismus missbrauchst, für den es nicht vorgesehen ist. Davon abgesehen, wenn schon die Minimal-Lösung, warum implementierst du überhaupt TFTP? Du kannst auch einen Broadcast an einen bestimmten (nicht offiziell zugewiesenen!) UDP-Port senden mit einem bestimmten Paketinhalt und dann antworten deine Geräte mit was auch immer. Schon die Absenderadresse des Pakets klärt das PC-Programm über die IP des Geräts auf. Ist dann anfällig für Spoofing, aber ich glaube kaum, dass dein jetziges System da besser dasteht. Peter II schrieb: > Diese Möglichkeiten verbaust du dir komplett, wenn du nur dein einfaches > Verfahren umsetzt. Sowie für den Admin, diese Auflistung auch im Betrieb über Subnetzgrenzen hinweg zu bekommen oder das irgendwo eingebaute Gerät (gut, wir wissen nicht, was es ist und ob es theoretisch vor Ort mehr oder weniger fest eingebaut sein wird) aus welchem Grund auch immer auf Werkseinstellungen zurückzusetzen und dann trotzdem vom Büro aus zu rekonfigurieren, weil es trotzdem sauber auffindbar ist, trotz Netzgrenzen. Zugegeben, z.B. Zeroconf hat seine eigenen Probleme und ist nicht zwangläufig das Mittel der Wahl. Aber wenigstens Multicast zu verwenden wäre ein guter Schritt. Wir hatten es mal mit Seriell-Servern zu tun, die gelegentlich gesponnen haben. War immer ein Krampf, die Dinger wieder ansprechbar zu kriegen, weil ihre Einbausituation nicht ohne Weiteres einen Link-lokalen Zugriff vom Admin-PC zugelassen hat, den das Konfigurationtool aber erstmal haben wollte. Es gibt leider schon genug "Plug and play" Geräte, die regelmäßig unterstellen, dass überall simple /24er Netze vorliegen und sonst scheitern und/oder stören.
@ Jörg Nun, ich denke, es macht keinen Sinn, einen TFTP-Server zu entwickeln, der auch bei Dateien, die nicht existieren, etwas liefert. Selbst wenn es das gäbe, was würde im schlimmsten Fall passieren? Im Dialog meines Anwenderprogrammes stünde eine unsinnige IP-Adresse! Ok, der völlig unbedarfte Anwender wird die "Hotline" anrufen. @ Peter II Im Grunde hast Du natürlich recht. Ideal wäre es, wenn alle gefundenen Geräte aufgelistet werden und der Anwender wählt das gewünschte aus. Da wären wir wieder bei meiner ursprünglichen "Scan-Lösung"!!! (mit dem häßlichen kleinen Zeitproblem) Noch eine allgemeine Bemerkung zu dieser Thematik Die von mir nun angestrebte Lösung halte ich inzwischen für sehr praktikabel (alle heute durchgeführten Tests verliefen positiv). Die gemachten Einwände und Bedenken sind zwar berechtigt, man muss aber auch in Erwägung ziehen, wie groß die Wahrscheinlichkeit ist, dass andere Geräte (von anderen Entwicklern) im gleichen Netz hängen, die einem bei diesem Konzept in die Suppe spucken könnten. Ok, die Idee ist dank dieses Forums nun publik, ich gehe trotzdem nicht davon aus, dass die Welt jetzt mit Geräten überflutet wird, die mit dem gleichen Trick arbeiten.
Rainer Reusch schrieb: > Im Grunde hast Du natürlich recht. Ideal wäre es, wenn alle gefundenen > Geräte aufgelistet werden und der Anwender wählt das gewünschte aus. Da > wären wir wieder bei meiner ursprünglichen "Scan-Lösung"!!! (mit dem > häßlichen kleinen Zeitproblem) nein, das geht auch schnell mit der Broadcast Lösung (auch wenn nur auf das Subnetzt begrenzt, bzw. Man muss das netz angeben) -> Broadcast schicken -> 1 sekunde lang die Antworten einsammeln -> anzeigen.
Rainer Reusch schrieb: > Nun, ich denke, es macht keinen Sinn, einen TFTP-Server zu entwickeln, > der auch bei Dateien, die nicht existieren, etwas liefert. Aus seiner Sicht existiert bestimmt eine Datei, er hat sich nur nicht die Mühe gemacht, deren Namen erst zu überprüfen, sondern liefert dir einfach das, was er für richtig hält. Aber du bist ja ohnehin nicht davon abzubringen, dass deine Methode die beste der Welt sei, was auch immer dir an Einwänden entgegnet wird und für wie krückig auch immer andere deine Idee halten. Dann mach einfach.
Rainer Reusch schrieb: > Die von mir nun angestrebte Lösung halte ich inzwischen für sehr > praktikabel (alle heute durchgeführten Tests verliefen positiv). Leider ist es in der Regel unmöglich in komplexen Systemen/Szenarien allein aufgrund der Bereichsgröße ALLE Werte zu prüfen > Die gemachten Einwände und Bedenken sind zwar berechtigt, man muss > aber auch in Erwägung ziehen, wie groß die Wahrscheinlichkeit ist Es reicht wenn EIN Server/Dienst die Grätsche macht oder hängt weil irgendwer ihn mit Scan-Paketen bombardiert und schon ist der Kunde (zu recht) sauer. > Ok, die Idee ist dank dieses Forums nun publik, ich gehe trotzdem nicht > davon aus, dass die Welt jetzt mit Geräten überflutet wird, die mit dem > gleichen Trick arbeiten. Der "Trick" ist einfach Mist (und ich darf mich leider ständig mit solchen "Trickreichen" Geräten rumärgern), spätestens wenn irgendwo ein Router oder VPN oder Firewalls oder ... zwischenhängt geht das doch schief, bei DHCP kann man doch einfach anhand der MAC (die man auf das Gehäuse druckt) feststellen welche IP das Gerät erhalten hat. Jörg Wunsch schrieb: > einen eigenen Hostnamen im DHCP mitliefern Bei einigen Geräten wird da einfach die MAC (oder ein Teil davon) genutzt, die sollte ja immer bekannt sein, ist einmalig und funktioniert dan auch mit mehreren gleichartigen Geräten im Netz.
Läubi .. schrieb: > Bei einigen Geräten wird da einfach die MAC (oder ein Teil davon) > genutzt, die sollte ja immer bekannt sein, ist einmalig und funktioniert > dan auch mit mehreren gleichartigen Geräten im Netz. Da fällt mir noch ein: wenn man die MAC-Adresse kennt und sich innerhalb der broadcast domain befindet, dann kann man natürlich auch das ganze Netz mit ARP probes (für jede Adresse einzeln) abklappern, bis man die gewünschte MAC-Adresse gefunden hat. Das ist auf jeden Fall verhältnismäßig wenig “intrusive”.
Jörg Wunsch schrieb: > wenn man die MAC-Adresse kennt und sich > innerhalb der broadcast domain befindet, dann kann man natürlich > auch das ganze Netz mit ARP probes (für jede Adresse einzeln) > abklappern Oder gleich per Unicast auf Layer 2 mit dem Ding kommunizieren und sei es nur, um die IP mitgeteilt zu bekommen. Allemal sauberer als irgendwelche Scan-Aktionen, die direkt das IDS auf den Plan rufen. Es soll auch Switche geben, die bei Broadcast-Spielereien schnell mal einen Port stilllegen, bis der Admin eingreift - und das verursachende Gerät oder Programm aus dem Netz verbannt ;-)
Malte S. schrieb: > Oder gleich per Unicast auf Layer 2 mit dem Ding kommunizieren und sei > es nur, um die IP mitgeteilt zu bekommen. und wie? Soll der Nutzer manuell die MAC eintragen? > Es > soll auch Switche geben, die bei Broadcast-Spielereien schnell mal einen > Port stilllegen, bis der Admin eingreift - und das verursachende Gerät > oder Programm aus dem Netz verbannt ;-) er soll ja nicht DoS machen sondern einen "Rundruf". Wenn der Port dann schon dicht gemacht wird, würde ja nicht mal dhcp funktionieren.
Peter II schrieb: > und wie? Soll der Nutzer manuell die MAC eintragen? Darum ging es doch, dass die ja bekannt ist und sich die IP daraus ermitteln lässt. Am DHCP-Server oder eben auf Layer 2. Die MAC lässt sich im Zweifelsfall schnell aus der Inventar-DB kopieren. Und sonst kann das UI des Admin-Tools das auch komfortabler machen, indem es z.B. die Herstellerkennung schon vorgibt. Bei entsprechender Vergabe entspricht der MAC-Suffix der Seriennummer oder lässt sich aus dieser zusammen mit dem Gerätetyp errechnen, was wiederum das Tool machen kann. Dann müsste nur eine im Zweifelsfall noch kürzere Seriennummer eingetragen werden. Peter II schrieb: > er soll ja nicht DoS machen sondern einen "Rundruf". Wenn der Port dann > schon dicht gemacht wird, würde ja nicht mal dhcp funktionieren. Klar, aber wenn die Dosierung der Pakete mit dem Holzhammer erfolgt ;)
Malte S. schrieb: > Darum ging es doch, dass die ja bekannt ist und sich die IP daraus > ermitteln lässt. Am DHCP-Server oder eben auf Layer 2. Die MAC lässt > sich im Zweifelsfall schnell aus der Inventar-DB kopieren. Als Admin will ich nicht irgendwelche Zahlenkolonnen abschreiben oder kopieren. Da will ich ein Programm starten und meine Geräte sehen.
Peter II schrieb: > Da will ich ein Programm starten und meine Geräte sehen. Es geht doch hier ausschließlich um die initiale Kontaktaufnahme.
Jörg Wunsch schrieb: >> Da will ich ein Programm starten und meine Geräte sehen. > > Es geht doch hier ausschließlich um die initiale Kontaktaufnahme. nein, wenn man etwas weiterdenkt geht es auch um das später wiederfinden. Wem ist es nicht schon mal passiert, das man die IP von eine Gerät vergessen hat?
Peter II schrieb: > nein, wenn man etwas weiterdenkt geht es auch um das später > wiederfinden. Und wenn man ganz weiterdenkt könnte man ja eine Speichernfunktion einbauen. ;-) Und das der "Recovery-Fall" ggf. nicht ganz so komfortabel ist muss ja nun kein Beinbruch sein. Es ging außerdem ja nur darum einen eindeutig dem Gerät zuordne baren Wert der auch ohne Display verfügbar ist zu erhalten ohne jedes gerät noch zusätzlich mit einem "Namen" ausstatten zu müssen... Die Xports nutzen z.B. die letzten 6 Hex Pärchen ... Das ist weniger als die Durchschnittliche Telefonnummer oder eine IBAN...
@Rainer Reusch Hast das Problem gelöst oder hast einfach aufgegeben???
@ Stephan Nein, keineswegs! Die Diskussion ist in eine Richtung abgedriftet, die für mich weniger von Interesse ist. Es ist zwar nett, dass sich hier einige Gedanken darüber machen, wie ich mein Projekt realisieren könnte, aber danach habe ich eigentlich nicht gefragt. Für mich ist das Problem gelöst, eben auch durch ein paar Beiträge in diesem Thread (insbesondere auch von Dir). An dieser Stelle vielen Dank an alle! Ich möchte mich hiermit aus der Diskussion ausklinken. Wer Lust hat, darf natürlich weiter machen. Um das zu befeuern, fasse ich hier meine endgültige Lösung nochmal zusammen: 1) Der Endanwender bekommt das Gerät so ausgeliefert, dass es zunächst per DHCP seine IP-Adresse bezieht. 2) Der Endanwender wird darüber informiert, dass während der Inbetriebnahme nur ein Gerät (meines Typs) im LAN vorhanden sein darf. 3) Der Endanwender wird angewiesen, dem Gerät eine feste IP-Adresse zu zu weisen (Konfigurationsdialog im Windows-Programm), weil es keinen Namen in einem DNS-Server hinterlegen kann, über den es gefunden werden könnte. 4) Damit der Endanwender das Gerät zur Konfiguration findet, muss er die ersten drei Adress-Zahlen des lokalen Netzwerks in einen Dialog eingeben. 5) Zum finden des Geräts während der Einrichtung betätigt er einen Button. Daraufhin wird eine TFTP-Leseanfrage (lesen einer bestimmten Datei) an die Adresse x.y.z.255 (x, y und z sind die Benutzereingaben) geschickt. Das entspricht im Grunde auch einem Broadcast. Das angeschlossene Gerät liefert die "Datei", die die tatsächliche IP-Adresse enthält. Wird keine Datei geliefert, ist das Gerät nicht angeschlossen. 6) Zur weiteren Konfiguration wird die tatsächliche (per DHCP vergebene) IP-Adresse verwendet. 7) Der Endanwender gibt eine neue (feste) IP-Adresse ein. Sie wird an das Gerät übermittelt und dort gespeichert. Die Windows-Software und das Gerät verwenden künftig diese feste Adresse (nach einem Neustart). Auch künftige Konfigurationen (auf demselben PC) laufen künftig über die gespeicherte IP-Adresse. Dieser Trick mit der IP-Adresse x.y.z.255, der hier den Diskussionsstoff geliefert hat, wird während eines PC-Lebens vielleicht nur ein-, zweimal angewendet! Ich hoffe, das jetzt für alle verständlich erläutert zu haben. Jetzt dürft ihr euch gerne wieder darüber auslassen.
Rainer Reusch schrieb: > Ich hoffe, das jetzt für alle verständlich erläutert zu haben. Ja. Wir sind jetzt Bilde, dass deine Methode bei einem Netz mit einer Maske von ungleich 24 Bit nicht funktioniert … Nach sowas wie IPv6 werden wir dann erst im 22. Jahrhundert fragen. :)
:
Bearbeitet durch Moderator
Rainer Reusch schrieb: > Dieser Trick mit der IP-Adresse x.y.z.255, der hier den Diskussionsstoff > geliefert hat, wird während eines PC-Lebens vielleicht nur ein-, zweimal > angewendet! Und nochmal der Hinweis auf Netze, deren Broadcast-Adresse z.B. x.y.z.127 lautet...
Ich habe eure nicht völlig von der Hand zu weisenden Bedenken vernommen! IPv4 setze ich schlichtweg voraus. Ich denke, das ist in einem lokalen Netz auch kein Problem (auch nicht in 10 Jahren). Ich werde das Produkt (bei dem es sich übrigens um kein Massenprodukt für den unbedarften Privatanwender handelt) aber jetzt so mal auf den Kunden los lassen. Die Erfahrung wird zeigen, ob es Probleme gibt. Und wenn, kann man den Kunden anweisen, zur Konfiguration den PC vom LAN vorübergehend zu trennen und nur das Gerät an zu schließen (über Switch oder Crossover-Kabel). Im Einzelfall kann das Gerät auch schon ab Werk mit einer gewünschten IP-Adresse ausgeliefert werden.
Rainer Reusch schrieb: > Und wenn, kann man den Kunden anweisen, zur Konfiguration den PC vom LAN > vorübergehend zu trennen und nur das Gerät an zu schließen Woher bekommt das Gerät dann eine IP-Adresse, wenn es DHCP machen will? > IPv4 setze ich schlichtweg voraus. Ich denke, das ist in einem lokalen > Netz auch kein Problem (auch nicht in 10 Jahren). Zeitgemäß ist es ja schon heute nicht mehr. > Ich werde das Produkt > (bei dem es sich übrigens um kein Massenprodukt für den unbedarften > Privatanwender handelt) Eben darum kann die /24er Netzmaske durchaus zum Problem werden. Gerade in Unternehmen und Institutionen gibt es durchaus deutlich mehr als die pseudo-Standard-Variante 192.168.1.0/24.
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.