Webserver discovery wenn nicht im gleichen Subnet

[Thomas F. (tf1973)]

Hallo zusammen,

folgendes Szenario: eine Dashboard Anwendung im Browser soll auf 
verschiedene Webserver im LAN zugreifen können. Diese laufen auf 
ESP32-S3. Es soll die Möglichkeit bestehen, dass diese Webserver 
automatisch erkannt und aufgelistet werden. Welche Möglichkeiten 
bestehen um das möglichst effizient zu gestalten? Sicher, im gleichen 
255.255.255.0 Subnet könnte man einfach durchpingen. Bei 255.255.0.0 
wird das definitv nichts gehe ich von aus. Außerdem muss noch der Fall 
abgedeckt werden, das kein DHCP zur Verfügung steht.

Danke schonmal!

[Rüdiger B. (rbruns)]

Broadcast/Unicast wurde dafür gemacht.
Oder ein Ping auf das Netzwerk, also 192.168.255.255 .

[Tobias S. (tobias_s)]

Hallo,

ich würde es mit mdns Discovery versuchen.

Arduino: https://docs.arduino.cc/libraries/arduinomdns/
ESP-IDF: 
https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/protocols/mdns.html

[Harald K. (kirnbichler)]

Rüdiger B. schrieb:
> Oder ein Ping auf das Netzwerk, also 192.168.255.255 .

Das gibt nicht sonderlich viele Antworten, deutlich weniger, als gerade 
im Netzwerk Geräte aktiv sind.

[Mario M. (thelonging)]

Thomas F. schrieb:
> * Dashboard Anwendung im Browser
> * nicht im gleichen Subnet
> * kein DHCP

Du bist auf dem Holzweg. Die genannten Lösungen funktionieren nur in 
stabiler Netzwerkumgebung und wären auch dann  von OS und Browser 
abhängig. Sonst kann man nur z.B. einen ESP nehmen, der einen AP 
aufmacht, die anderen ESPs per ESP-NOW abfragt und die Daten dann auf 
seiner Webseite darstellt.

[Nemopuk (nemopuk)]

Wie "toll" automatisches Discovery funktioniert erlebe ich seit 30 
Jahren mit Druckern und der Dateifreigabe von Windows. Nein Danke, egal 
wie es gelöst wird, ich habe kein Interesse mehr.

Auf der Arbeit würde so ein Dashboard übrigens wegen der Scans von der 
Firewall blockiert werden.

[Markus K. (markus-)]

Thomas F. schrieb:

> folgendes Szenario: eine Dashboard Anwendung im Browser soll auf
> verschiedene Webserver im LAN zugreifen können.

Wie schon geschrieben wurde: Broadcasts kann man aus fremden Subnetzen 
empfangen, allerdings muss das ja UDP sein und das kann man nicht im 
Browser empfangen.

Broadcasts gehen auch eher nicht über einen Router in andere Subnetze. 
Sind alle Subnetze auf einem Switch, dann könnte man Broadcasts 
empfangen, aber wenn die Subnetze nicht alle in den 
Netzwerkeinstellungen eingetragen sind, dann kann man sich nicht 
verbinden. Man kann also durch den Broadcast feststellen, dass die 
anderen Rechner da sind, aber dann nicht auf deren Webserver zugreifen.

[Ob S. (Firma: 1984now) (observer)]

Harald K. schrieb:
> Rüdiger B. schrieb:
>> Oder ein Ping auf das Netzwerk, also 192.168.255.255 .
>
> Das gibt nicht sonderlich viele Antworten, deutlich weniger, als gerade
> im Netzwerk Geräte aktiv sind.

Nunja, er will ja bestimmte Geräte finden, über deren Verhalten er 
vermutlich die Kontrolle hat. Dann würde das schon gehen. Er müßte denen 
halt allen beibiegen, dass sie auf Ping an die Broadcastadresse 
antworten.

Naja, es werden gelegentlich noch einige Uralt-Geräte im LAN ebenfalls 
auf den Ping-Broadcast antworten. Die kann er dann ausfiltern, indem er 
wirklich einen Web-Request versucht.

Aber, wenn die Broadcastadresse mangels DHCP-Server garnicht bekannt 
ist, kann man das sinnlose Broadcast-Pingen auch gleich ganz einsparen 
(und damit den Aufwand, das den gesuchten Targets beibringen zu müssen).

Einfach gleich nur ARP benutzen. Das ist die bestmögliche Näherung für 
die Aufgabe, in einer unbekannten Netzumgebung potentielle Server zu 
finden. Zumindest die drei privaten Adressbereiche sind mit einer 
binären Suche und halbwegs intelligenter Auswertung der eintreffenden 
Antworten relativ schnell abgeklappert. Nunja: wenn nicht gerade ein 
intelligenter Switch mit threat-protection den Usurpator als solchen 
erkennt und schlicht mittendrin abwürgt...

Die bessere Strategie bei unbekanntem Netzwerk ohne DHCP deshalb, 
zunächst mal nur passiv die ARP-Broadcasts anderer zu belauschen. Es 
dauert zwar eine Weile, bis man ein halbwegs verläßliches Ergebnis hat, 
aber die aktive Suche kann dann sehr viel gezielter und damit 
entsprechend schneller sein. Und mit etwas Glück ein recht zuverlässiges 
Ergebnis liefern noch bevor irgendeine threat-protection Alarm gibt.

[Frank K. (fchk)]

Thomas F. schrieb:

> folgendes Szenario: eine Dashboard Anwendung im Browser soll auf
> verschiedene Webserver im LAN zugreifen können. Diese laufen auf
> ESP32-S3. Es soll die Möglichkeit bestehen, dass diese Webserver
> automatisch erkannt und aufgelistet werden.

Eine weitere Möglichkeit wäre so etwas wie dyndns, wo sich alle Server 
nach dem Aktivieren des Interfaces sich mit ihrer IP-Adresse 
registrieren.

IPv6 nutzt vermehrt Multicast. Da weiß ich aber nicht, ob der IP-Stack 
deiner ESP dafür Support hat.

fchk

[Εrnst B. (ernst)]

Thomas F. schrieb:
> Bei 255.255.0.0 wird das definitv nichts gehe ich von aus.

