[gelöst] Nach Update auf Gluon kein Standardgateway / keine FFRN Verbindung

Technik Gluon
1

Hi,

habe hier ein Problem und hoffe, es hat schon mal jemand gelöst und kann mir hier den Lösungsweg aufzeigen.

ich habe schon bei 2 Routerndas Update auf Gluon erfolgreich eingerichtet. Beide sind am Netz. Der 3. Router macht Schwierigkeiten. Gluon läuft und ist konfiguriert. Das meshing über WLAN läuft auch. Ich will den Knoten aber direkt ans Internet hängen und das geht nicht. Den Unterschied zu den anderen (laufenden) Routern ist, dass ich per LAN kein Standardgateway zugewiesen bekomme. Ansonsten will sich der Router einfach nicht bei den VPN Gateway anmelden - zumindest geht er nicht online.

Alle Router sind baugleiche TP-Link WR851N v9.0. Am Internetzugang liegt es nicht, da die anderen Router hier ja auch laufen. Per LAN komme ich weiterhin drauf und habe Gluon auch schon ein zweites Mal drüber gebügelt.

Hoffe, ihr könnt mit der Beschreibung was anfangen und mir helfen!

Grüße
Jörg

2

Hast du den Knoten per WAN Buchse (Blau) mit deinem Zugangrouter verbunden?
Der ist standardmäßig als Internetverbindungsbuchse eingestellt.

3

Hallo LittleJ

ja, habe ich. 4 LEDs sind an Power, LAN, WAN und WPS

Grüße
Jörg

4

Im Chat hatte gerade jemand ein ähnliches Problem, das ich auch nicht ganz erklären konnte. Bist Du sicher, dass Du beim Konfigurieren alles richtig eingestellt hast? Da kann man irgendwo „Mesh-only“ und „Knoten mit VPN-Uplink“ auswählen, wenn Du das das falsche genommen hast, würde das vielleicht das Verhalten erklären.

Kannst Du vielleicht die Ausgaben der folgenden Programme posten?

/sbin/ifconfig

/sbin/route

nslookup gw02.gluon.ffrn.de

Soll wahrscheinlich 841 heißen, oder?

5

Das ist nur nen Flag für welches ins JSON eingeht. Das hat nur einen Nutzen für eventuelle Dienste.

6

Hi Tobox,

hier die Infos:

Hardware-Modell: TP-Link TL-WR841N/ND v9 (ja, 841 sollte es sein)
Gluon-Version v2015.1.2
Firmware-Release 0.4-20151012

Im Config Modus, also nach Drücken der Resettaste:

/sbin/ifconfig
br-setup Link encap:Ethernet HWaddr 30:B5:C2:C6:81:FA
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::32b5:c2ff:fec6:82fa/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4333 errors:0 dropped:0 overruns:0 frame:0
TX packets:1271 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:485726 (474.3 KiB) TX bytes:236849 (231.2 KiB)

eth0 Link encap:Ethernet HWaddr 30:B5:C2:C6:81:FA
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4811 errors:0 dropped:20 overruns:0 frame:0
TX packets:1269 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:589046 (575.2 KiB) TX bytes:235273 (229.7 KiB)
Interrupt:5

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:76 (76.0 B) TX bytes:76 (76.0 B)

/sbin/route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 br-setup

nslookup gw02.gluon.ffrn.de
Server: 127.0.0.1
Address 1: 127.0.0.1 localhost

nslookup: can’t resolve ‘gw02.gluon.ffrn.de’: Name or service not known

Hoffe, das hilft weiter.
Grüße
Jörg

7

Also die Ausgaben im Config-Modus sind relativ uninteressant, da er sich ja dann eh nicht mit einem Default-Gateway im LAN verbindet, geschweige denn mit den Freifunk-Gateways. Kannst Du Dich einloggen, wenn er nicht im Config-Mode ist? Zum Beispiel per ssh auf die IPv4-Adresse, die er (hoffentlich) von Deinem Router bekommt? Oder vielleicht auch über die Link-Local-IPv6-Adresse (vielleicht die fe80::32b5:c2ff:fec6:82fa)?

8

Moin,

so, nachdem ich es nun geschafft habe per IPv6 LAN auf den Router zu kommen, wenn er nicht im Config-Mode ist, bin ich der Sache näher gekommen:

nslookup gw02.gluon.ffrn.de
Server: 127.0.0.1
Address 1: 127.0.0.1 localhost

