Seit 11.7. ist mein Feinstaubsensor https://www.madavi.de/sensor/signal.php?sensor=esp8266-13957099 , der an meinem FFV Router 5c2222202b20 angebunden ist, nur noch äußerst selten fähig, die Daten an den Server http://api.luftdaten.info/ zu übermitteln. https://www.madavi.de/sensor/graph.php?sensor=esp8266-13957099-sds011
Auch bei Verbindungen mit dem Mobiltelefon oder dem Laptop über den FFV-Router "hängt" oft der Datentransport. Im Moment geht der Ping -zum Beispiel auf Google.de- recht flott, bis ich eine Webseite aufrufe, dann kommen keine Pings mehr durch, bis ich die WLAN-Verbindung reconnecte. Liegt es an meinem Router, VPN01 oder etwas völlig anderem?
TIA, Denis.
DANKE Denis, ich wollte nicht der erste sein, das Thema anspricht.
Meine Erfahrung in der letzten Zeit spiegeln deine Beobachtung.
Der Jo
Denis Mitlacher via Freifunk_info freifunk_info@freifunk-vogtland.net schrieb am Do. 19. Juli 2018 um 22:23:
Seit 11.7. ist mein Feinstaubsensor https://www.madavi.de/sensor/signal.php?sensor=esp8266-13957099 , der an meinem FFV Router 5c2222202b20 angebunden ist, nur noch äußerst selten fähig, die Daten an den Server http://api.luftdaten.info/ zu übermitteln. https://www.madavi.de/sensor/graph.php?sensor=esp8266-13957099-sds011
Auch bei Verbindungen mit dem Mobiltelefon oder dem Laptop über den FFV-Router "hängt" oft der Datentransport. Im Moment geht der Ping -zum Beispiel auf Google.de- recht flott, bis ich eine Webseite aufrufe, dann kommen keine Pings mehr durch, bis ich die WLAN-Verbindung reconnecte. Liegt es an meinem Router, VPN01 oder etwas völlig anderem?
TIA, Denis.
Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net https://mx.hateotu.de/mailman/listinfo/freifunk_info
Ich will aber mal was beitragen, ich denke es sind DNS Probleme. iPhone Client hier. Über Freifunk bekomme ich 2 DNS Server zugeteilt. 1 IPv4 und 1 ipv6.
10.204.64.1
fd01:fd59:0:1c00::1:1
Mit manuellen DNS Einstellungen kann ich einfach mal den einen oder andern raus schmeißen und so testen welcher von den beiden antwortet und Namen auflöst.
Keiner tut es bei mir.
Nehmen wir 8.8.8.8 (Google) dann geht es sehr gut und auch die Geschwindigkeit ist überraschend schnell.
Ich sage DNS selbst oder dessen Erreichbarkeit via ipv4 oder ipv6
Es grüßt der Jo
Dunkelschunkel dunkelschunkel@googlemail.com schrieb am Do. 19. Juli 2018 um 23:08:
DANKE Denis, ich wollte nicht der erste sein, das Thema anspricht.
Meine Erfahrung in der letzten Zeit spiegeln deine Beobachtung.
Der Jo
Denis Mitlacher via Freifunk_info freifunk_info@freifunk-vogtland.net schrieb am Do. 19. Juli 2018 um 22:23:
Seit 11.7. ist mein Feinstaubsensor https://www.madavi.de/sensor/signal.php?sensor=esp8266-13957099 , der an meinem FFV Router 5c2222202b20 angebunden ist, nur noch äußerst selten fähig, die Daten an den Server http://api.luftdaten.info/ zu übermitteln. https://www.madavi.de/sensor/graph.php?sensor=esp8266-13957099-sds011
Auch bei Verbindungen mit dem Mobiltelefon oder dem Laptop über den FFV-Router "hängt" oft der Datentransport. Im Moment geht der Ping -zum Beispiel auf Google.de- recht flott, bis ich eine Webseite aufrufe, dann kommen keine Pings mehr durch, bis ich die WLAN-Verbindung reconnecte. Liegt es an meinem Router, VPN01 oder etwas völlig anderem?
TIA, Denis.
Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net https://mx.hateotu.de/mailman/listinfo/freifunk_info
Ach ja, getestet in der MoritzLöscherStr22, dort steht ein Futro als GW
http://vogtland.freifunk.net/map/#!v:m;n:001999bc6254
Es grüßt der Jo
Dunkelschunkel dunkelschunkel@googlemail.com schrieb am Fr. 20. Juli 2018 um 07:17:
Ich will aber mal was beitragen, ich denke es sind DNS Probleme. iPhone Client hier. Über Freifunk bekomme ich 2 DNS Server zugeteilt. 1 IPv4 und 1 ipv6.
10.204.64.1
fd01:fd59:0:1c00::1:1
Mit manuellen DNS Einstellungen kann ich einfach mal den einen oder andern raus schmeißen und so testen welcher von den beiden antwortet und Namen auflöst.
Keiner tut es bei mir.
Nehmen wir 8.8.8.8 (Google) dann geht es sehr gut und auch die Geschwindigkeit ist überraschend schnell.
Ich sage DNS selbst oder dessen Erreichbarkeit via ipv4 oder ipv6
Es grüßt der Jo
Dunkelschunkel dunkelschunkel@googlemail.com schrieb am Do. 19. Juli 2018 um 23:08:
DANKE Denis, ich wollte nicht der erste sein, das Thema anspricht.
Meine Erfahrung in der letzten Zeit spiegeln deine Beobachtung.
Der Jo
Denis Mitlacher via Freifunk_info freifunk_info@freifunk-vogtland.net schrieb am Do. 19. Juli 2018 um 22:23:
Seit 11.7. ist mein Feinstaubsensor https://www.madavi.de/sensor/signal.php?sensor=esp8266-13957099 , der an meinem FFV Router 5c2222202b20 angebunden ist, nur noch äußerst selten fähig, die Daten an den Server http://api.luftdaten.info/ zu übermitteln. https://www.madavi.de/sensor/graph.php?sensor=esp8266-13957099-sds011
Auch bei Verbindungen mit dem Mobiltelefon oder dem Laptop über den FFV-Router "hängt" oft der Datentransport. Im Moment geht der Ping -zum Beispiel auf Google.de- recht flott, bis ich eine Webseite aufrufe, dann kommen keine Pings mehr durch, bis ich die WLAN-Verbindung reconnecte. Liegt es an meinem Router, VPN01 oder etwas völlig anderem?
TIA, Denis.
Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net https://mx.hateotu.de/mailman/listinfo/freifunk_info
On Freitag, 20. Juli 2018 07:17:02 CEST Dunkelschunkel via Freifunk_info wrote:
Ich will aber mal was beitragen, ich denke es sind DNS Probleme. iPhone Client hier. Über Freifunk bekomme ich 2 DNS Server zugeteilt. 1 IPv4 und 1 ipv6.
Wenn das der Fall ist, dann muesste der lokale DNS wieder abgeschalten werden. Dann geht auch nextnode.ffv nicht mehr.
Leider versteh ich nicht in wieweit ein Websiten-Aufruf den Ping kaputt macht.
Gruesse, Sven
Mit lokalen DNS meinst du die beiden hinterlegten IP Adressen?
Es wäre auch möglich, dass der DNS-Server bestimmte Adressen nicht auflösen kann wenn Clients Anfragen stellen.
Es grüßt der Jo
Sven Eckelmann sven@narfation.org schrieb am Fr. 20. Juli 2018 um 09:47:
On Freitag, 20. Juli 2018 07:17:02 CEST Dunkelschunkel via Freifunk_info wrote:
Ich will aber mal was beitragen, ich denke es sind DNS Probleme. iPhone Client hier. Über Freifunk bekomme ich 2 DNS Server zugeteilt. 1 IPv4
und 1
ipv6.
Wenn das der Fall ist, dann muesste der lokale DNS wieder abgeschalten werden. Dann geht auch nextnode.ffv nicht mehr.
Leider versteh ich nicht in wieweit ein Websiten-Aufruf den Ping kaputt macht.
Gruesse, Sven
On Freitag, 20. Juli 2018 10:09:30 CEST Dunkelschunkel wrote:
Mit lokalen DNS meinst du die beiden hinterlegten IP Adressen?
Nein, ich meine, dass jeder AP einen DNS Server laufen hat um nextnode.ffv aufzuloesen und alle anderen Anfragen weiterzuleiten.
Es wäre auch möglich, dass der DNS-Server bestimmte Adressen nicht auflösen kann wenn Clients Anfragen stellen.
Ich weiss leider den Grund nicht. Ich habe das DNS Zeug auf dem Server gerade mal umgangen. Bitte testet nochmal eine Runde ob das jetzt besser geht.
Das wir keine perfekte Gigabit-Verbindung bereitstellen koennen bzw. es keine perfekte Latenz hat, war halt schon vorher so. Und daran kann ich momentan wenig aendern.
Gruesse, Sven
Bin grade auf Arbeit
Sven Eckelmann sven@narfation.org schrieb am Fr. 20. Juli 2018 um 10:20:
On Freitag, 20. Juli 2018 10:09:30 CEST Dunkelschunkel wrote:
Mit lokalen DNS meinst du die beiden hinterlegten IP Adressen?
Nein, ich meine, dass jeder AP einen DNS Server laufen hat um nextnode.ffv aufzuloesen und alle anderen Anfragen weiterzuleiten.
Es wäre auch möglich, dass der DNS-Server bestimmte Adressen nicht
auflösen
kann wenn Clients Anfragen stellen.
Ich weiss leider den Grund nicht. Ich habe das DNS Zeug auf dem Server gerade mal umgangen. Bitte testet nochmal eine Runde ob das jetzt besser geht.
Das wir keine perfekte Gigabit-Verbindung bereitstellen koennen bzw. es keine perfekte Latenz hat, war halt schon vorher so. Und daran kann ich momentan wenig aendern.
Gruesse, Sven
Verhalten ist immer noch komisch. Bei manchen Knoten reicht es, wenn ich am Client das Elan richtig deaktiviere und nach einigen Augenblicken wieder aktiviere. (In den Einstellungen von iOS und nicht Kontrollzentrum) Bei anderen Knoten hilft das nicht und ich muss einen anderen DNS Server eintragen am Client.
Was wären denn die korrekten Einstellungen für DNS und Gateway?
Mit sieht es nun eher wie ein möglich DHCP bzw. Lease Problem auf Clientsite aus.
Teilweise
Dunkelschunkel dunkelschunkel@googlemail.com schrieb am Fr. 20. Juli 2018 um 10:29:
Bin grade auf Arbeit
Sven Eckelmann sven@narfation.org schrieb am Fr. 20. Juli 2018 um 10:20:
On Freitag, 20. Juli 2018 10:09:30 CEST Dunkelschunkel wrote:
Mit lokalen DNS meinst du die beiden hinterlegten IP Adressen?
Nein, ich meine, dass jeder AP einen DNS Server laufen hat um nextnode.ffv aufzuloesen und alle anderen Anfragen weiterzuleiten.
Es wäre auch möglich, dass der DNS-Server bestimmte Adressen nicht
auflösen
kann wenn Clients Anfragen stellen.
Ich weiss leider den Grund nicht. Ich habe das DNS Zeug auf dem Server gerade mal umgangen. Bitte testet nochmal eine Runde ob das jetzt besser geht.
Das wir keine perfekte Gigabit-Verbindung bereitstellen koennen bzw. es keine perfekte Latenz hat, war halt schon vorher so. Und daran kann ich momentan wenig aendern.
Gruesse, Sven
Wenn es nicht geht bekomme ich als DNS den vpn04 mit 10.204.64.1
Auf dem ist Port 53 nicht offen laut Scan. Generell braucht dieser für Scan Ergebnisse sehr lange und er findet nur Port 22 und 80.
Der jo
Dunkelschunkel dunkelschunkel@googlemail.com schrieb am Fr. 20. Juli 2018 um 11:19:
Verhalten ist immer noch komisch. Bei manchen Knoten reicht es, wenn ich am Client das Elan richtig deaktiviere und nach einigen Augenblicken wieder aktiviere. (In den Einstellungen von iOS und nicht Kontrollzentrum) Bei anderen Knoten hilft das nicht und ich muss einen anderen DNS Server eintragen am Client.
Was wären denn die korrekten Einstellungen für DNS und Gateway?
Mit sieht es nun eher wie ein möglich DHCP bzw. Lease Problem auf Clientsite aus.
Teilweise
Dunkelschunkel dunkelschunkel@googlemail.com schrieb am Fr. 20. Juli 2018 um 10:29:
Bin grade auf Arbeit
Sven Eckelmann sven@narfation.org schrieb am Fr. 20. Juli 2018 um 10:20:
On Freitag, 20. Juli 2018 10:09:30 CEST Dunkelschunkel wrote:
Mit lokalen DNS meinst du die beiden hinterlegten IP Adressen?
Nein, ich meine, dass jeder AP einen DNS Server laufen hat um nextnode.ffv aufzuloesen und alle anderen Anfragen weiterzuleiten.
Es wäre auch möglich, dass der DNS-Server bestimmte Adressen nicht
auflösen
kann wenn Clients Anfragen stellen.
Ich weiss leider den Grund nicht. Ich habe das DNS Zeug auf dem Server gerade mal umgangen. Bitte testet nochmal eine Runde ob das jetzt besser geht.
Das wir keine perfekte Gigabit-Verbindung bereitstellen koennen bzw. es keine perfekte Latenz hat, war halt schon vorher so. Und daran kann ich momentan wenig aendern.
Gruesse, Sven
Am 20. Juli 2018 11:35:57 MESZ schrieb Dunkelschunkel dunkelschunkel@googlemail.com:
Wenn es nicht geht bekomme ich als DNS den vpn04 mit 10.204.64.1
Auf dem ist Port 53 nicht offen laut Scan. Generell braucht dieser für Scan Ergebnisse sehr lange und er findet nur Port 22 und 80.
War das ein UDP Port-Scan?
10.0.204.64.1 ist der AP auf dem du verbunden bist.
Gruesse, Sven
Aha, Danke, deswegen hatte ich nach den IP Adressen gefragt. Welche bekommt der Client und welche Server sind das.
Kann dir leider gerade nicht sagen, ob das Udp war. Bin auf mobil unter wegs
Der jo
Sven Eckelmann sven@narfation.org schrieb am Fr. 20. Juli 2018 um 12:57:
Am 20. Juli 2018 11:35:57 MESZ schrieb Dunkelschunkel < dunkelschunkel@googlemail.com>:
Wenn es nicht geht bekomme ich als DNS den vpn04 mit 10.204.64.1
Auf dem ist Port 53 nicht offen laut Scan. Generell braucht dieser für Scan Ergebnisse sehr lange und er findet nur Port 22 und 80.
War das ein UDP Port-Scan?
10.0.204.64.1 ist der AP auf dem du verbunden bist.
Gruesse, Sven
Grade wieder getestet in der Zwickauer Straße
Mi 10.204.64.1 als DNS geht kein Seitenaufruf bzw. Seeeehr selten. Mit manuellem DNS Server auf dem Client sehr schnell. Selbst wenn ich zb 10.204.64.6 (vpn05) als DNS Server an Client hinterlege und nicht Google
Dunkelschunkel dunkelschunkel@googlemail.com schrieb am Fr. 20. Juli 2018 um 13:25:
Aha, Danke, deswegen hatte ich nach den IP Adressen gefragt. Welche bekommt der Client und welche Server sind das.
Kann dir leider gerade nicht sagen, ob das Udp war. Bin auf mobil unter wegs
Der jo
Sven Eckelmann sven@narfation.org schrieb am Fr. 20. Juli 2018 um 12:57:
Am 20. Juli 2018 11:35:57 MESZ schrieb Dunkelschunkel < dunkelschunkel@googlemail.com>:
Wenn es nicht geht bekomme ich als DNS den vpn04 mit 10.204.64.1
Auf dem ist Port 53 nicht offen laut Scan. Generell braucht dieser für Scan Ergebnisse sehr lange und er findet nur Port 22 und 80.
War das ein UDP Port-Scan?
10.0.204.64.1 ist der AP auf dem du verbunden bist.
Gruesse, Sven
@Sven, ich hoffe grade echt ganz doll, dass ich dich grade nicht irgendwie auf einen Holzweg führe. Das könnte ich sicher nicht wieder gut machen
Der jp
Dunkelschunkel dunkelschunkel@googlemail.com schrieb am Fr. 20. Juli 2018 um 13:33:
Grade wieder getestet in der Zwickauer Straße
Mi 10.204.64.1 als DNS geht kein Seitenaufruf bzw. Seeeehr selten. Mit manuellem DNS Server auf dem Client sehr schnell. Selbst wenn ich zb 10.204.64.6 (vpn05) als DNS Server an Client hinterlege und nicht Google
Dunkelschunkel dunkelschunkel@googlemail.com schrieb am Fr. 20. Juli 2018 um 13:25:
Aha, Danke, deswegen hatte ich nach den IP Adressen gefragt. Welche bekommt der Client und welche Server sind das.
Kann dir leider gerade nicht sagen, ob das Udp war. Bin auf mobil unter wegs
Der jo
Sven Eckelmann sven@narfation.org schrieb am Fr. 20. Juli 2018 um 12:57:
Am 20. Juli 2018 11:35:57 MESZ schrieb Dunkelschunkel < dunkelschunkel@googlemail.com>:
Wenn es nicht geht bekomme ich als DNS den vpn04 mit 10.204.64.1
Auf dem ist Port 53 nicht offen laut Scan. Generell braucht dieser für Scan Ergebnisse sehr lange und er findet nur Port 22 und 80.
War das ein UDP Port-Scan?
10.0.204.64.1 ist der AP auf dem du verbunden bist.
Gruesse, Sven
On Freitag, 20. Juli 2018 14:07:51 CEST Dunkelschunkel wrote:
@Sven, ich hoffe grade echt ganz doll, dass ich dich grade nicht irgendwie auf einen Holzweg führe. Das könnte ich sicher nicht wieder gut machen
Wie sieht es jetzt aus? Habe hier gerade einen Freifunk-Knoten aufgebaut und es ging ziemlich gut. Ueber IPv6 und IPv4.
Momentan wird ueber DHCP auch ein externer DNS-Server eingetragen.
Gruesse, Sven
Kleines Update von meiner Seite.
Mit dem externen DNS Server geht es gut. Bin vor dem Haus aus dem Auto gestiegen und hatte Freifunk und konnte gut surfen.
Es würde sicher genau so gut laufen, wenn einer der VPN0(x) Server auf denen DNS läuft als DNS Server für die Clients hinterlegt wird. Oder gleich die ip des jeweils gewählten GW als DNS Server zwecks Verteilung der Anfragen.
Komisch nur, dass es mit der IP des jeweils lokalen Routers nicht zuverlässig läuft.
Wo ist da der Knick drinnen?
Der jo
Sven Eckelmann sven@narfation.org schrieb am Fr. 20. Juli 2018 um 18:08:
On Freitag, 20. Juli 2018 14:07:51 CEST Dunkelschunkel wrote:
@Sven, ich hoffe grade echt ganz doll, dass ich dich grade nicht
irgendwie
auf einen Holzweg führe. Das könnte ich sicher nicht wieder gut machen
Wie sieht es jetzt aus? Habe hier gerade einen Freifunk-Knoten aufgebaut und es ging ziemlich gut. Ueber IPv6 und IPv4.
Momentan wird ueber DHCP auch ein externer DNS-Server eingetragen.
Gruesse, Sven
On Freitag, 20. Juli 2018 20:57:01 CEST Dunkelschunkel wrote: [...]
Komisch nur, dass es mit der IP des jeweils lokalen Routers nicht zuverlässig läuft.
Wo ist da der Knick drinnen?
Siehe https://github.com/freifunk-gluon/gluon/pull/1489 und die weiteren verlinkten PRs + Ticket.
Gruesse, Sven
Da weiß ich was du am Wochenende gemacht hast.
Ich ziehe meinen Hut.
Der Johannes
Sven Eckelmann sven@narfation.org schrieb am So. 22. Juli 2018 um 17:46:
On Freitag, 20. Juli 2018 20:57:01 CEST Dunkelschunkel wrote: [...]
Komisch nur, dass es mit der IP des jeweils lokalen Routers nicht zuverlässig läuft.
Wo ist da der Knick drinnen?
Siehe https://github.com/freifunk-gluon/gluon/pull/1489 und die weiteren verlinkten PRs + Ticket.
Gruesse, Sven
Hallo Sven,
Da kann ich mich Johannes nur anschließen - Chapeau! Und vielen Dank für deine Arbeit!
VG,
André
Outlook for Android herunterladen
On Sun, Jul 22, 2018 at 5:47 PM +0200, "Sven Eckelmann via Freifunk_info" freifunk_info@freifunk-vogtland.net wrote:
On Freitag, 20. Juli 2018 20:57:01 CEST Dunkelschunkel wrote: [...]
Komisch nur, dass es mit der IP des jeweils lokalen Routers nicht zuverlässig läuft.
Wo ist da der Knick drinnen?
Siehe https://github.com/freifunk-gluon/gluon/pull/1489 und die weiteren verlinkten PRs + Ticket.
Gruesse, Sven
Dito.
Vielen Dank.
Pascal.
Von: Freifunk_info freifunk_info-bounces@freifunk-vogtland.net Im Auftrag von andre.fiedler--- via Freifunk_info Gesendet: Sonntag, 22. Juli 2018 21:11 An: info@freifunk-vogtland.net Cc: andre.fiedler@me.com Betreff: Re: [Freifunk_info] schlechte Internet-Verbindung bei guter WLAN-Verbindung
Hallo Sven,
Da kann ich mich Johannes nur anschließen - Chapeau! Und vielen Dank für deine Arbeit!
VG,
André
Outlook for Android https://aka.ms/ghei36 herunterladen
On Sun, Jul 22, 2018 at 5:47 PM +0200, "Sven Eckelmann via Freifunk_info" <freifunk_info@freifunk-vogtland.net mailto:freifunk_info@freifunk-vogtland.net > wrote:
On Freitag, 20. Juli 2018 20:57:01 CEST Dunkelschunkel wrote: [...]
Komisch nur, dass es mit der IP des jeweils lokalen Routers nicht zuverlässig läuft.
Wo ist da der Knick drinnen?
Siehe https://github.com/freifunk-gluon/gluon/pull/1489 und die weiteren verlinkten PRs + Ticket.
Gruesse, Sven
Juhu! Sieht sehr viel besser aus, aber erst nach einem Neustart des Routers. Der Feinstaubsensor kann nun wieder Daten ablegen.
Dankeschön! Wenn wir uns mal wieder treffen, erinnere mich daran, dass ich Dir was ausgebe. :)
Am 20.07.2018 um 18:08 schrieb Sven Eckelmann via Freifunk_info:
On Freitag, 20. Juli 2018 14:07:51 CEST Dunkelschunkel wrote:
@Sven, ich hoffe grade echt ganz doll, dass ich dich grade nicht irgendwie auf einen Holzweg führe. Das könnte ich sicher nicht wieder gut machen
Wie sieht es jetzt aus? Habe hier gerade einen Freifunk-Knoten aufgebaut und es ging ziemlich gut. Ueber IPv6 und IPv4.
Momentan wird ueber DHCP auch ein externer DNS-Server eingetragen.
Gruesse, Sven
Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net https://mx.hateotu.de/mailman/listinfo/freifunk_info
Hab es auch gerade getestet, einmal in Lauterbach und nun bei mir: So keine Veränderung. Aber nach einem Neustart des FFV-Routers und ist FFV zumindest am Laptop und Mobilephone hier wie dort wieder benutzbar, aber noch langsam beim Aufruf der Webseiten. Nun geht auch PING und Webseitenaufrufen wieder :)
Im Anhang habe ich eine Netzwerkanalyse der Webseite, mit der mein Feinstaubsensor verbunden sein muss zuerst mit FFV und dann mit meinem lokalen WLAN (gleiches Gerät) durchgeführt. Für mich deutet das auch auf ein DNS-Problem hin.
Am 20.07.2018 um 09:47 schrieb Sven Eckelmann via Freifunk_info:
On Freitag, 20. Juli 2018 07:17:02 CEST Dunkelschunkel via Freifunk_info wrote:
Ich will aber mal was beitragen, ich denke es sind DNS Probleme. iPhone Client hier. Über Freifunk bekomme ich 2 DNS Server zugeteilt. 1 IPv4 und 1 ipv6.
Wenn das der Fall ist, dann muesste der lokale DNS wieder abgeschalten werden. Dann geht auch nextnode.ffv nicht mehr.
Leider versteh ich nicht in wieweit ein Websiten-Aufruf den Ping kaputt macht.
Gruesse, Sven
Genau das gleiche Phänomen hatte ich auch. Mein Sensor hängt jetzt an meinem privaten WLAN und kann auch wieder Daten senden. Leider kann ich aufgrund von Zeitmangel nicht analysieren woran es liegt.
VG, André
Am 19. Juli 2018 um 22:23 schrieb Denis Mitlacher via Freifunk_info freifunk_info@freifunk-vogtland.net:
Seit 11.7. ist mein Feinstaubsensor https://www.madavi.de/sensor/signal.php?sensor=esp8266-13957099 , der an meinem FFV Router 5c2222202b20 angebunden ist, nur noch äußerst selten fähig, die Daten an den Server http://api.luftdaten.info/ zu übermitteln. https://www.madavi.de/sensor/graph.php?sensor=esp8266-13957099-sds011
Auch bei Verbindungen mit dem Mobiltelefon oder dem Laptop über den FFV-Router "hängt" oft der Datentransport. Im Moment geht der Ping -zum Beispiel auf Google.de- recht flott, bis ich eine Webseite aufrufe, dann kommen keine Pings mehr durch, bis ich die WLAN-Verbindung reconnecte. Liegt es an meinem Router, VPN01 oder etwas völlig anderem?
TIA, Denis.
_______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net https://mx.hateotu.de/mailman/listinfo/freifunk_info
Hier sieht man, dass es am 12.07. los ging ... am 18.07. habe ich das Netzwerk gewechselt:
VG, André
Am 20. Juli 2018 um 09:11 schrieb André Fiedler via Freifunk_info freifunk_info@freifunk-vogtland.net:
Genau das gleiche Phänomen hatte ich auch. Mein Sensor hängt jetzt an meinem privaten WLAN und kann auch wieder Daten senden. Leider kann ich aufgrund von Zeitmangel nicht analysieren woran es liegt.
VG, André
Am 19. Juli 2018 um 22:23 schrieb Denis Mitlacher via Freifunk_info freifunk_info@freifunk-vogtland.net:
Seit 11.7. ist mein Feinstaubsensor https://www.madavi.de/sensor/signal.php?sensor=esp8266-13957099 , der an meinem FFV Router 5c2222202b20 angebunden ist, nur noch äußerst selten fähig, die Daten an den Server http://api.luftdaten.info/ zu übermitteln. https://www.madavi.de/sensor/graph.php?sensor=esp8266-13957099-sds011
Auch bei Verbindungen mit dem Mobiltelefon oder dem Laptop über den FFV-Router "hängt" oft der Datentransport. Im Moment geht der Ping -zum Beispiel auf Google.de- recht flott, bis ich eine Webseite aufrufe, dann kommen keine Pings mehr durch, bis ich die WLAN-Verbindung reconnecte. Liegt es an meinem Router, VPN01 oder etwas völlig anderem?
TIA, Denis.
_______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net https://mx.hateotu.de/mailman/listinfo/freifunk_info _______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net https://mx.hateotu.de/mailman/listinfo/freifunk_info
-
andre.fiedler＠me.com -
André Fiedler
-
Denis Mitlacher -
Dunkelschunkel -
P. Wettin -
Sven Eckelmann