Wieso?
Die Frage kam letztes Jahr schonmal auf. 64k gleichzeitige TCP-Connects 
(O_NONBLOCK) versuchen und bei Verbindung einen HTTP-GET zu senden geht 
Single-Threaded in ca. 2 Sekunden (Reine CPU-Zeit, x86@2GHz).

Beitrag "Re: IP-Subsysteme im LAN effektiv finden?"

Wär allerdings für einen Server, wenn das autark im Webbrowser per 
Javascript laufen soll, ist das eine andere Geschichte. Aber da kannst 
du auch kein arp, multicast u.ä. verwenden.

[Nick (nick15)]

Eigentlich ist mDNS heutzutage schon der richtige Weg. Entgegen der 
landläufigen Meinung funktioniert das auch subnetzübergreifend 
problemlos, wenn man einen mDNS Repeater dazwischen hängt. Gute Router 
können das von Haus aus. Ich nutze das z.B. um einen Drucker, der in 
einem anderen VLAN hängt, über AirPrint ansprechen zu können.

Alternativ geht das auch mit einem Computer, der in beiden Subnetzen 
hängt. Siehe dazu hier: 
https://hifish.ch/2022/02/21/netzwerk-segmentierung-und-mdns-bonjour-airprint/ 
oder z.B. als Docker-Container hier: 
https://hub.docker.com/r/yuxzhu/mdns-reflector (letzteren habe ich seit 
ein paar Jahren problemlos für die Docker-interne Weiterleitung im 
Einsatz).

(Voraussetzung dafür, dass die subnetzübergreifende Erkennung dann am 
Ende auch was bringt ist natürlich, dass der Router die Pakete dann auch 
in das jeweils andere Subnetz (und wieder zurück) leitet und etwaige 
Firewall-Regeln entsprechend angepasst sind. Sonst sind die Dienste im 
anderen Subnetz durch den Repeater zwar bekanntgemacht, lassen sich aber 
nicht erreichen.)

Wie du die so erkannten Geräte dann in deine Dashboard-Anwendung 
bringst, ist dann nochmal eine andere Frage. Kommt dann drauf an, was 
für ein Backend die benutzt. Sollte aber für alles gängige entsprechende 
mDNS libraries geben.

[Frank E. (Firma: Q3) (qualidat)]

Man kann doch problemlos ein eigenes broadcast-basiertes Protokoll in 
der Art von ARP entwickeln und nutzen.

Der interessierte Netzwerkteilnehmer (der mit dem Dashboard) sendet 
einen solchen Broadcast (UDP, spezieller Port). Die erreichbaren 
Clients, die etwas damit anfangen können, antworten an die Adresse des 
Fragenden. Die Antwort muss kein Broadcast sein, die Antwortadresse ist 
bekannt, wenn die im Broadcast stand. Und sie kann sogar per TCP 
erfolgen, damit sie nicht verloren geht.

Man muss damit auch nicht alle Netzwerkteilnehmer "durchpingen", den 
Broadcast empfangen sowieso erstmal alle (im gleichen Subnet) und 
antworten nur dann, wenn sie auch zur Zielgruppe gehören.

[Nick (nick15)]

Frank E. schrieb:
> Man kann doch problemlos ein eigenes broadcast-basiertes Protokoll in
> der Art von ARP entwickeln und nutzen.

Das ist maximal unnötig. Wieso Zeit verlieren mit einer eigenen 
Implementierung, wenn man auch einfach mDNS samt der passenden libraries 
nutzen kann?

Eine Webapp, die z.B. sämtliche per mDNS erkannten Webserver einsammelt 
und als Liste präsentiert baut ChatGPT dir mit einem Prompt …

[Markus K. (markus-)]

Nick schrieb:
> Eine Webapp, die z.B. sämtliche per mDNS erkannten Webserver einsammelt
> und als Liste präsentiert baut ChatGPT dir mit einem Prompt …

Redet mDNS nicht UDP? Das geht nicht im Browser. Man braucht also ein 
Hilfsprogramm, das außerhalb läuft.

[Frank K. (fchk)]

Nick schrieb:
> Frank E. schrieb:
>> Man kann doch problemlos ein eigenes broadcast-basiertes Protokoll in
>> der Art von ARP entwickeln und nutzen.
>
> Das ist maximal unnötig. Wieso Zeit verlieren mit einer eigenen
> Implementierung, wenn man auch einfach mDNS samt der passenden libraries
> nutzen kann?

Ich stimme mit @Nick überein, dass es deutlich sinnvoller ist, eine der 
zahlreichen vorhandenen Lösungen zu verwenden als eine weitere 
Sonderlocke zu erzeugen, natürlich nur unter der Vorausetzung, dass alle 
vorhandenen Anforderungen erfüllt werden. Was in dem konkreten Fall das 
Beste ist (mDNS, WS-Discovery, ...) müsste man sehen, aber da gibts auf 
jeden Fall was von ...

fchk

[Nick (nick15)]

Markus K. schrieb:
> Redet mDNS nicht UDP? Das geht nicht im Browser. Man braucht also ein
> Hilfsprogramm, das außerhalb läuft.

Ja, natürlich. Aber bei einem Dashboard bin ich mal davon ausgegangen, 
dass es ein entsprechendes Backend gibt.

Ganz unabhängig davon würde ich sowieso empfehlen, dass man die ganze 
Discovery nicht den Browser machen lässt, sondern das Backend. Weil dann 
müssen die mDNS-Broadcasts für den Client gar nicht sichtbar sein. Das 
würde nämlich spätestens dann zu Problemen führen, wenn man das 
Dashboard über eine Verbindung aufruft, die mDNS (oder auch sämtliche 
Form von UDP-Broadcasts) nicht wirklich unterstützt, z.B. über ein 
WireGuard-VPN auf iOS (nicht sicher, ob das bei Android geht).

Wenn man den Server dann auch noch ins gleiche Subnetz wie die zu 
entdeckenden Geräte hängt, könnte man sich sogar den mDNS-Repeater 
sparen.

[Mario M. (thelonging)]

Markus K. schrieb:
> Redet mDNS nicht UDP? Das geht nicht im Browser. Man braucht also ein
> Hilfsprogramm, das außerhalb läuft.

Ja, nennt sich Windows(10/11).

[Markus K. (markus-)]

Ich habe gerade dass da gefunden
https://github.com/hrzlgnm/mdns-browser