nslookup: can’t resolve ‘gw02.gluon.ffrn.de’: Name or service not known`

nslookup google.com
Server: 127.0.0.1
Address 1: 127.0.0.1 localhost

nslookup: can’t resolve ‘google.com’: Name or service not known

ping google.com
ping: bad address ‘google.com’

ping 109.193.192.89
PING 109.193.192.89 (109.193.192.89): 56 data bytes
64 bytes from 109.193.192.89: seq=0 ttl=59 time=22.484 ms

Das bedeutet doch wohl, dass der die Nameserver zur Namensauflösung nicht findet.

/sbin/route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.2.254 0.0.0.0 UG 0 0 0 br-wan
10.142.0.0 * 255.255.0.0 U 0 0 0 local-node
192.168.2.0 * 255.255.255.0 U 0 0 0 br-wan

Hier ein paar Infos aus der /etc/config/network

config interface 'wan6’
option proto 'dhcpv6’
option ifname 'br-wan’
option ip6table '1’
option peerdns ‘0’

config interface 'wan’
option igmp_snooping '0’
option ifname 'eth1’
option auto '1’
option peerdns '0’
option type 'bridge’
option proto 'dhcp’
option macaddr ‘32:b6:c2:c6:81:fa’

config rule6 'wan6_lookup’
option mark '0x01/0x01’
option lookup ‘1’

config route6 'wan6_unreachable’
option type 'unreachable’
option table '1’
option target '::/0’
option metric '65535’
option gateway '::'
option interface ‘loopback’

Ist hier was bei der Einrichtung schief gelaufen?

Grüße
Jörg

9

Vielleicht noch als nützliche Ergänzung:

/tmp/resolv.conf

search lan
nameserver 127.0.0.1

/tmp/resolv.conf.auto

# Interface wan
# Interface wan6

Sind das die Standardwerte?

10

Das ist alles soweit ok. Auch das du auf dem Knoten nicht direkt auflösen kannst, ist normal. In Gluon darf nur der VPN Prozess den DNS Server des Uplinks nutzen. Alle anderen Dienste müssen auf die DNS Server warten, die er mitgeteilt bekommt, wenn er mit den Gateways verbunden ist.

11

Ich weiß nicht ganz genau, wie es funktioniert, aber es kann sein dass das mit der nicht funktionierenden Namensauflösung so korrekt ist. Das ist eine Sicherheitsmaßnahme, damit der Verkehr immer durchs VPN fließt.
In die /tmp/resolv.conf.auto kommen dann die Freifunk-Nameserver, sobald dein Knoten richtig im Freifunk-Netz ist. Aber da das bei Dir nicht funktioniert, ist es erklärbar, dass die Datei praktisch leer ist.

13

Das macht Sinn. Verstehe nur gerade nicht, wie er sich per VPN verbinden kann, wenn er nicht auflösen kann.
In der /etc/config/fastd habe ich mal spassehalber die IP Adresse des gw02 manuell aufgelöst:

alt: list remote '"gw02.gluon.ffrn.de" port 10000'
neu: list remote '78.46.199.234 port 10000'

leider erfolglos.

14

@anon8743323 die Frage ist ob wir über die Rolle im Expert Mode sprechen oder den Haken vorne im Wizzard.

16

Hallo FF,

habe Problem gefunden und gelöst! Keine Ahnung, wie das passieren konnte, aber der Fehler lag ganz woanders. Den neuen VPN Key, der nach dem Update erstellt wird, hatte ich nicht unter https://register.freifunk-rhein-neckar.de/ hinterlegt. Hier war noch der alte Key drin. VPN Key getauscht und schon online!

Das Thema kann man jetzt unter “Lesson learned” ablegen und in die Checkliste für “Probleme im Verbindungsaufbau” aufnehmen…

Danke allen, die hier fleisig mitgeholfen habe, die Ursache zu finden.

Grüße
Jörg

1 „Gefällt mir“
17

Auch wenn das Thema schon gelöst ist, das mit dem DNS könnt ihr hier in der Doku von Gluon nachlesen:

http://gluon.readthedocs.org/en/v2015.1.2/dev/wan.html#gluon-wan-dnsmasq

18

Danke für den Tipp. Ich hatte genau dasselbe Problem, hatte vergessen, den neuen VPN-Key einzutragen. Knoten Werder läuft jetzt wieder.
Jörg