Treffen 13.3.

classic Classic list List threaded Threaded
11 messages Options
Carsten N Carsten N
Reply | Threaded
Open this post in threaded view
|

Treffen 13.3.

Wer heute zum Treffen kommen wollte, dem sei gesagt, wir machen einen Grill an. ;-)

Bis 18Uhr c ya :-)

--

Viele Grüße
Carsten

[hidden email]


Web | Twitter | Facebook
FF-Mail: <a moz-do-not-send="true" href="sendto:%20info@freifunk-potsdam.de">info@...
Freifunk Potsdam Logo


_______________________________________________
Users mailing list
[hidden email]
https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
Johannes Rohr Johannes Rohr
Reply | Threaded
Open this post in threaded view
|

VPN tot?

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
[hidden email]
https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
Hannes Fuchs Hannes Fuchs
Reply | Threaded
Open this post in threaded view
|

Re: VPN tot?

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
> [hidden email]
> https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
>


_______________________________________________
Users mailing list
[hidden email]
https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users

signature.asc (879 bytes) Download Attachment
Nicco Kunzmann (gmx) Nicco Kunzmann (gmx)
Reply | Threaded
Open this post in threaded view
|

Re: VPN tot?

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
[hidden email]
https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users




_______________________________________________
Users mailing list
[hidden email]
https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
Hannes Fuchs Hannes Fuchs
Reply | Threaded
Open this post in threaded view
|

Re: VPN tot?

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/default/
[2]
http://buildbot.berlin.freifunk.net/buildbot/stable/1.0.0/ar71xx-generic/vpn03/
[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
>>> [hidden email]
>>> https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
>


_______________________________________________
Users mailing list
[hidden email]
https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users

signature.asc (879 bytes) Download Attachment
Johannes Rohr Johannes Rohr
Reply | Threaded
Open this post in threaded view
|

Re: VPN tot?

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
> >>> [hidden email]
> >>> https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
> >>
> >> _______________________________________________
> >> Users mailing list
> >> [hidden email]
> >> https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
> >
> > _______________________________________________
> > Users mailing list
> > [hidden email]
> > https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
Hannes Fuchs Hannes Fuchs
Reply | Threaded
Open this post in threaded view
|

Probleme mit Hedy? War: Re: VPN tot?

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/hedy-1.0.0-ffp-cpe210-220-sysupgrade.bin
[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
>>>>> [hidden email]
>>>>> https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> [hidden email]
>>>> https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
>>>
>>> _______________________________________________
>>> Users mailing list
>>> [hidden email]
>>> https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
>
>


_______________________________________________
Users mailing list
[hidden email]
https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users

signature.asc (879 bytes) Download Attachment
Johannes Rohr Johannes Rohr
Reply | Threaded
Open this post in threaded view
|

Re: Probleme mit Hedy? War: Re: VPN tot?

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
_______________________________________________
Users mailing list
[hidden email]
https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
Hannes Fuchs Hannes Fuchs
Reply | Threaded
Open this post in threaded view
|

Re: Probleme mit Hedy? War: Re: VPN tot?

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
>


_______________________________________________
Users mailing list
[hidden email]
https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users

signature.asc (879 bytes) Download Attachment
Johannes Rohr Johannes Rohr
Reply | Threaded
Open this post in threaded view
|

Re: Probleme mit Hedy? War: Re: VPN tot?

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
>>
>

_______________________________________________
Users mailing list
[hidden email]
https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users
Hannes Fuchs Hannes Fuchs
Reply | Threaded
Open this post in threaded view
|

Re: Probleme mit Hedy? War: Re: VPN tot?

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
>>>
>>
>

_______________________________________________
Users mailing list
[hidden email]
https://lists.freifunk-potsdam.de/cgi-bin/mailman/listinfo/users