Das hat Clients für verschiedene Betriebssysteme. Mal kurz unter Windows 
ausprobiert, es findet 8 Services auf der Fritzbox, je 1-2 auf den 
Repeatern und einen der Raspberry Pis.

[Markus K. (markus-)]

Mario M. schrieb:
> Markus K. schrieb:
>> Redet mDNS nicht UDP? Das geht nicht im Browser. Man braucht also ein
>> Hilfsprogramm, das außerhalb läuft.
>
> Ja, nennt sich Windows(10/11).

Das kann man im Browser abrufen?
Oder meinst Du einfach die Windows-Netzwerkumgebung?

[Mario M. (thelonging)]

Ich meinte die Namensauflösung per mDNS. Also einfach die Geräte passend 
benennen, dann kann man sie im Browser über den Namen aufrufen. 
Inwiefern "service discovery" im Broser möglich ist, weiß ich nicht. 
Vielleicht geht da was mit JavaScript und Sockets.

[Markus K. (markus-)]

Mario M. schrieb:
> Inwiefern "service discovery" im Broser möglich ist, weiß ich nicht.
> Vielleicht geht da was mit JavaScript und Sockets.

Eher nicht. Javascript im Browser kann kein UDP, was aber nötig wäre.

[Rüdiger B. (rbruns)]

Ob S. schrieb:
> Einfach gleich nur ARP benutzen.

Und der ARP-Cache füllt sich auch mit dem Ping auf die Broadcast 
Adresse.

[Nick (nick15)]

Ich verstehe immer noch nicht, wieso der Client da irgendwas machen 
soll. Das soll die Webapp im Backend machen und gut ist. Dann hat man es 
komplett Browser- und Netzwerkunabhängig. Das einzige, wozu der Client 
fähig sein muss, ist eine HTTP-Verbindung zu den entdeckten Geräten 
(wobei man selbst das proxien könnte, aber lassen wir das mal).

Proof of concept für ein Dashboard nach zwei Prompts mit ChatGPT; das 
ist der Python-Code:

from flask import Flask, render_template
from zeroconf import Zeroconf, ServiceBrowser, ServiceListener
import threading
import socket

app = Flask(__name__)
zeroconf = Zeroconf()
discovered_services = {}

class HTTPServiceListener(ServiceListener):
    def add_service(self, zeroconf, type, name):
        info = zeroconf.get_service_info(type, name)
        if info:
            address = socket.inet_ntoa(info.addresses[0])
            port = info.port
            full_url = f"http://{address}:{port}"
            discovered_services[name] = full_url

    def remove_service(self, zeroconf, type, name):
        if name in discovered_services:
            del discovered_services[name]

def start_mdns_browser():
    listener = HTTPServiceListener()
    ServiceBrowser(zeroconf, "_http._tcp.local.", listener)

# Start mDNS discovery in a background thread
threading.Thread(target=start_mdns_browser, daemon=True).start()

@app.route("/")
def index():
    return render_template("index.html", services=discovered_services)

if __name__ == "__main__":
    app.run(debug=True, host="0.0.0.0", port=5000)

Den HTML-Code kann ich nicht posten, weil Spamschutz, deshalb im Anhang.

Zum Ausführen, python-Skript unter $WORKDIR/dashboard.py ablegen und 
index.html unter $WORKDIR/templates/index.html ablegen.

Dann nur noch dependencies installieren und starten:

cd $WORKDIR
python3 -m venv .venv
source .venv/bin/activate
pip3 install flask zeroconf
python3 ./dashboard.py

Und dann im Browser das Dashboard unter http://localhost:5000 aufrufen.

[Tobias S. (tobias_s)]

Als Ergänzung zu Nicks Vorschlag könnte man zusätzlich einen eigenen 
Service anlegen – ähnlich wie es beim Arduino-OTA-Flashen gemacht wird.

Beispiel unter Linux:

avahi-browse _arduino._tcp
+ enp34s0 IPv4 esp32-d4d4xxxxxx    _arduino._tcp        local

[Hannes J. (pnuebergang)]

Namensauflösung reicht ja nicht, du musst die aufzulösenden Namen erst 
mal haben. Willst du die raten? Namenskonvention und dann 
durchprobieren? Ist doch Mist.

Um es halbwegs vernünftig zu machen könnte man z.B. noch so etwas wie 
DNS-SD hinzu nehmen um eine entsprechende Service-Discovery zu machen um 
die Namen zu bekommen. Die erhaltenen Hostnames kann man dann mit mDNS 
oder was auch immer auflösen.

Das wiederum bedeutet die PTR, SVR und TXT DNS Records dafür müssen 
aufgesetzt werden. Eigentlich kein Problem - in einem anständig 
administrierten Netzwerk, oder sogar durch die Clients selber die sich 
registrieren (Dynamic DNS). Das entspricht dann einem Bootstrapping der 
Service-Discovery-Konfiguration die auch nicht ohne ein paar 
Basisconfigurationen auf den Clients geht.

Und jetzt sind wir beim eigentlichen Punkt. Das Vorhaben ist mal wieder 
der klassische feuchte Traum alles ohne Infrastrukturunterstützung, ohne 
Netzwerkadministation und ähnliches machen zu wollen. Es soll irgendwie 
einfach magisch funktionieren. Alleine schon wieder die Idee einfach mal 
alles durchzupingen oder mit ARP-Requests vollzumüllen ... Das kannst du 
in einem ranzigen Heimnetz machen (in dem stolz auf DHCP verzichtet 
wurde), aber viel Spaß damit in Kundennetzwerken durchzukommen (wenn der 
Admin nicht gerade ein Volltrottel ist).

Also, Standardprotokolle auswählen die das machen was man will, breit 
sein den Preis dafür zu bezahlen. Nämlich die dafür dafür notwendige 
Infrastruktur im Netz aufsetzen zu müssen. Wie der Rheinländer sagt, von 
nix kütt (kommt) nix.

---

Nebenbei bemerkt, die Behauptung dass ein Host die Broadcastadresse 
seines Subnetzes mangels DHCP-Server nicht kennt ist natürlich auch 
quatsch.

Damit er überhaupt über IP kommunizieren kann (und jetzt komm mir keiner 
mit Ethernet-only, man könnte ja ...), braucht er eine IP-Adresse und 
eine Netmask. Hat er die nicht ist er auf IP-Ebene nicht existent. Auch 
hier wieder von nix kütt nix.

