Ethernet Gegenstelle detektieren

Der Web Server kann keine Verbindung zu einem Browser aufbauen. Ergo 
kann er nicht wissen, ob ein Browser verfügbar ist.

Du kannst höchstens erkennen, ob der Computer, auf dem der Browser 
erwartet wird, erreichbar ist (mit Ping).

Hallo,

das ist ein grundsätzliches Problem: ein Browser baut keine Verbindung 
auf und hält sie aufrecht, sondern fordert eine Seite an und das wars - 
wenn du nach dem Browser fragst, kann der User schon wo ganz anders 
sein, und er meldet sich nie wieder.

Georg

Peter Müller schrieb:

> Ist es möglich, die Unterscheidung zu treffen anhand der Frage "Hängt an
> der Ethernetschnittstelle gerade ein Webbrowser?" - dann soll ein
> Webserver zum Setup starten. Anderenfalls in den Run-Modus verzweigt
> werden.

Nein, das ist weitgehend unmöglich und zwar deshalb, weil es praktisch 
schon unmöglich ist, festzustellen, ob überhaupt ein Peer vorhanden ist, 
mit dem man kommunizieren könnte.

Alles, was man ziemlich sicher feststellen kann, ist der Status auf 
Link-Level. Der sagt allerdings auch schon "Peer vorhanden", wenn dein 
Gerät als einziges an einen dummen Switch oder Hub angeschlossen ist, 
also weit und breit nix ist, mit was man tatsächlich reden könnte.

Aber selbst, wenn man mal (per Axiom) voraussetzt, dass das 
angeschlossene Gerät kein Switch/Hub, sondern immer ein Computer ist, 
bist du auch noch keinen Schritt weiter. Denn du kennst dann trotzdem 
noch nichtmal seine MAC-Addresse, geschweige denn seine IP.

Du müsstest also ein weiteres Axiom einführen, nämlich die (durch nichts 
begründete) Annahme, dass auch das gegnerische Gerät über die 
Schnittstelle dringend kommunizieren will und deshalb die Etablierung 
eines Links zum Anlass nimmt, DHCP-Broadcasts über diesen Link zu 
senden.
Dann allerdings bist du einen Riesenschritt weiter, denn du kennst jetzt 
die MAC des Peer. Und wenn der Peer eine Schlampe und deshalb wenig 
wählerisch bei der Wahl seiner Kommunikationspartner ist, wird er 
vielleicht sogar eine DHCP-Antwort von dir akzeptieren, dann kennst du 
sogar seine IP, weil du ihm die selber zugeteilt hast. Alles, was du bis 
hierher machen mußt: Einen DHCP-Server auf deiner Kiste laufen lassen.

Schon gewonnen? Nein, natürlich noch längst nicht. Wenn der Peer mehrere 
Netzwerkschnittstellen hat und eine andere bereits vorher verbunden war, 
wird er in der Regel nicht seine default route auf "deine" Schnittstelle 
legen. Also ist schon wieder das nächste Axiom fällig: der Peer darf 
entweder nur eine aktive Netzwerkschnittstelle haben oder muß bereit 
sein, freiwillig die default route auf jedes neu auftauchende Interface 
zu legen. Das wird jetzt aber schon sehr unkonventionell, nur 
Vollidioten würden ihre Rechner derart konfigurieren und genau die wären 
garnicht dazu in der Lage, dies zu tun...

Aber weiter mit dem neuen Axiom. Jetzt gewonnen? Nein, natürlich immer 
noch nicht. Du weisst immer noch nicht, ob auf dem Peer ein Browser 
läuft und du hast auch keine Möglichkeit, das durch irgendwelche Tricks 
aktiv herauszufinden. Du müßtest warten, bis der Browser von sich aus 
irgendwas tut. I.d.R. wäre bei einem neuen Interface das erste Anzeichen 
dafür, daß er einen DNS-Request macht. Du müßtest also auch noch einen 
DNS-Server laufen haben, der jeden Request zu deiner eigenen IP auflöst, 
denn nur mit so einer Antwort käme der Browser das erste Mal auf die 
Idee, einen (mehr oder weniger) browsertypischen Request zu senden, an 
dem du dann letztlich (mit recht geringer Zuverlässigkeit) erkennen 
könntest, dass auf dem Peer ein Browser läuft...

Hey,

danke allen für die Beiträge! Hatte mir Ähnliches schon gedacht, aber 
manchmal fühlt man sich ja doch besser, wenn man eine Idee mal in der 
Runde ausgeboxt hat, wie hier geschehen :-)
Danke insbesondere an c-hater, für die detaillierte Darlegung!

Einen schönen Abend!