Wer heute zum Treffen kommen wollte, dem sei gesagt, wir machen einen Grill an. ;-) Bis 18Uhr c ya :-) -- Viele Grüße Carsten carsitux+ffp@jitmail.de ------------------------------------------------------------------------ Web <https://blog.freifunk-potsdam.de/> | Twitter <https://twitter.com/FreifunkPotsdam> | Facebook <https://www.facebook.com/freifunkpotsdam/> FF-Mail: info@freifunk-potsdam.de <sendto:%20info@freifunk-potsdam.de> Freifunk Potsdam Logo <https://blog.freifunk-potsdam.de/>
Seit mindestens gestern sehe ich bei einer CPE, das nix mehr durchs VPN kommt. Das Gerät hängt normal am LAN, ist erreichbar, aber durchs FFVPN tröpfeln die Bytes nur. Seht Ihr anderswo ähnliches? Ich sehe auch in Grafana, dass der Netztwerk- Traffic im Uferwerk in den letzten Tagen ziemlich eingebrochen ist https:// monitor.freifunk-potsdam.de/grafana/dashboard/db/loc-uferwerk-werder?orgId=2 Ich würde ja gerne die Uplinks alle auf Hedy mit No-Tunnel umrüsten, aber meine bisherigen Erfahrungen damit waren teilweise ziemlich problematisch, und für CPEs scheint es noch kein offizielles Hedy zu geben.. Ciao, Johannes
Hallo, laut Berliner ML [1] sind vpn03a und vpn03e nicht erreichbar. Dadurch wird jetzt die Last auf die übrigen VPN-Server verteilt und das kann dann die Performanceeinbrüche erklären. [1] https://lists.berlin.freifunk.net/pipermail/berlin/2018-March/037249.html Grüße Hannes Am 14.03.2018 um 15:31 schrieb Johannes Rohr:
Seit mindestens gestern sehe ich bei einer CPE, das nix mehr durchs VPN kommt. Das Gerät hängt normal am LAN, ist erreichbar, aber durchs FFVPN tröpfeln die Bytes nur.
Seht Ihr anderswo ähnliches? Ich sehe auch in Grafana, dass der Netztwerk- Traffic im Uferwerk in den letzten Tagen ziemlich eingebrochen ist https:// monitor.freifunk-potsdam.de/grafana/dashboard/db/loc-uferwerk-werder?orgId=2
Ich würde ja gerne die Uplinks alle auf Hedy mit No-Tunnel umrüsten, aber meine bisherigen Erfahrungen damit waren teilweise ziemlich problematisch, und für CPEs scheint es noch kein offizielles Hedy zu geben..
Ciao,
Johannes _______________________________________________ Users mailing list Users@lists.freifunk-potsdam.de https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
Hi,
für CPEs scheint es noch kein offizielles Hedy zu geben..
Ich denke dazu folgendes: Der build Bot hat das vielleicht noch nicht gebaut. Aber: OpenWRT/LEDE funktionieren für die CPE210. Das heißt, dass Hedy-Images ohne Risiko, dass die Router unbrauchbar werden, verwendet werden können. Zusätzlich gibt es eine Anleitung, wie man die Software selber baut. Damit, denke ich, kann man die Software für die CPE210 auf dem Hedy-1.0.0-Branch selbst bauen. https://github.com/freifunk-berlin/firmware/blob/v1.0.0/README.md Viele Grüße, Nicco On 03/14/2018 04:12 PM, Hannes Fuchs wrote:
Hallo,
laut Berliner ML [1] sind vpn03a und vpn03e nicht erreichbar. Dadurch wird jetzt die Last auf die übrigen VPN-Server verteilt und das kann dann die Performanceeinbrüche erklären.
[1] https://lists.berlin.freifunk.net/pipermail/berlin/2018-March/037249.html
Grüße Hannes
Am 14.03.2018 um 15:31 schrieb Johannes Rohr:
Seit mindestens gestern sehe ich bei einer CPE, das nix mehr durchs VPN kommt. Das Gerät hängt normal am LAN, ist erreichbar, aber durchs FFVPN tröpfeln die Bytes nur.
Seht Ihr anderswo ähnliches? Ich sehe auch in Grafana, dass der Netztwerk- Traffic im Uferwerk in den letzten Tagen ziemlich eingebrochen ist https:// monitor.freifunk-potsdam.de/grafana/dashboard/db/loc-uferwerk-werder?orgId=2
Ich würde ja gerne die Uplinks alle auf Hedy mit No-Tunnel umrüsten, aber meine bisherigen Erfahrungen damit waren teilweise ziemlich problematisch, und für CPEs scheint es noch kein offizielles Hedy zu geben..
Ciao,
Johannes _______________________________________________ Users mailing list Users@lists.freifunk-potsdam.de https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@lists.freifunk-potsdam.de https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
Am 14.03.2018 um 16:33 schrieb Nicco Kunzmann (gmx):
Hi,
für CPEs scheint es noch kein offizielles Hedy zu geben..
Wird langsam OT... Ist doch alles da [1][2]: - hedy-1.0.0-cpe210-220-factory.bin - hedy-1.0.0-cpe210-220-sysupgrade.bin - hedy-1.0.0-cpe510-520-factory.bin - hedy-1.0.0-cpe510-520-sysupgrade.bin Für CPE210 V2 sollte unstable build >= 623 [3] funktionieren. Wer klickfaul ist kann gerne die angepassten builds [4] von mir testen: - SSID angepasst - olsrd defaults: etx_ff -> etx_ffeth (kommt noch ein vernünftiger Patch upstream) - potsdam community als default [1] http://buildbot.berlin.freifunk.net/buildbot/stable/1.0.0/ar71xx-generic/def... [2] http://buildbot.berlin.freifunk.net/buildbot/stable/1.0.0/ar71xx-generic/vpn... [3] http://buildbot.berlin.freifunk.net/buildbot/unstable/ar71xx-generic/ [4] https://dev.0xef.de/ffp/firmware/stable/1.0.0-ffp/ar71xx-generic/ Grüße Hannes
Ich denke dazu folgendes: Der build Bot hat das vielleicht noch nicht gebaut. Aber: OpenWRT/LEDE funktionieren für die CPE210. Das heißt, dass Hedy-Images ohne Risiko, dass die Router unbrauchbar werden, verwendet werden können. Zusätzlich gibt es eine Anleitung, wie man die Software selber baut. Damit, denke ich, kann man die Software für die CPE210 auf dem Hedy-1.0.0-Branch selbst bauen. https://github.com/freifunk-berlin/firmware/blob/v1.0.0/README.md
Viele Grüße, Nicco
On 03/14/2018 04:12 PM, Hannes Fuchs wrote:
Hallo,
laut Berliner ML [1] sind vpn03a und vpn03e nicht erreichbar. Dadurch wird jetzt die Last auf die übrigen VPN-Server verteilt und das kann dann die Performanceeinbrüche erklären.
[1] https://lists.berlin.freifunk.net/pipermail/berlin/2018-March/037249.html
Grüße Hannes
Am 14.03.2018 um 15:31 schrieb Johannes Rohr:
Seit mindestens gestern sehe ich bei einer CPE, das nix mehr durchs VPN kommt. Das Gerät hängt normal am LAN, ist erreichbar, aber durchs FFVPN tröpfeln die Bytes nur.
Seht Ihr anderswo ähnliches? Ich sehe auch in Grafana, dass der Netztwerk- Traffic im Uferwerk in den letzten Tagen ziemlich eingebrochen ist https:// monitor.freifunk-potsdam.de/grafana/dashboard/db/loc-uferwerk-werder?orgId=2
Ich würde ja gerne die Uplinks alle auf Hedy mit No-Tunnel umrüsten, aber meine bisherigen Erfahrungen damit waren teilweise ziemlich problematisch, und für CPEs scheint es noch kein offizielles Hedy zu geben..
Ciao,
Johannes _______________________________________________ Users mailing list Users@lists.freifunk-potsdam.de https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@lists.freifunk-potsdam.de https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@lists.freifunk-potsdam.de https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
Schönen Dank für die Hinweise. Gerade mit einer CPE probiert. Das war ein längerer Kampf, dessen Ergebnis genauso besch$$$en war, wie meine Versuche mit einer Glinet. Nach Ersteinrichtung geht gar nichts mehr. Man kommt zwar noch auf das Gerät drauf, aber von dort aus geht nix, man kann das Default-Gateway nicht einmal anpingen, geschweige denn Namen auflösen etc. Hm, hat jemand von Euch die No-Tunnel-Variante auf einer CPE im erfolgreichen Einsatz? Johannes Am Mittwoch, 14. März 2018, 16:48:33 CET schrieb Hannes Fuchs:
Am 14.03.2018 um 16:33 schrieb Nicco Kunzmann (gmx):
Hi,
für CPEs scheint es noch kein offizielles Hedy zu geben..
Wird langsam OT... Ist doch alles da [1][2]: - hedy-1.0.0-cpe210-220-factory.bin - hedy-1.0.0-cpe210-220-sysupgrade.bin - hedy-1.0.0-cpe510-520-factory.bin - hedy-1.0.0-cpe510-520-sysupgrade.bin
Für CPE210 V2 sollte unstable build >= 623 [3] funktionieren.
Wer klickfaul ist kann gerne die angepassten builds [4] von mir testen: - SSID angepasst - olsrd defaults: etx_ff -> etx_ffeth (kommt noch ein vernünftiger Patch upstream) - potsdam community als default
[1] http://buildbot.berlin.freifunk.net/buildbot/stable/1.0.0/ar71xx-generic/def ault/ [2] http://buildbot.berlin.freifunk.net/buildbot/stable/1.0.0/ar71xx-generic/vpn 03/ [3] http://buildbot.berlin.freifunk.net/buildbot/unstable/ar71xx-generic/ [4] https://dev.0xef.de/ffp/firmware/stable/1.0.0-ffp/ar71xx-generic/
Grüße Hannes
Ich denke dazu folgendes: Der build Bot hat das vielleicht noch nicht gebaut. Aber: OpenWRT/LEDE funktionieren für die CPE210. Das heißt, dass Hedy-Images ohne Risiko, dass die Router unbrauchbar werden, verwendet werden können. Zusätzlich gibt es eine Anleitung, wie man die Software selber baut. Damit, denke ich, kann man die Software für die CPE210 auf dem Hedy-1.0.0-Branch selbst bauen. https://github.com/freifunk-berlin/firmware/blob/v1.0.0/README.md
Viele Grüße, Nicco
On 03/14/2018 04:12 PM, Hannes Fuchs wrote:
Hallo,
laut Berliner ML [1] sind vpn03a und vpn03e nicht erreichbar. Dadurch wird jetzt die Last auf die übrigen VPN-Server verteilt und das kann dann die Performanceeinbrüche erklären.
[1] https://lists.berlin.freifunk.net/pipermail/berlin/2018-March/037249.html
Grüße Hannes
Am 14.03.2018 um 15:31 schrieb Johannes Rohr:
Seit mindestens gestern sehe ich bei einer CPE, das nix mehr durchs VPN kommt. Das Gerät hängt normal am LAN, ist erreichbar, aber durchs FFVPN tröpfeln die Bytes nur.
Seht Ihr anderswo ähnliches? Ich sehe auch in Grafana, dass der Netztwerk- Traffic im Uferwerk in den letzten Tagen ziemlich eingebrochen ist https:// monitor.freifunk-potsdam.de/grafana/dashboard/db/loc-uferwerk-werder?org Id=2
Ich würde ja gerne die Uplinks alle auf Hedy mit No-Tunnel umrüsten, aber meine bisherigen Erfahrungen damit waren teilweise ziemlich problematisch, und für CPEs scheint es noch kein offizielles Hedy zu geben..
Ciao,
Johannes _______________________________________________ Users mailing list Users@lists.freifunk-potsdam.de https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@lists.freifunk-potsdam.de https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@lists.freifunk-potsdam.de https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
Am 14.03.2018 um 23:49 schrieb Johannes Rohr:
Schönen Dank für die Hinweise. Gerade mit einer CPE probiert. Das war ein längerer Kampf, dessen Ergebnis genauso besch$$$en war, wie meine Versuche mit einer Glinet. Nach Ersteinrichtung geht gar nichts mehr. Man kommt zwar noch auf das Gerät drauf, aber von dort aus geht nix, man kann das Default-Gateway nicht einmal anpingen, geschweige denn Namen auflösen etc.
Also ich kann deine Probleme nicht reproduzieren. Die Images funktionieren soweit auf einer CPE210 v1.1 und einem GL-AR150. Bei dem GL-AR150 hat lediglich das Zurückspielen der Konfiguration nicht sauber funktioniert. Den musste ich dann reseten und neu konfigurieren. Egal ob jetzt mit vpn (vpn03) oder ohne (default). Die von die genannten Probleme sind mir noch nicht begegnet. Bisher hatte Roaming rumgezickt, aber nach ein-zwei reboots hat es dann geklappt. Das müssten wir uns dann noch mal genauer ansehen. Gehst du auch richtig vor?: - Konfiguration sichern - Upgrade *ohne* Haken bei "Konfiguration beibehalten" - Konfiguration wiederherstellen Im schlimmsten Fall muss man eben reseten und alles manuell neu konfigurieren.
Hm, hat jemand von Euch die No-Tunnel-Variante auf einer CPE im erfolgreichen Einsatz?
*CPE210 (V1.1)* Nach der Installation von Hedy liegt LAN0 (PoE, eth0.1) auf dem DHCP-Netz und das WAN auf LAN1 (eth0.2). Wenn man nur ein Kabel nach außen legen möchte muss dementsprechend getauscht werden: Unter Netzwerk -> Schnittstellen: - DHCP -> Phys. Einst. -> Switch VLAN: "eth0.1" Haken raus -> Speichern - WAN -> Phys. Einst. -> Switch VLAN: "eth0.2" Haken raus und bei eth0.1 rein -> Speichern - WAN6 -> Wechsel Protokoll -> Phys. Einst. -> Switch VLAN: "eth0.1" auswählen -> Speichern & Anwenden Bei DHCP kann man auch den Haken bei Switch VLAN: "eth0.2" setzten, dann hat man das DHCP Netz auf LAN1. Für das Potsdam-VPN [1] müssen die OpenVPN Pakete nachträglich installiert werden: - System -> Paketverwaltung - Liste Aktualisieren - Folgende Pakete installieren: - luci-app-openvpn - luci-i18n-openvpn-de - luci-i18n-openvpn-en - openvpn-openssl Danach nach Anleitung [1] vorgehen. Hierfür habe das Image hedy-1.0.0-ffp-cpe210-220-sysupgrade.bin [2] verwendet. Achtung: Dort ist noch eine falsche URL für den Paketmanager eingetragen. Es muss http://dev.0xef.de/ffp/firmware/stable/1.0.0-ffp/ar71xx-generic/... anstatt http://dev.0xef.de/ffp/firmware/stable/1.0.0-ffp/ar71xx/... lauten. Oder man nimmt die vom Buildbot [3] [1] https://wiki.freifunk-potsdam.de/Potsdam-VPN [2] https://dev.0xef.de/ffp/firmware/stable/1.0.0-ffp/ar71xx-generic/default/hed... [3] http://buildbot.berlin.freifunk.net/buildbot/stable/1.0.0/ar71xx-generic/ Grüße Hannes
Johannes
Am Mittwoch, 14. März 2018, 16:48:33 CET schrieb Hannes Fuchs:
Am 14.03.2018 um 16:33 schrieb Nicco Kunzmann (gmx):
Hi,
für CPEs scheint es noch kein offizielles Hedy zu geben..
Wird langsam OT... Ist doch alles da [1][2]: - hedy-1.0.0-cpe210-220-factory.bin - hedy-1.0.0-cpe210-220-sysupgrade.bin - hedy-1.0.0-cpe510-520-factory.bin - hedy-1.0.0-cpe510-520-sysupgrade.bin
Für CPE210 V2 sollte unstable build >= 623 [3] funktionieren.
Wer klickfaul ist kann gerne die angepassten builds [4] von mir testen: - SSID angepasst - olsrd defaults: etx_ff -> etx_ffeth (kommt noch ein vernünftiger Patch upstream) - potsdam community als default
[1] http://buildbot.berlin.freifunk.net/buildbot/stable/1.0.0/ar71xx-generic/def ault/ [2] http://buildbot.berlin.freifunk.net/buildbot/stable/1.0.0/ar71xx-generic/vpn 03/ [3] http://buildbot.berlin.freifunk.net/buildbot/unstable/ar71xx-generic/ [4] https://dev.0xef.de/ffp/firmware/stable/1.0.0-ffp/ar71xx-generic/
Grüße Hannes
Ich denke dazu folgendes: Der build Bot hat das vielleicht noch nicht gebaut. Aber: OpenWRT/LEDE funktionieren für die CPE210. Das heißt, dass Hedy-Images ohne Risiko, dass die Router unbrauchbar werden, verwendet werden können. Zusätzlich gibt es eine Anleitung, wie man die Software selber baut. Damit, denke ich, kann man die Software für die CPE210 auf dem Hedy-1.0.0-Branch selbst bauen. https://github.com/freifunk-berlin/firmware/blob/v1.0.0/README.md
Viele Grüße, Nicco
On 03/14/2018 04:12 PM, Hannes Fuchs wrote:
Hallo,
laut Berliner ML [1] sind vpn03a und vpn03e nicht erreichbar. Dadurch wird jetzt die Last auf die übrigen VPN-Server verteilt und das kann dann die Performanceeinbrüche erklären.
[1] https://lists.berlin.freifunk.net/pipermail/berlin/2018-March/037249.html
Grüße Hannes
Am 14.03.2018 um 15:31 schrieb Johannes Rohr:
Seit mindestens gestern sehe ich bei einer CPE, das nix mehr durchs VPN kommt. Das Gerät hängt normal am LAN, ist erreichbar, aber durchs FFVPN tröpfeln die Bytes nur.
Seht Ihr anderswo ähnliches? Ich sehe auch in Grafana, dass der Netztwerk- Traffic im Uferwerk in den letzten Tagen ziemlich eingebrochen ist https:// monitor.freifunk-potsdam.de/grafana/dashboard/db/loc-uferwerk-werder?org Id=2
Ich würde ja gerne die Uplinks alle auf Hedy mit No-Tunnel umrüsten, aber meine bisherigen Erfahrungen damit waren teilweise ziemlich problematisch, und für CPEs scheint es noch kein offizielles Hedy zu geben..
Ciao,
Johannes _______________________________________________ Users mailing list Users@lists.freifunk-potsdam.de https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@lists.freifunk-potsdam.de https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@lists.freifunk-potsdam.de https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
Am Donnerstag, 15. März 2018, 11:08:45 CET schrieb Hannes Fuchs:
Am 14.03.2018 um 23:49 schrieb Johannes Rohr:
Schönen Dank für die Hinweise. Gerade mit einer CPE probiert. Das war ein längerer Kampf, dessen Ergebnis genauso besch$$$en war, wie meine Versuche mit einer Glinet. Nach Ersteinrichtung geht gar nichts mehr. Man kommt zwar noch auf das Gerät drauf, aber von dort aus geht nix, man kann das Default-Gateway nicht einmal anpingen, geschweige denn Namen auflösen etc.
Also ich kann deine Probleme nicht reproduzieren. Die Images funktionieren soweit auf einer CPE210 v1.1 und einem GL-AR150.
Ich habe hier eine Gl-Inet 6416, wo es reproduzierbar nach der FF- Ersteinrichtung hakt. Dann blinkt die LED des Geräts rot und man kann das Gerät zwar von außen erreichen aber aus dem Gerät heraus kann man nicht einmal das lokale Default-Gateway anpingen. Die CPE, mit der ich es gestern probiert habe ist auch eine 210. Auch da: Nach FF-Ersteinrichtung ist der ausgehende Datenverkehr gesperrt.
Bei dem GL-AR150 hat lediglich das Zurückspielen der Konfiguration nicht sauber funktioniert. Den musste ich dann reseten und neu konfigurieren.
Das habe ich auch gemacht.
Egal ob jetzt mit vpn (vpn03) oder ohne (default). Die von die genannten Probleme sind mir noch nicht begegnet.
Bisher hatte Roaming rumgezickt, aber nach ein-zwei reboots hat es dann geklappt. Das müssten wir uns dann noch mal genauer ansehen.
Das Problem tritt aber auf, bevor ich überhaupt Roaming eingerichtet habe.
Gehst du auch richtig vor?: - Konfiguration sichern - Upgrade *ohne* Haken bei "Konfiguration beibehalten"
Ja
- Konfiguration wiederherstellen
Habe ich versucht, das Ergebnis war aber auch nicht so doll, da gab's dann andere Probleme.
Im schlimmsten Fall muss man eben reseten und alles manuell neu konfigurieren.
Habe ich gemacht, zwei-drei mal. Ergebnis war immer identisch.
Hm, hat jemand von Euch die No-Tunnel-Variante auf einer CPE im erfolgreichen Einsatz?
*CPE210 (V1.1)* Nach der Installation von Hedy liegt LAN0 (PoE, eth0.1) auf dem DHCP-Netz und das WAN auf LAN1 (eth0.2). Wenn man nur ein Kabel nach außen legen möchte muss dementsprechend getauscht werden: Unter Netzwerk -> Schnittstellen:
Nunja, das habe ich gemacht. Wie gesagt, eingehender Datenverkehr geht, aber ausgehender nicht. Ciao, Johannes
Wenn ich mich nicht irre gibt es noch mindestens einen Thread dazu von dir in der Berliner ML, auch bisher ohne positiven Ergebnis. Ich versuche es zusammenzufassen: - nach Abschluss des Wizards geht nur Traffic *zum* Router: - ssh / http / icmp - der Router selbst kommt nicht raus - weder ins Internet - noch ins LAN - geschweige denn zum GW Das ganze scheint an Hedy zu liegen. Versionen davor haben funktioniert. Zum Gl-Inet 6416 kann man wohl nur abwarten bis jemand anderes (Carsten) es ausprobiert. Zur CPE210; hier wäre die genaue Version hilfreich. Vielleicht hängt es ja mit den HW-Versionen zusammen. Ich habe es mit einer 1.1 (nicht EU) getestet, später gab es dann die 1.1 (EU). Das ein Router von sich aus komplett dicht macht, also keinen ausgehenden Traffic mehr erlaubt ist an sich schon komisch. Normalerweise kommt man ja vom Router aus überall hin und wenigstens der DHCP Request auf WAN muss ja allen anschien nach raus gehen. Wie sieht denn die IP-Konfiguration aus? Am besten via SSH auf den Router und dann: ip ad sh Grüße Hannes Am 15.03.2018 um 15:34 schrieb Johannes Rohr:
Am Donnerstag, 15. März 2018, 11:08:45 CET schrieb Hannes Fuchs:
Am 14.03.2018 um 23:49 schrieb Johannes Rohr:
Schönen Dank für die Hinweise. Gerade mit einer CPE probiert. Das war ein längerer Kampf, dessen Ergebnis genauso besch$$$en war, wie meine Versuche mit einer Glinet. Nach Ersteinrichtung geht gar nichts mehr. Man kommt zwar noch auf das Gerät drauf, aber von dort aus geht nix, man kann das Default-Gateway nicht einmal anpingen, geschweige denn Namen auflösen etc.
Also ich kann deine Probleme nicht reproduzieren. Die Images funktionieren soweit auf einer CPE210 v1.1 und einem GL-AR150.
Ich habe hier eine Gl-Inet 6416, wo es reproduzierbar nach der FF- Ersteinrichtung hakt. Dann blinkt die LED des Geräts rot und man kann das Gerät zwar von außen erreichen aber aus dem Gerät heraus kann man nicht einmal das lokale Default-Gateway anpingen.
Die CPE, mit der ich es gestern probiert habe ist auch eine 210. Auch da: Nach FF-Ersteinrichtung ist der ausgehende Datenverkehr gesperrt.
Bei dem GL-AR150 hat lediglich das Zurückspielen der Konfiguration nicht sauber funktioniert. Den musste ich dann reseten und neu konfigurieren.
Das habe ich auch gemacht.
Egal ob jetzt mit vpn (vpn03) oder ohne (default). Die von die genannten Probleme sind mir noch nicht begegnet.
Bisher hatte Roaming rumgezickt, aber nach ein-zwei reboots hat es dann geklappt. Das müssten wir uns dann noch mal genauer ansehen.
Das Problem tritt aber auf, bevor ich überhaupt Roaming eingerichtet habe.
Gehst du auch richtig vor?: - Konfiguration sichern - Upgrade *ohne* Haken bei "Konfiguration beibehalten"
Ja
- Konfiguration wiederherstellen
Habe ich versucht, das Ergebnis war aber auch nicht so doll, da gab's dann andere Probleme.
Im schlimmsten Fall muss man eben reseten und alles manuell neu konfigurieren.
Habe ich gemacht, zwei-drei mal. Ergebnis war immer identisch.
Hm, hat jemand von Euch die No-Tunnel-Variante auf einer CPE im erfolgreichen Einsatz?
*CPE210 (V1.1)* Nach der Installation von Hedy liegt LAN0 (PoE, eth0.1) auf dem DHCP-Netz und das WAN auf LAN1 (eth0.2). Wenn man nur ein Kabel nach außen legen möchte muss dementsprechend getauscht werden: Unter Netzwerk -> Schnittstellen:
Nunja, das habe ich gemacht. Wie gesagt, eingehender Datenverkehr geht, aber ausgehender nicht.
Ciao,
Johannes
Am 15.03.2018 um 19:17 schrieb Hannes Fuchs:
Wenn ich mich nicht irre gibt es noch mindestens einen Thread dazu von dir in der Berliner ML, auch bisher ohne positiven Ergebnis. Ich versuche es zusammenzufassen:
- nach Abschluss des Wizards geht nur Traffic *zum* Router: - ssh / http / icmp - der Router selbst kommt nicht raus - weder ins Internet - noch ins LAN - geschweige denn zum GW
Alles korrekt.
Das ganze scheint an Hedy zu liegen. Versionen davor haben funktioniert. Zum Gl-Inet 6416 kann man wohl nur abwarten bis jemand anderes (Carsten) es ausprobiert.
Zur CPE210; hier wäre die genaue Version hilfreich. Vielleicht hängt es ja mit den HW-Versionen zusammen. Ich habe es mit einer 1.1 (nicht EU) getestet, später gab es dann die 1.1 (EU).
Hm, wo sehe ich die Hardware-Version? Ich denke EU, aber sicher bin ich nicht.
Das ein Router von sich aus komplett dicht macht, also keinen ausgehenden Traffic mehr erlaubt ist an sich schon komisch. Normalerweise kommt man ja vom Router aus überall hin und wenigstens der DHCP Request auf WAN muss ja allen anschien nach raus gehen.
Stimmt.
Wie sieht denn die IP-Konfiguration aus? Am besten via SSH auf den Router und dann: ip ad sh
Ich habe jetzt erstmal kathleen zurückgespielt, um ein funktionierendes Gerät zu haben, aber heute morgen hat mir schon jemand diese Frage ähnlich gestellt. Hier :
Hallo Johannes,
Kannst du "swconfig dev switch0 show" und "ip a" ausführen und mir schicken? Global attributes: enable_vlan: 0 Port 0: pvid: 0 link: port:0 link:up speed:1000baseT full-duplex txflow rxflow Port 1: pvid: 0 link: port:1 link:down Port 2: pvid: 0 link: port:2 link:down Port 3: pvid: 0 link: port:3 link:down Port 4: pvid: 0 link: port:4 link:down VLAN 0: vid: 0 ports: 0 1 2 3 4 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-wan state UP group default qlen 1000 link/ether e4:95:6e:40:31:95 brd ff:ff:ff:ff:ff:ff 3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel master br-dhcp state DOWN group default qlen 1000 link/ether e4:95:6e:40:31:95 brd ff:ff:ff:ff:ff:ff 4: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1 link/ipip 0.0.0.0 brd 0.0.0.0 8: ifb0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc hfsc state UNKNOWN group default qlen 32 link/ether 26:dc:cc:30:52:d9 brd ff:ff:ff:ff:ff:ff inet6 fe80::24dc:ccff:fe30:52d9/64 scope link valid_lft forever preferred_lft forever 9: br-dhcp: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether e4:95:6e:40:31:95 brd ff:ff:ff:ff:ff:ff inet 6.16.4.1/24 brd 6.16.4.255 scope global br-dhcp valid_lft forever preferred_lft forever 10: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e4:95:6e:40:31:95 brd ff:ff:ff:ff:ff:ff inet 192.168.30.14/24 brd 192.168.30.255 scope global br-wan valid_lft forever preferred_lft forever inet6 fe80::e695:6eff:fe40:3195/64 scope link valid_lft forever preferred_lft forever 11: ffuplink_wan@ffuplink: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-wan state UP group default qlen 1000 link/ether da:22:3d:7b:c4:d9 brd ff:ff:ff:ff:ff:ff 12: ffuplink@ffuplink_wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc hfsc state UP group default qlen 1000 link/ether 7e:a9:83:6a:04:18 brd ff:ff:ff:ff:ff:ff inet 192.168.30.195/24 brd 192.168.30.255 scope global ffuplink valid_lft forever preferred_lft forever inet6 fe80::7ca9:83ff:fe6a:418/64 scope link valid_lft forever preferred_lft forever 13: br-ROAM_AP: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e6:95:6e:40:31:95 brd ff:ff:ff:ff:ff:ff inet 10.22.17.129/25 brd 10.22.17.255 scope global br-ROAM_AP valid_lft forever preferred_lft forever inet6 fe80::e495:6eff:fe40:3195/64 scope link valid_lft forever preferred_lft forever 14: wlan0-adhoc-2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e4:95:6e:40:31:95 brd ff:ff:ff:ff:ff:ff inet 10.22.16.4/16 brd 10.22.255.255 scope global wlan0-adhoc-2 valid_lft forever preferred_lft forever inet6 fe80::e695:6eff:fe40:3195/64 scope link valid_lft forever preferred_lft forever 15: wlan0-dhcp-2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-ROAM_AP state UP group default qlen 1000 link/ether e6:95:6e:40:31:95 brd ff:ff:ff:ff:ff:ff inet6 fe80::e495:6eff:fe40:3195/64 scope link valid_lft forever preferred_lft forever 16: wlan0-2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e2:95:6e:40:31:95 brd ff:ff:ff:ff:ff:ff inet6 fe80::e095:6eff:fe40:3195/64 scope link valid_lft forever preferred_lft forever 17: tnl_0a161005@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1 link/ipip 0.0.0.0 peer 10.22.16.5 inet 10.22.16.4/32 scope global tnl_0a161005 valid_lft forever preferred_lft forever
Grüße Hannes
Am 15.03.2018 um 15:34 schrieb Johannes Rohr:
Am Donnerstag, 15. März 2018, 11:08:45 CET schrieb Hannes Fuchs:
Am 14.03.2018 um 23:49 schrieb Johannes Rohr:
Schönen Dank für die Hinweise. Gerade mit einer CPE probiert. Das war ein längerer Kampf, dessen Ergebnis genauso besch$$$en war, wie meine Versuche mit einer Glinet. Nach Ersteinrichtung geht gar nichts mehr. Man kommt zwar noch auf das Gerät drauf, aber von dort aus geht nix, man kann das Default-Gateway nicht einmal anpingen, geschweige denn Namen auflösen etc. Also ich kann deine Probleme nicht reproduzieren. Die Images funktionieren soweit auf einer CPE210 v1.1 und einem GL-AR150. Ich habe hier eine Gl-Inet 6416, wo es reproduzierbar nach der FF- Ersteinrichtung hakt. Dann blinkt die LED des Geräts rot und man kann das Gerät zwar von außen erreichen aber aus dem Gerät heraus kann man nicht einmal das lokale Default-Gateway anpingen.
Die CPE, mit der ich es gestern probiert habe ist auch eine 210. Auch da: Nach FF-Ersteinrichtung ist der ausgehende Datenverkehr gesperrt.
Bei dem GL-AR150 hat lediglich das Zurückspielen der Konfiguration nicht sauber funktioniert. Den musste ich dann reseten und neu konfigurieren. Das habe ich auch gemacht.
Egal ob jetzt mit vpn (vpn03) oder ohne (default). Die von die genannten Probleme sind mir noch nicht begegnet.
Bisher hatte Roaming rumgezickt, aber nach ein-zwei reboots hat es dann geklappt. Das müssten wir uns dann noch mal genauer ansehen. Das Problem tritt aber auf, bevor ich überhaupt Roaming eingerichtet habe.
Gehst du auch richtig vor?: - Konfiguration sichern - Upgrade *ohne* Haken bei "Konfiguration beibehalten" Ja
- Konfiguration wiederherstellen Habe ich versucht, das Ergebnis war aber auch nicht so doll, da gab's dann andere Probleme.
Im schlimmsten Fall muss man eben reseten und alles manuell neu konfigurieren. Habe ich gemacht, zwei-drei mal. Ergebnis war immer identisch.
Hm, hat jemand von Euch die No-Tunnel-Variante auf einer CPE im erfolgreichen Einsatz? *CPE210 (V1.1)* Nach der Installation von Hedy liegt LAN0 (PoE, eth0.1) auf dem DHCP-Netz und das WAN auf LAN1 (eth0.2). Wenn man nur ein Kabel nach außen legen möchte muss dementsprechend getauscht werden: Unter Netzwerk -> Schnittstellen: Nunja, das habe ich gemacht. Wie gesagt, eingehender Datenverkehr geht, aber ausgehender nicht.
Ciao,
Johannes
Am 15.03.2018 um 19:24 schrieb Johannes Rohr:
Am 15.03.2018 um 19:17 schrieb Hannes Fuchs:
[...]
Zur CPE210; hier wäre die genaue Version hilfreich. Vielleicht hängt es ja mit den HW-Versionen zusammen. Ich habe es mit einer 1.1 (nicht EU) getestet, später gab es dann die 1.1 (EU). Hm, wo sehe ich die Hardware-Version? Ich denke EU, aber sicher bin ich nicht.
Auf dem Aufkleber unter der Klappe und falls nicht physisch erreichbar unter Status -> Übersicht. Aber keine Ahnung ob dort bei der EU Version dies mit angezeigt wird.
[...] Wie sieht denn die IP-Konfiguration aus? Am besten via SSH auf den Router und dann: ip ad sh
Ich habe jetzt erstmal kathleen zurückgespielt, um ein funktionierendes Gerät zu haben, aber heute morgen hat mir schon jemand diese Frage ähnlich gestellt.
Hier :
Hallo Johannes,
Kannst du "swconfig dev switch0 show" und "ip a" ausführen und mir schicken? Global attributes: enable_vlan: 0 Port 0: pvid: 0 link: port:0 link:up speed:1000baseT full-duplex txflow rxflow Port 1: pvid: 0 link: port:1 link:down Port 2: pvid: 0 link: port:2 link:down Port 3: pvid: 0 link: port:3 link:down Port 4: pvid: 0 link: port:4 link:down VLAN 0: vid: 0 ports: 0 1 2 3 4 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-wan state UP group default qlen 1000 link/ether e4:95:6e:40:31:95 brd ff:ff:ff:ff:ff:ff 3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel master br-dhcp state DOWN group default qlen 1000 link/ether e4:95:6e:40:31:95 brd ff:ff:ff:ff:ff:ff 4: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1 link/ipip 0.0.0.0 brd 0.0.0.0 8: ifb0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc hfsc state UNKNOWN group default qlen 32 link/ether 26:dc:cc:30:52:d9 brd ff:ff:ff:ff:ff:ff inet6 fe80::24dc:ccff:fe30:52d9/64 scope link valid_lft forever preferred_lft forever 9: br-dhcp: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether e4:95:6e:40:31:95 brd ff:ff:ff:ff:ff:ff inet 6.16.4.1/24 brd 6.16.4.255 scope global br-dhcp valid_lft forever preferred_lft forever 10: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e4:95:6e:40:31:95 brd ff:ff:ff:ff:ff:ff inet 192.168.30.14/24 brd 192.168.30.255 scope global br-wan valid_lft forever preferred_lft forever inet6 fe80::e695:6eff:fe40:3195/64 scope link valid_lft forever preferred_lft forever 11: ffuplink_wan@ffuplink: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-wan state UP group default qlen 1000 link/ether da:22:3d:7b:c4:d9 brd ff:ff:ff:ff:ff:ff 12: ffuplink@ffuplink_wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc hfsc state UP group default qlen 1000 link/ether 7e:a9:83:6a:04:18 brd ff:ff:ff:ff:ff:ff inet 192.168.30.195/24 brd 192.168.30.255 scope global ffuplink valid_lft forever preferred_lft forever inet6 fe80::7ca9:83ff:fe6a:418/64 scope link valid_lft forever preferred_lft forever 13: br-ROAM_AP: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e6:95:6e:40:31:95 brd ff:ff:ff:ff:ff:ff inet 10.22.17.129/25 brd 10.22.17.255 scope global br-ROAM_AP valid_lft forever preferred_lft forever inet6 fe80::e495:6eff:fe40:3195/64 scope link valid_lft forever preferred_lft forever 14: wlan0-adhoc-2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e4:95:6e:40:31:95 brd ff:ff:ff:ff:ff:ff inet 10.22.16.4/16 brd 10.22.255.255 scope global wlan0-adhoc-2 valid_lft forever preferred_lft forever inet6 fe80::e695:6eff:fe40:3195/64 scope link valid_lft forever preferred_lft forever 15: wlan0-dhcp-2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-ROAM_AP state UP group default qlen 1000 link/ether e6:95:6e:40:31:95 brd ff:ff:ff:ff:ff:ff inet6 fe80::e495:6eff:fe40:3195/64 scope link valid_lft forever preferred_lft forever 16: wlan0-2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e2:95:6e:40:31:95 brd ff:ff:ff:ff:ff:ff inet6 fe80::e095:6eff:fe40:3195/64 scope link valid_lft forever preferred_lft forever 17: tnl_0a161005@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1 link/ipip 0.0.0.0 peer 10.22.16.5 inet 10.22.16.4/32 scope global tnl_0a161005 valid_lft forever preferred_lft forever
Das ist wohl die vom Gl-Inet 6416. Sieht für mich Okay aus. Ich sehe das dort Roaming konfiguriert ist. Kann es vielleicht mit dem Roaming zusammenhängen? Damit hatte ich ja auch Probleme und seitdem ich die Ursache dafür eingrenzen wollte läuft es. Andererseits schubst du, dass schon vor der Einrichtung von Roaming kein ausgehender Traffic ging. Vom Router aus sollte man problemlos was aus dem Privaten Netz (192.168.30.0/24) pingen können, falls nicht braucht man erst gar nicht weiter machen. Bei der Fehlersuche bin ich wie folgt vorgegangen: - Router zurückgesetzt - Wizard durchlaufen -> reboot - ggf. WAN Port umkonfiguriert, auch bei WAN6! - ggf. Roaming eingerichtet - ggf. KK eingerichtet Sollte schon nachdem reboot nichts mehr gehen, dann ist arg was faul. Ansonsten Schritt für Schritt vorgehen und Ursache eingrenzen.
Grüße Hannes
Am 15.03.2018 um 15:34 schrieb Johannes Rohr:
Am Donnerstag, 15. März 2018, 11:08:45 CET schrieb Hannes Fuchs:
Am 14.03.2018 um 23:49 schrieb Johannes Rohr:
Schönen Dank für die Hinweise. Gerade mit einer CPE probiert. Das war ein längerer Kampf, dessen Ergebnis genauso besch$$$en war, wie meine Versuche mit einer Glinet. Nach Ersteinrichtung geht gar nichts mehr. Man kommt zwar noch auf das Gerät drauf, aber von dort aus geht nix, man kann das Default-Gateway nicht einmal anpingen, geschweige denn Namen auflösen etc. Also ich kann deine Probleme nicht reproduzieren. Die Images funktionieren soweit auf einer CPE210 v1.1 und einem GL-AR150. Ich habe hier eine Gl-Inet 6416, wo es reproduzierbar nach der FF- Ersteinrichtung hakt. Dann blinkt die LED des Geräts rot und man kann das Gerät zwar von außen erreichen aber aus dem Gerät heraus kann man nicht einmal das lokale Default-Gateway anpingen.
Die CPE, mit der ich es gestern probiert habe ist auch eine 210. Auch da: Nach FF-Ersteinrichtung ist der ausgehende Datenverkehr gesperrt.
Bei dem GL-AR150 hat lediglich das Zurückspielen der Konfiguration nicht sauber funktioniert. Den musste ich dann reseten und neu konfigurieren. Das habe ich auch gemacht.
Egal ob jetzt mit vpn (vpn03) oder ohne (default). Die von die genannten Probleme sind mir noch nicht begegnet.
Bisher hatte Roaming rumgezickt, aber nach ein-zwei reboots hat es dann geklappt. Das müssten wir uns dann noch mal genauer ansehen. Das Problem tritt aber auf, bevor ich überhaupt Roaming eingerichtet habe.
Gehst du auch richtig vor?: - Konfiguration sichern - Upgrade *ohne* Haken bei "Konfiguration beibehalten" Ja
- Konfiguration wiederherstellen Habe ich versucht, das Ergebnis war aber auch nicht so doll, da gab's dann andere Probleme.
Im schlimmsten Fall muss man eben reseten und alles manuell neu konfigurieren. Habe ich gemacht, zwei-drei mal. Ergebnis war immer identisch.
Hm, hat jemand von Euch die No-Tunnel-Variante auf einer CPE im erfolgreichen Einsatz? *CPE210 (V1.1)* Nach der Installation von Hedy liegt LAN0 (PoE, eth0.1) auf dem DHCP-Netz und das WAN auf LAN1 (eth0.2). Wenn man nur ein Kabel nach außen legen möchte muss dementsprechend getauscht werden: Unter Netzwerk -> Schnittstellen: Nunja, das habe ich gemacht. Wie gesagt, eingehender Datenverkehr geht, aber ausgehender nicht.
Ciao,
Johannes
participants (4)
-
Carsten N -
Hannes Fuchs -
Johannes Rohr -
Nicco Kunzmann (gmx)