Mit IP-Adresse und Mask ist jedoch auch die Broadcast-Adresse 
festgelegt. Es ist immer die letzte Adresse im Subnet.

Ohne DHCP müssen die IP Adresse und Mask zum Beispiel statisch von Hand 
auf dem Host konfiguriert sein. Das macht bei großen Netzwerken viel 
Spaß ... Oder man spielt Zeroconf-Lotterie und der Host würfelt sich 
nach gewissen Regeln eine IP-Adresse in 169.254.0.0/16 aus. Auch hier 
ist die Broadcast-Adresse die letzte Adresse im Subnet 169.254.255.255. 
Also bekannt.

[Alexander (alxc)]

Habe demletzt bei einem Kunden aus der Industrie ein Netzwerk vorgeführt 
bekommen wo die Knoten einfach angesteckt werden und los geht’s mit IPv6 
(only) und mDNS. War keinerlei Netzwerkkonfiguration notwendig und 
keinerlei Kenntnis von IP Adressen. Das hat mir sehr gut gefallen. 
Natürlich ging’s da nicht um solche hochkomplexe Geschichten wie 
Internetzugang und Drucker sondern „nur“ um Maschinen die miteinander 
reden sollten.

Dennoch fand ich das so überzeugend dass ich mich frage warum wir noch 
mit IPv4 Konfiguration unsere Zeit verschwenden.

[Sheeva P. (sheevaplug)]

Thomas F. schrieb:
> folgendes Szenario: eine Dashboard Anwendung im Browser soll auf
> verschiedene Webserver im LAN zugreifen können. Diese laufen auf
> ESP32-S3. Es soll die Möglichkeit bestehen, dass diese Webserver
> automatisch erkannt und aufgelistet werden. Welche Möglichkeiten
> bestehen um das möglichst effizient zu gestalten? Sicher, im gleichen
> 255.255.255.0 Subnet könnte man einfach durchpingen. Bei 255.255.0.0
> wird das definitv nichts gehe ich von aus. Außerdem muss noch der Fall
> abgedeckt werden, das kein DHCP zur Verfügung steht.

Das wäre ja noch schöner, wenn jede Browser-Anwendung meine lokalen 
Netze scannen könnte. Was Du also suchst, ist im Prinzip eine 
Sicherheitslücke, deren Ausmaß kaum übertrieben werden kann.

Zudem muß die Anwendung, die hinterher im Browser laufen soll, ja 
irgendwo her kommen, mithin: es bedarf eines Webservers. Egal, ob das 
Apache, Nginx, Caddy, oder irgendwas anderes ist, er muß auf irgendeiner 
Hardware unter einer zuvor bekannten Location (IP-Adresse, Hostname) 
laufen.

Ich persönlich würde vermutlich einen SBC nehmen, nennen wir ihn 
Raspberry Pi, und den in mein lokales Netz sowie in die betreffenden 
Subnetze hängen. Der könnte auch einen DHCP- und / oder DNS-Server 
enthalten, zum Beispiel dnsmasq, und den ESPs per DHCP ihre 
IP-Konfiguration mitteilen; anhand der DNS-Leases kann die darauf 
laufende Anwendung dann herausfinden, welche der ESPs gerade Leases 
haben, und die gewünschten Informationen dort per HTTP abfragen, sie 
aggregieren, und der Browser-Anwendung zur Verfügung stellen. Dadurch 
lassen sich dann auch die Zugriffe auf die Subnetze der ESPs 
feingranuliert steuern, sofern solche Zugriffe denn überhaupt notwendig 
sein sollten.

[Thomas F. (tf1973)]

Danke für die bisherigen Vorschläge! Hilfsprogramme bzw. -hardware ist 
nicht möglich...
Vielleicht muss ich doch noch etwas Hintergrundinfos geben: Das Ganze 
ist für Pro Audio Geräte vorgesehen, aktive  Lautsprecher bzw. 
Verstärker. Alle mit der gleichen Netzwerk Hardware, sprich ESP32. Der 
reicht auch (ganz dick) aus um mit der Außenwelt zu kommunizieren und 
ein paar Steuerbefehle an die DSPs zu verteilen.
Vorgabe und Idee waren nun, alles ohne jegliche Softwareinstallation auf 
Client Seite zu realisieren, sprich Webbrowser-only. Das funktioniert 
auch so problemlos. Allerdings gibt es da auch die ein oder andere Hürde 
die man nicht ignorieren kann:

- die Anwender sind in der Regel keine IT Profis, man muss damit 
rechnen, dass die manuelle Vergabe einer IP Adresse schon ein Problem 
darstellt (Ja, isso...auch wenn das im Jahr 2025 deutlich seltener 
vorkommt)
- Geräte gehen auch mal in den Rental und dann haben die Anwender den IP 
Adressbereich eventuell komplett umgestellt
- man muss davon ausgehen, das die IT Umgebung auch mal recht 
spartanisch ausfallen kann, kein Router, kein DHCP, günstiger 
"Baumarkt-Switch". Und auch da muss das funktionieren.

So wie es aussieht, bleibt dann wohl nichts anderes übrig, als allen 
Geräten eine fixe Factory IP Adresse zu vergeben um zumindest erstmalig 
per Webbrowser erkannt zu werden (einzeln angeschlossen natürlich...). 
Was dann der Anwender macht, ist sein Problem. Ich gehe auch davon aus, 
das es nicht wirklich viele Anwendungen gibt, wo wirklich mehr als 256 
Geräte gleichzeitig benötigt werden. Also könnte man auch da den IP 
Adressbereich zum discovery per default einschränken, aber 
selbstverständlich alle Optionen offen halten. Wer wirklich mehr 
benötigt, weiß ganz sicher auch wie man IP Adressen ändert, weil dann 
geht es um richtig dicke Anwendungen.

[Harald K. (kirnbichler)]

Thomas F. schrieb:
> Vorgabe und Idee waren nun, alles ohne jegliche Softwareinstallation auf
> Client Seite zu realisieren, sprich Webbrowser-only.

Und wie kommt das in den Webbrowser, was Deine Konfigurationsmagie 
durchführen soll?

Wie willst Du das ausliefern?

Die übliche Vorgehensweise bei derartigen Systemen ist die, daß ein in 
Betrieb genommenes Gerät ein eigenes WLAN aufspannt und dann der 
Anwender sein Smartphone mit diesem verbindet. Dann kann das mit dem 
Webserver auf dem Gerät kommunizieren.

