Fortsetzung der Diskussion von In der Firmwarebäckerei:
Für 1.5.0 machen wir hier weiter, 1.5.0~71 basiert auf gluon-v2022.1.3. Let’s go!
Wie schon oben beschrieben … auch mit Version 1.5.0~71
Windows sagt leider auch „Kein Internet“
Hallo,
Wie schon oben beschrieben … auch mit Version 1.5.0~71
Windows sagt leider auch „Kein Internet“
ich habe das Verhalten hier mit der 1.4.0~74 unter Android (und bisher
einem Windows-Rechner) ebenfalls beobachtet. Geräte verbinden sich und
zeigen dann „kein Internet“ an. Werden aber als Client auf der Karte
gezeigt. Manchmal half ein Neustart des Smartphone/PC. Ich habe es
aber darauf geschoben, dass hier relativ viele Knoten untereinander
per WLAN meshen und gleichzeitig auch Internet per WAN bekommen.
Nachdem ich bei den betroffenen Knoten das Meshen per WLAN
ausgeschaltet habe, bilde ich mir ein, dass es besser geworden ist.
Viele Grüße
Andreas
Thanks, that definitely helps. Denn das hieße auch, daß es nicht auf Gluon v2022 begrenzt ist.
Ich habe das teilweise bei meinem, ähem, ›gewagt‹ angebundenen Knoten im OG beobachtet — der hängt an einem WLAN-Client, dessen (Steckdosen-)AP im Raum darunter per WDS-Strecke vom zentralen AP versorgt wird, also quasi hinter zwei ›WLAN-Kabeln‹ hängt. Meistens tut’s, aber manchmal bekommt der Androide zwar 'ne v4-IP, doch Android sagt »ohne Internet verbunden«. Habe das bislang irritiert auf zu schlechtes »Funkwetter« geschoben – siehe Anbindung –, aber dann dürfte eigentlich auch DHCP nicht tun. Werde dies nun Mal genauer beobachten, sieht mir nämlich mehr nach IP(v4-)-Weiterleitungsthema auf dem GW aus (weil DHCP ja tut).
Wenn das Gerät per WLAN eine IP-Verbindung hat, aber trotzdem „Kein Internet“ angezeigt wird, liegt das manchmal an einem fehlenden/kaputten/langsamen DNS.
Man könnte von dem Androiden mit einer „Ping-App“ versuchen „1.1.1.1“ anzupingen, oder „one.one.one.one“. Wenn ersteres klappt, letzteres aber nicht, dann liegt es nicht am Routing, sondern eher am DNS. Ausprobieren mit einer manuellen DNS-Server-Konfiguration im Android, und statt dem DNS-Server, den man per DHCP bekam, einen anderen nutzen (1.1.1.1 oder 8.8.8.8 zum Testen).
So hab ich das Problem schon einige Male gelöst als der ISP-DNS-Resolver nicht tat.
In meinem Fall probiere ich dann, per App »Ping & Net« einen traceroute zu 1.1.1.1 — der versackt dann i. d. R. schon bei Hop 1, also der GW-VM im RZ. Die NS werden mit der 10er-Mesh-IP auch vom Gateway-Smokping erfasst — aber ggf. ist es eben ein Unterschied, ob das GW die Anfrage stellt oder ein Client dahinter (IP-Forwarding und/oder Routing im Batman-Mesh).