Dann aber kann auch der Webserver auf dem Gerät sich darum kümmern, 
seine Kumpels zu entdecken, das muss nicht der Webbrowser im Smartphone 
veranstalten.

[Εrnst B. (ernst)]

Thomas F. schrieb:
> Vorgabe und Idee waren nun, alles ohne jegliche Softwareinstallation auf
> Client Seite zu realisieren, sprich Webbrowser-only.

ja, dann mach das doch einfach und schau wie's läuft.
Lokale IP kriegst du per Javascript, ggfs. über das 
"window.RTCConnection"-Objekt.
Dann einfach der Reihe nach die IPs durchklingeln, direkt mit einem GET 
auf eine spezielle Detection-Adresse, z.B. "GET /wasbistdu", damit du 
gleich erkennen kannst, was deine Geräte sind, und was nur irgendein 
Drucker, Router oder sonstwas im Netzwerk.

Das ganze hinter einem "Scan"-Button verstecken, und für Profi-Anwender 
auch Option zum manuellen Eingeben von IPs vorsehen.
Idee: der 08/15 Heimanwender hat eh seine Fritzbox mit /24er Netz, da 
ist das Scannen in Sekundenbruchteilen durch.
Der "Profi" mit /16er Netz wird wohl auch wissen, wie er IPs eingibt.

[Nick (nick15)]

Ich verstehe immer noch nicht wie das Dashboard, das du darstellen 
willst, in den Webbrowser kommen soll.

Soll es wirklich ein Dashboard sein, muss es an irgendeiner Stelle einen 
Webserver geben. Und dort machst du den ganzen Discovery-Kram, mit 
welchen Mitteln auch immer.

Und das was du schreibst ist auch widersprüchlich. Du sagst, deine 
Anwender sind komplett nutzlos, willst ihnen dann aber Geräte mit 
statischer IP geben und dann "sollen sie selbst klarkommen". Das ist 
doch die dümmste Idee überhaupt; wenn die nicht mal in der Lage zu 
verstehen, dass es eine gute Idee ist irgendwo einen DHCP-Server zu 
haben, dann werden die ganz sicher nicht in der Lage sein, ihren 
Netzwerkadapter auf das Subnetz der statischen IP zu ändern, nur um dann 
x Geräte auf den richtigen Adressbereich umzukonfigurieren.

Was meiner Meinung nach eine elegante Lösung wäre:
1. Du stattest die Firmware deiner ESP32-Geräte mit mDNS aus, sodass sie 
ihre Webserver announcen.
2. Du kaufst dir irgendeine billo Kiste mit zwei LAN-Anschlüssen.
3. Du kaufst einen Switch.
4. Auf der billo Kiste läuft
   a) ein DHCP-Server auf eth0 mit einem eher obskuren Adressbereich, 
damit es keine Konflikte gibt (oder gleich nur IPv6, aber nicht sicher, 
ob ESP32 das unterstützt)
   b) gunicorn mit dem von mir oben geposteten Python-Skript, aber 
erweitert um eine reverse-proxy Funktion, sodass die iframes über den 
Server geladen werden und der Client keine Konnektivität ins Subnetz 
braucht.
   c) auf eth1 je nach dem (dazu gleich) ein DHCP-Client oder ein 
DHCP-Server.
   d) Das Ding hat eins von diesen billigen Displays, das den aktuellen 
Betriebsmodus von eth1 und die aktuelle IP-Adresse von eth1 anzeigt.
   e) Das Ding hat einen Knopf/Schalter/whatever mit dem man eth1 von 
DHCP-Client auf DHCP-Server umstellen kann.
5. Du sagst deinen (anscheinend dummen, aber das verstehen sie ja 
hoffentlich noch) Kunden, dass sie in den Switch aus Schritt 2 NUR die 
ESP32-Dinger einstecken sollen (das hier ist der wichtigste Teil, denn 
so behältst du die Kontrolle über das Netzwerk in dem die ESPs laufen).
6. Du sagst deinen Kunden, dass sie den Switch aus Schritt 2 mit eth0 
verbinden sollen (mach farbige Aufkleber auf die jeweiligen Ports und 
eine bebilderte Anleitung – mein Gott, es kann nicht so schwer sein, die 
Leute arbeiten mit "Pro Audio Geräten", die sind es doch gewohnt, Kabel 
an den richtigen Ort zu stecken?!).
7. Du sagst deinen Kunden, dass sie
   a) eth1 entweder mit ihrem Rechner oder
   b) mit ihrem restlichen Netzwerk verbinden sollen und
   c) je nach dem der Betriebsmodus angepasst werden muss. (Den 
Betriebsmodus kann man auch benutzerfreundlich benennen, und nicht 
"DHCP-Server" oder "DHCP-Client" auf das Display schreiben, sondern z.B. 
"direkter Anschluss" oder "Anschluss über Netzwerk".)
8. Du sagst deinen Kunden, dass sie die im Display angezeigte IP-Adresse 
aufrufen sollen. Dann kriegen sie ein hübsches Dashboard, wo sie sich in 
der Seitenleiste durch alle auf den ESP-32 laufenden Webserver 
durchklicken können und deren Inhalt im selben Browserfenster aufgerufen 
wird.

Fertig.

Wenn dir das alles zu aufwendig erscheint, dann hast du einfach eine 
falsche Vorstellung davon, wie viel Aufwand es ist, sowas unter 
sämtlichen Bedingungen und auch noch mit minimaler kundenseitiger 
Konfiguration einsatzfähig zu halten. (Eigentlich ist es aber gar nicht 
so viel Aufwand, die Softwareseite ist, wenn man sich auskennt, ziemlich 
schnell erledigt. Hardwaremäßig kann man für 2. d), e) übrigens auch 
wieder einen ESP einsetzen, dann einfach per USB angeschlossen.)

[Frank D. (Firma: LAPD) (frank_s634)]

ESPs--melden sich--> [Server [ Dashbaord] ] <--holt sich Dashb --> 
Browser

So geht das am einfachsten und nicht per Rumgefrage vom Browser direkt 
ins Netz, das ist doch völliger Murks, geht zgT prinzipiell nicht, auch 
wenn es da angeblich "Lösungen" gibt, die je nach Sonnenstand mal 
funktionieren.

Meinetwegen auch per mqtt oder sowas, jedenfalls ohne tumbes gescanne, 
das ist doch hirnverbrannt und macht man nur Einzelfällen aber nicht für 
eine dauerhafte Anwendung.

[Nick (nick15)]

Frank D. schrieb:
> So geht das am einfachsten und nicht per Rumgefrage vom Browser direkt
> ins Netz, das ist doch völliger Murks

Danke. Ich verstehe auch nach wie vor nicht, woher das Dashboard kommen 
soll, wenn nicht von einem Webserver irgendwo. Das Dashboard kommt ja 
nicht aus heiterem Himmel in den Browser.

[Thomas F. (tf1973)]

> Und wie kommt das in den Webbrowser, was Deine Konfigurationsmagie
> durchführen soll?
>
> Wie willst Du das ausliefern?

Also WLAN wird es nicht geben, ist auch absolut unüblich bei sowas. Das 
kommt in den Webbrowser, indem dieser eine Webseite aufruft auf dem 
ESP32 - oder habe ich deine Frage falsch verstanden? Das funktioniert 
auch alles soweit problemlos, es geht mir jetzt um mehrere Devices im 
LAN und wie man diese einfach und sicher identifizieren kann. Und das 
ganze nur mit dem Webbrowser, was die Sache auf Javascript reduziert 
gehe ich von aus.

[Thomas F. (tf1973)]

Nick schrieb:
> Frank D. schrieb:
>> So geht das am einfachsten und nicht per Rumgefrage vom Browser direkt
>> ins Netz, das ist doch völliger Murks
>
> Danke. Ich verstehe auch nach wie vor nicht, woher das Dashboard kommen
> soll, wenn nicht von einem Webserver irgendwo. Das Dashboard kommt ja
> nicht aus heiterem Himmel in den Browser.

Davon ausgehend, das es wenigstens EINEN verbunden Webserver gibt. Sonst 
macht das ja auch wenig Sinn :)

[Nick (nick15)]

Thomas F. schrieb:
> Davon ausgehend, das es wenigstens EINEN verbunden Webserver gibt. Sonst
> macht das ja auch wenig Sinn :)

Und wo ist das Problem daran, diesem Webserver ein Backend zu 
spendieren, das die Discovery macht (und ggfs. den Traffic proxied)? Mit 
anderen Worten: Ob da jetzt Apache läuft oder gunicorn, sollte keinen 
Unterschied machen. (Wobei mir einfällt, sogar Apache kann WSGI 
ausführen …)

Insofern, setz dich bitte mal mit meinen Umsetzungsvorschlägen 
auseinander.

[Harald K. (kirnbichler)]

Thomas F. schrieb:
> Also WLAN wird es nicht geben, ist auch absolut unüblich bei sowas.

Aha. Die meisten Leute verwenden ESP32, weil die WLAN-Hardware 
enthalten. Einige ESP32 können zwar auch Ethernet ("LAN"), brauchen 
dafür aber auch noch einen PHY.

Gut, wenn Du so etwas einsetzt, wird halt kein WLAN, sondern LAN 
verwendet.

Dann stellt sich natürlich die Frage, wie Du ohne Konfiguration 
Kontakt zum Webserver auf Deinem ESP32 aufnehmen willst. Woher soll der 
PC/das Smartphone/Wasauchimmer die IP-Adresse dieses ESP32 kennen?

> Das kommt in den Webbrowser, indem dieser eine Webseite aufruft auf dem
> ESP32 - oder habe ich deine Frage falsch verstanden?

Aha. Also ist da ein Webserver.

> Das funktioniert auch alles soweit problemlos, es geht mir jetzt um
> mehrere Devices im LAN und wie man diese einfach und sicher
> identifizieren kann.

Na, das kann der ESP32 übernehmen, mit dessen Webserver Du da redest.

> Und das ganze nur mit dem Webbrowser,

Nein. Eben nicht.

Wieso willst Du Dir das Leben unnötig schwer machen, wenn Du doch ein 
Gerät mit einem Webserver zur Verfügung stehen hast, auf dem Du 
problemlos eigene Funktionen in Software umsetzen kannst, die auch UDP 
und sogar nackte Ethernet-Frames verwenden?

Genau das ist das, was ich als "seine Kumpels entdecken" bezeichnete.

[Markus K. (markus-)]

Thomas F. schrieb:
> es geht mir jetzt um mehrere Devices im
> LAN und wie man diese einfach und sicher identifizieren kann. Und das
> ganze nur mit dem Webbrowser, was die Sache auf Javascript reduziert
> gehe ich von aus.

Läuft auf den ESP32 Dein Code? Wenn nicht, dann bräuchtest Du wenigstens 
noch ein extra-Gerät, dass die Namen der anderen Geräte einsammelt.

Wenn Du die ESP32 unter Kontrolle hast, dann könnten einfach alle mit 
mdns eine Liste der Lautsprecher erstellen, der Anwender verbindet sich 
dann mit  dem Webserver eines Lautsprechers (Name steht hintendrauf) und 
dieser kennt dann alle seine Kollegen.

Evtl. wäre es auch machbar, dass die Lautsprecher einen Master wählen 
und dieser dann unter einem festen Namen erreichbar ist.

Zur IP-Adressvergabe:
Wenn es einen DHCP Server gibt, dann ist alles gut.
Wenn es keinen gibt, dann können die Geräte mit Zeroconf/AutoIP ohne 
einen Server eine ausmachen. Das funktioniert unter Windows bei IPv4 
aber nur, wenn auf dem Netzwerkinterface DHCP eingestellt ist. Wenn das 
nicht der Fall ist, sondern eine statische Adresse eingestellt wurde, 
dann kann es dank mdns zwar die Namen auflösen, aber dann nicht 
connecten.
Mit IPv6 könnte es vielleicht gehen, aber da fehlt mir die Erfahrung.

[Ein T. (ein_typ)]

Nick schrieb:
> Danke. Ich verstehe auch nach wie vor nicht, woher das Dashboard kommen
> soll, wenn nicht von einem Webserver irgendwo. Das Dashboard kommt ja
> nicht aus heiterem Himmel in den Browser.

Das bringt der Storch.

[Thomas F. (tf1973)]

Nick schrieb:
> Thomas F. schrieb:
>> Davon ausgehend, das es wenigstens EINEN verbunden Webserver gibt. Sonst
>> macht das ja auch wenig Sinn :)
>
> Und wo ist das Problem daran, diesem Webserver ein Backend zu
> spendieren, das die Discovery macht (und ggfs. den Traffic proxied)? Mit
> anderen Worten: Ob da jetzt Apache läuft oder gunicorn, sollte keinen
> Unterschied machen. (Wobei mir einfällt, sogar Apache kann WSGI
> ausführen …)
>
> Insofern, setz dich bitte mal mit meinen Umsetzungsvorschlägen
> auseinander.

Apache läuft auf ESP32? Aber ja, wie das hier genannt wurde, die 
Webserver das Discovery ausführen zu lassen und dann nur noch eine Liste 
abzurufen macht Sinn.

[Harry L. (mysth)]

Thomas F. schrieb:
> eine Dashboard Anwendung im Browser soll auf
> verschiedene Webserver im LAN zugreifen können.

Die eigentlich Frage müsste doch lauten:

Warum zum Teufel Webserver?

Klingt für mich eher so, als würde der TO einfach nix anderes kennen.

Für "Mensch<->Maschine " ist ein Webserver ja prima, aber für 
"Maschine<->Maschine" ist sowas eher suboptimal, und dafür gibts 
deutlich bessere Lösungsansätze. (Bsp.: MQTT)

HomeAssistant bietet dem Noob einen recht niedrig schwelligen Einstieg 
in die Technik, und man hat damit auch schnell das gewünschte Dashboard.
HomeAssistant hat sogar ein integriertes Auto-Discovery. (via MQTT)

Läuft zwar nicht auf einem ESP32 aber ein RaspberryPi oder ein 
100€-Mini-PC von Aliexpress reicht vollkommen aus, und das braucht man 
auch nur einmal - ganz egal, wie viele Devices da sonst noch im Netz 
hängen.

[Harald K. (kirnbichler)]

Thomas F. schrieb:
> Apache läuft auf ESP32?

Natürlich nicht. Aber ein Webserver läuft da drauf, das ist bei sehr 
vielen Anwendungen mit ESP32 & Co. der Fall.

Harry L. schrieb:
> Warum zum Teufel Webserver?

Ganz einfach: Weil nur damit eine einfach zugängliche und bedienbare 
Oberfläche auf PCs, Smartphones etc. dargestellt werden kann, ohne daß 
auf diesen eigens irgendwelche Software installiert werden muss.

Deswegen enthalten fast alle Netzwerkgeräte einen Webserver.

Harry L. schrieb:
> Läuft zwar nicht auf einem ESP32 aber ein RaspberryPi oder ein
> 100€-Mini-PC von Aliexpress reicht vollkommen aus

Das wäre dann also noch ein Gerät, das nur für die Inbetriebnahme der 
hier angedachten ESP32-Geräte da noch extra dazugestellt werden muss.

Mir scheint, daß das nicht dem Ziel des Threadstarters entspricht.

[Nick (nick15)]

Thomas F. schrieb:
> Apache läuft auf ESP32? Aber ja, wie das hier genannt wurde, die
> Webserver das Discovery ausführen zu lassen und dann nur noch eine Liste
> abzurufen macht Sinn.

Ne, Apache läuft da nicht :D Ist halt irgendwas anderes.

Aber das stimmt schon, eigentlich können die ESPs das auch selbst 
machen. Ist dann ggfs. nur ein bisschen mehr Programmieraufwand. Ich 
weiß auch nicht wie gut sich das auf einem ESP32 abbilden lässt, wenn da 
auch noch deine restliche Software drauf laufen muss. Musst dann halt 
schauen, dass sich da nix beißt.

Aber dann einfach mal ausprobieren, mDNS library gibts ja und wie mein 
Python-Beispiel von oben zeigt ist das vom Prinzip her ja recht 
überschaubar. Einziger Teil der noch fehlt ist, dass die sich per mDNS 
announcen, aber das dürfte ja schnell gemacht sein.

[Ob S. (Firma: 1984now) (observer)]

Harald K. schrieb:

> Deswegen enthalten fast alle Netzwerkgeräte einen Webserver.

Ja. Der dann irgendwo oder nirgendwo zu finden ist.

Im Prinzip gibt es da zweieinhalb Konzepte, die aber allesamt Scheiße 
sind, so weit es um das Auffinden oder Zugänglichmachen des Webservers 
geht.

Variante 1: Das Device mit dem Webserver spannt ein eigenes WLAN auf. 
Sehr häufig bei ESP32-basierten Geräte anzutreffen, weil die ESP32 halt 
WiFi sowieso dabei haben. Dem DAU wird aber (im Minimum) abverlangt, 
sich mit einem anderen WLAN zu verbinden. Wa macht er aber, wenn er an 
einem Computer arbeitet, der überhaupt kein WLAN-Interface besitzt?

Variante 2.a) Feste IP in einem fest vorgegeben Netz. Dem DAU wird (im 
Minumum) zugemutet, eine weitere Adresse an seine NIC zu binden. Und 
völlig aufgeschmissen ist der DAU, wenn das vorgegeben Netz zufällig 
seinem eigenen LAN entspricht und die Adresse des Webservers bereits 
durch ein anderes Gerät belgt ist.

Variante 2.b) Adresse des Webservers wird aus einem vorhandenen 
DHCP-Server bezogen. Dann braucht der DAU nix umkonfigurieren, weiss 
aber auch die Adresse des Webservers nicht, den er erreichen möchte.

Also irgendwie sind alle diese Ansätze große Scheiße. Was beweist: 
Webbrowser als Allheilmittel sind große Scheiße.

[Nemopuk (nemopuk)]

Ob S. schrieb:
> Adresse des Webservers wird aus einem vorhandenen
> DHCP-Server bezogen.

Und die könnte man über ein kleines Display anzeigen.

Bei WLAN hilft das aber wenig, weil man ja vorher das Netz auswählen und 
Passort eingeben muss. Weil: WPS funktioniert ja auch wieder nur mit 
Glück.

[Harald K. (kirnbichler)]

Ob S. schrieb:
> Was beweist:
> Webbrowser als Allheilmittel sind große Scheiße.

Klar, denn natürlich käme niemand auf die Idee, vielleich einfach sein 
blödes Smartphone zu zücken ...

Und deswegen ist alles andere auch große Scheiße.

Wie wäre es, wenn Du einfach Gurken verkaufen würdest? Die brauchen all' 
den Kram nicht.

[Markus K. (markus-)]

Ob S. schrieb:

> Variante 2.b) Adresse des Webservers wird aus einem vorhandenen
> DHCP-Server bezogen. Dann braucht der DAU nix umkonfigurieren, weiss
> aber auch die Adresse des Webservers nicht, den er erreichen möchte.

Meist ist beim DHCP auch noch ein Nameserver dabei, bei dem sich die 
Geräte registrieren können. Damit kann man sie auch per Namen 
ansprechen.

[Ob S. (Firma: 1984now) (observer)]

Nemopuk schrieb:

> Und die könnte man über ein kleines Display anzeigen.

Ja sicher. So das Zielgerät denn überhaupt eines hat und dieses genügend 
groß zur Anzeige einer IP-Adresse ist.

Display findet man zwar schon recht häufig bei Temperatursensoren. Aber 
dann oft nur mit 3,5 oder 4 Digits.

[Ob S. (Firma: 1984now) (observer)]

Markus K. schrieb:
> Ob S. schrieb:
>
>> Variante 2.b) Adresse des Webservers wird aus einem vorhandenen
>> DHCP-Server bezogen. Dann braucht der DAU nix umkonfigurieren, weiss
>> aber auch die Adresse des Webservers nicht, den er erreichen möchte.
>
> Meist ist beim DHCP auch noch ein Nameserver dabei, bei dem sich die
> Geräte registrieren können. Damit kann man sie auch per Namen
> ansprechen.

Namenskollision vorprogrammiert. Und außerdem: längst nicht jeder 
DNS-Server erlaubt jedem Client, sich dort zu registrieren.

[Mario M. (thelonging)]

Die Geräte registrieren sich auch nicht beim DNS-Server, sondern 
normalerweise übergibt der DHCP-Server den Hostnamen und die IP ans DNS.

[Ob S. (Firma: 1984now) (observer)]

Mario M. schrieb:

> Die Geräte registrieren sich auch nicht beim DNS-Server, sondern
> normalerweise übergibt der DHCP-Server den Hostnamen und die IP ans DNS.

Ja klar. Aber der DNS-Server kann das ablehnen. Der fällt also die 
Entscheidung, nicht der DHCP-Server.

[Nick (nick15)]

Das geht doch in 99% der (Consumer-)Fällen Hand in Hand, nämlich über 
dnsmasq. Außerdem: Wäre ja extrem dumm so einen Automatismus von Hand 
einzubauen und dem DNS-Server dann die Möglichkeit geben, das 
routinemäßig abzulehnen (vor allem auf welcher Basis?!). Wie dumm

[Markus K. (markus-)]

Ob S. schrieb:
> Markus K. schrieb:
>> Ob S. schrieb:
>>
>>> Variante 2.b) Adresse des Webservers wird aus einem vorhandenen
>>> DHCP-Server bezogen. Dann braucht der DAU nix umkonfigurieren, weiss
>>> aber auch die Adresse des Webservers nicht, den er erreichen möchte.
>>
>> Meist ist beim DHCP auch noch ein Nameserver dabei, bei dem sich die
>> Geräte registrieren können. Damit kann man sie auch per Namen
>> ansprechen.
>
> Namenskollision vorprogrammiert.

Da nimmt man bei Massenware Namen mit einer Zufallszahl hintendran und 
bei Kleinserien einfach fortlaufende Nummern. Die Lautsprechergeschichte 
hört sich eher nach letzterem an.

> Und außerdem: längst nicht jeder
> DNS-Server erlaubt jedem Client, sich dort zu registrieren.

Privat machen das wohl die meisten Router und bei der Arbeit darf man 
bei uns keine fremden Geräte ans Firmennetz anschließen (Whitelisting 
der MAC-Adressen). Da stellt sich jetzt die Frage, ob die IT von den 
typischen Lautsprecherkunden eher wie ein privates Setup oder wie eine 
Konzern-IT aussieht.

[Alexander (alxc)]

Wie hat es Thomas F. denn jetzt gelöst?

[Ob S. (Firma: 1984now) (observer)]

Alexander schrieb:
> Wie hat es Thomas F. denn jetzt gelöst?

Vermutlich garnicht. Wenn man Web-Gedöhns kennt und keine Ahnung von 
Netzwerkprotokollen hat, ist es wohl auch unmöglich, eine halbwegs (*) 
brauchbare Lösung zu finden.

(*) Für restriktiv administrierte Netze mit aktiver threat protection 
ist es natürlich auch nicht möglich, eine auch nur halbwegs brauchbare 
Lösung zu finden.

Genau deswegen gibt es diese Schutzvorrichtungen schließlich. Die sollen 
genau das unmöglich machen, was der TO will und braucht, um seine 
Vorstellungen umzusetzen.

Aber für die "normalen" Consumer-Netze geht das schon zu machen. Aber 
eben nicht rein mit Web-Gedöhns. Jedenfalls nicht im Sinne von "so gut 
wie irgend möglich".

[Harald K. (kirnbichler)]

Der für alle Normalanwender auch im Heimbereich problemlos gangbare Weg 
wurde bereits angesprochen ... und natürlich von unserem C-Hater in 
Bausch und Bogen verdammt, weil das in seinem Hassbunker nicht zulässig 
sein darf.

(der einzurichtende Controller spannt ein WLAN auf, mit dem man sich mit 
seinem Smartphone verbindet, darüber sieht man die Weboberfläche zur 
Konfiguration. Geht, funktioniert problemlos. Wenn der Krempel dann mit 
einem totalvernagelten LAN verbunden werden soll, gehts natürlich nicht 
weiter, aber das tut es dann sowieso nicht, denn deswegen ist das LAN ja 
totalvernagelt. In allen anderen Fällen aber kann, wie schon erwähnt, 
der Controller, mit dessen WLAN das Smartphone verbunden ist, über 
seinen Ethernetport alle nötigen Schritte unternehmen, um seine Kumpels 
finden zu können. Wenn man nicht die speziellen Scheuklappen unseres 
Spezis aufhat, dann ist das sogar so ziemlich die einzige gangbare 
Möglichkeit, die den technisch unbedarfteren Anwendern zugänglich ist)