Raspberry Pi v1 als Node mit zusätzlicher Client-NIC?

warmsurfer · 11. Dezember 2016 um 16:02

Habe mir mal die Config unter /etc/config angesehen:

config interface 'loopback’
option ifname 'lo’
option proto 'static’
option ipaddr '127.0.0.1’
option netmask ‘255.0.0.0’

config globals 'globals’
option ula_prefix ‘eine Adresse’

config interface 'wan’
option ifname 'eth0’
option multicast_querier '0’
option peerdns '0’
option auto '1’
option type 'bridge’
option proto 'dhcp’
option macaddr ‘eine Adresse’

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

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’

config interface 'mesh_wan’
option ifname 'br-wan’
option auto '0’
option transitive '1’
option fixed_mtu '1’
option proto ‘gluon_mesh’

config interface 'client’
option type 'bridge’
option macaddr 'eine Adresse’
option proto 'dhcpv6’
option reqprefix 'no’
option robustness '3’
option query_interval '2000’
option query_response_interval '500’
option peerdns '1’
option sourcefilter '0’
option ifname ‘eth1’

config interface 'bat0’
option multicast_router '2’
option ifname 'bat0’
option macaddr 'eine Adresse’
option learning '0’
option proto ‘none’

config interface 'mesh_vpn’
option ifname 'mesh-vpn’
option transitive '1’
option macaddr 'eine Adresse’
option fixed_mtu '1’
option proto ‘gluon_mesh’

config device 'local_node_dev’
option macaddr 'eine Adresse’
option ifname 'br-client’
option name 'local-node’
option type ‘macvlan’

config interface 'local_node’
option ifname 'local-node’
option ipaddr 'eine Adresse’
option ip6addr 'eine Adresse’
option netmask '255.255.224.0’
option proto ‘static’

config route6 'local_node_route6’
option target 'eine Adresse’
option gateway '::'
option interface ‘client’

Ich habe das doch schon etwas länger nicht mehr gemacht, wie würde ich jetzt br-client auf eth1 bridgen?
Ein bisschen gefährliches Halbwissen…

Danke schon mal!

psy · 11. Dezember 2016 um 16:48

Vergiss /etc/config wieder und schau dir https://github.com/freifunk-gluon/gluon/wiki/Commandline-administration an. Gluon nutzt uci um Einstellungen updatefest zu managen. Alles andere könnte oder wird relativ wahrscheinlich bei einem Update wieder kaputtgehen.

warmsurfer · 11. Dezember 2016 um 16:58

Also muss ich bei network.client.ifname=‘eth1’ setzen?
Reicht das in diesem Fall?

psy · 11. Dezember 2016 um 19:11

Sollte vermutlich reichen. Funktioniert es denn? Falls nicht wären die Ausgaben von ip a und brctl show interessant.

warmsurfer · 13. Dezember 2016 um 19:53

Ich habe jetzt mal das gebastel gelassen und ein TP-Link WR841N v9 mit der aktuellen Gluon-Firmware ausgestattet. Jetzt sollte er auch über WLAN meshen und siehe da: An den LAN-Ports fällt nun tatsächlich das Clientnetz raus!

Was mir noch zum Thema “nicht funktionierender ASIX-NIC” eingefallen ist: kann es ein, dass sich die Firmware auf dem Raspberry daran stört, dass ich die Module erst NACH der Ersteinrichtung installiert habe.
Ich würde ja gerne mit “firstboot” wieder von vorne anfangen, aber dann sind ja auch schließlich die Module wieder weg…
Ich müsste die Firmware mit den Modulen einkompiliert bauen.
Die Frage ist sowieso, warum man dies bei dem Raspberry-Image nicht sowie macht und zumindest die meist verbeitesten LAN-Adapter/WLAN-Chips damit unterstützt. Würde viel Gebastel ersparen.
Am Speicher wird’s wohl kaum hängen…

Natürlich wäre für alle anderen die Thematik trotzdem interessant, evtl. will ja jemand sowas auch mal machen und stößt dann auf die gleichen Probleme.

Der Raspberry existiert noch, ich werde mal in den nächsten Tagen die oben genannten Ausgaben posten…
Schon mal Danke!

psy · 17. Dezember 2016 um 13:12

Sehe keinen Grund, der dagegen spricht. Evtl wollen das die Firmware-Bauer einfach mal machen?

warmsurfer · 19. Dezember 2016 um 17:57

Aktuell habe ich Probleme, eine “stock” Umsetzung stabil zum Laufen zu bringen, guckst du hier:
https://forum.ortenau.freifunk.net/t/tp-link-wr841n-mit-gluon-0-2-90-instabil/159/5

Wenn ich das Thema mal stabil zum Laufen bekomme, dann nehme ich das Gebastel wieder auf
Wenn ich mal was angefangen habe, dann will ich auch das es funktioniert (oder ich erkenne, dass es technisch einfach nicht möglich ist => OK).
Vor allem will ich hier ja auch in Zukunft für andere ein Anlaufstelle bieten.
Spät. Anfang Januar habe ich Urlaub und dann habe ich etwas Zeit…

warmsurfer · 12. Januar 2017 um 23:55

So, nun habe ich wieder etwas Zeit gehabt und mal den aktuellen Beta-Build für das Raspi v. 1 auf die SD-Karte geschoben.
Siehe da, die Module für den ASIX-Adapter sind nun drin, toll!

Ich habe jetzt folgendes durchgeführt:

SD-Karte mit dem Beta-Image bespielt
Gluon über das WAN-Interface (eingebautes Interface) eingerichtet
Den Raspi mit dem WAN-Interface an mein Intranet angeschlossen und den ASIX-Adapter an des Raspi sowie an einen Switch angeklemmt.
Mit UCI network.client.ifname=‘eth1’ konfiguriert
UCI commit
Neustart des Raspi

Nun bekomme ich allerdings noch immer kein Clientnetzwerk am ASIX-Adapter.
Laut ifconfig siehts schon mal gut aus:

bat0      Link encap:Ethernet  HWaddr <Eine MAC>
          inet6 addr: fe80::ba27:ebff:fe9b:830/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:45163 errors:0 dropped:0 overruns:0 frame:0
          TX packets:184 errors:0 dropped:8 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3533605 (3.3 MiB)  TX bytes:24001 (23.4 KiB)

br-client Link encap:Ethernet  HWaddr <Eine MAC>
          inet6 addr: fe80::ba27:ebff:fe9b:830/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:531 errors:0 dropped:0 overruns:0 frame:0
          TX packets:354 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:49497 (48.3 KiB)  TX bytes:31805 (31.0 KiB)

br-wan    Link encap:Ethernet  HWaddr <Eine MAC>
          inet addr:192.168.2.22  Bcast:192.168.255.255  Mask:255.255.0.0
          inet6 addr: fe80::8013:b9ff:fe2e:6fa8/64 Scope:Link
          inet6 addr: 2003:6b:75a:3101:8013:b9ff:fe2e:6fa8/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:112724 errors:0 dropped:0 overruns:0 frame:0
          TX packets:71822 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:23046572 (21.9 MiB)  TX bytes:14487162 (13.8 MiB)

eth0      Link encap:Ethernet  HWaddr <Eine MAC>
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:112887 errors:0 dropped:105 overruns:0 frame:0
          TX packets:71822 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:23073063 (22.0 MiB)  TX bytes:15063402 (14.3 MiB)

eth1      Link encap:Ethernet  HWaddr <Eine MAC>
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:583 errors:0 dropped:52 overruns:0 frame:0
          TX packets:184 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:57037 (55.7 KiB)  TX bytes:14168 (13.8 KiB)

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:2624 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2624 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:236988 (231.4 KiB)  TX bytes:236988 (231.4 KiB)

local-node Link encap:Ethernet  HWaddr <Eine MAC>
          inet addr:10.214.32.1  Bcast:10.214.63.255  Mask:255.255.224.0
          inet6 addr: fe80::b7:7aff:feca:fe01/64 Scope:Link
          inet6 addr: 2a03:2260:a:eeee::/128 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:322 errors:0 dropped:0 overruns:0 frame:0
          TX packets:247 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:36922 (36.0 KiB)  TX bytes:21386 (20.8 KiB)

mesh-vpn  Link encap:Ethernet  HWaddr <Eine MAC>
          inet6 addr: fe80::8013:b9ff:fe2e:6faf/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1406  Metric:1
          RX packets:103131 errors:0 dropped:0 overruns:0 frame:0
          TX packets:69646 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:13910530 (13.2 MiB)  TX bytes:8270097 (7.8 MiB)

primary0  Link encap:Ethernet  HWaddr <Eine MAC>
          UP BROADCAST RUNNING NOARP  MTU:1532  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:57728 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:9685099 (9.2 MiB)

Über das WAN-Interface mesht er schon mal fleißig, aber ich bekomme immer noch kein DHCP-Lease…
Hier die Ausgabe von ip a:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
    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 qlen 1000
    link/ether <Eine MAC> brd ff:ff:ff:ff:ff:ff
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop
    link/ether <Eine MAC> brd ff:ff:ff:ff:ff:ff
4: teql0: <NOARP> mtu 1500 qdisc noop qlen 100
    link/void
5: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-client qlen 1000
    link/ether <Eine MAC> brd ff:ff:ff:ff:ff:ff
6: br-client: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
    link/ether <Eine MAC> brd ff:ff:ff:ff:ff:ff
    inet6 fe80::ba27:ebff:fe9b:830/64 scope link
       valid_lft forever preferred_lft forever
7: mesh-vpn: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1406 qdisc fq_codel master bat0 qlen 500
    link/ether <Eine MAC> brd ff:ff:ff:ff:ff:ff
    inet6 fe80::8013:b9ff:fe2e:6faf/64 scope link
       valid_lft forever preferred_lft forever
8: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
    link/ether <Eine MAC> brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.22/16 brd 192.168.255.255 scope global br-wan
       valid_lft forever preferred_lft forever
    inet6 2003:6b:75a:3101:8013:b9ff:fe2e:6fa8/64 scope global dynamic
       valid_lft 14358sec preferred_lft 1758sec
    inet6 fe80::8013:b9ff:fe2e:6fa8/64 scope link
       valid_lft forever preferred_lft forever
9: local-node@br-client: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
    link/ether <Eine MAC> brd ff:ff:ff:ff:ff:ff
    inet 10.214.32.1/19 brd 10.214.63.255 scope global local-node
       valid_lft forever preferred_lft forever
    inet6 2a03:2260:a:eeee::/128 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::b7:7aff:feca:fe01/64 scope link
       valid_lft forever preferred_lft forever
10: primary0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1532 qdisc noqueue master bat0
    link/ether <Eine MAC> brd ff:ff:ff:ff:ff:ff
11: bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
    link/ether <Eine MAC> brd ff:ff:ff:ff:ff:ff
    inet6 fe80::ba27:ebff:fe9b:830/64 scope link
       valid_lft forever preferred_lft forever

Ausgabe von brctl show:
bridge name bridge id STP enabled interfaces
br-client 7fff.b827eb9b0830 no eth1
br-wan 7fff.8213b92e6fa8 no eth0

Muss an der Firewall-Config in UCI noch etwas angepasst werden?
Danke im Voraus!

EDIT: Habe mal die Ausgaben als vorformatierten Text formatiert.

rgr · 13. Januar 2017 um 00:52

was sagt denn batctl o ?

warmsurfer · 13. Januar 2017 um 01:00

Etwas viel, um es hier vollständig zu posten, es fängt mit

de:86:ed:1e:d6:63    1.960s   (203) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (203)
be:ef:ca:fe:00:07    6.280s   (231) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (231)
76:5f:9b:5c:22:9b    0.820s   (197) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (197)
26:ee:61:56:ac:87    2.880s   (203) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (203)
da:13:ae:f5:78:6b    1.390s   (166) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (166)
8e:63:e8:80:c5:bf    3.370s   (177) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (177)
52:3b:c9:8f:17:df    3.910s   (199) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (199)
b2:2d:db:b9:ba:12    2.910s   (184) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (184)
ce:6f:25:0c:e4:0b    4.880s   (199) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (199)
2e:0a:6b:c7:9c:83    1.600s   (203) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (203)
8a:bf:3a:20:a0:b3    2.920s   (143) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (143)
52:3a:c3:54:57:63   14.950s   (176) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (176)
36:e3:de:68:4e:a3    3.030s   (187) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (187)
e6:2a:d7:9e:a1:ef    4.570s   (203) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (203)
06:00:dc:c8:81:cf    6.170s   (190) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (190)
1e:6b:f3:30:3b:bb    1.390s   (195) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (195)
82:74:4b:98:12:7b    1.960s   (166) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (166)
d2:49:b5:6f:da:87    0.840s   (205) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (205)
46:1b:92:2f:12:2b    4.240s   (166) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (166)
72:fd:b5:d7:ae:bf   10.020s   (199) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (199)
72:a7:eb:05:fb:33    4.470s   (196) be:ef:ca:fe:00:07 [  mesh-vpn]: be:ef:ca:fe:00:07 (196)

an…
Ich arbeite Nachts auch am besten…

EDIT: Habe mal die Ausgaben als vorformatierten Text formatiert.

psy · 13. Januar 2017 um 12:48

Hi,
bitte nutze für Logs, Quellcode, … die Vorformatierter Text-Funktion, mit Monospace-Font ist das ganze deutlich besser lesbarer als so.

Wenn du Clientnetz auf eth1 haben willst musst du zusätzlich zu eth1 auch noch bat0 (das ist das Interface an dem das Clientnetz rausfällt) hinzufügen. Dann sollte bei brctl show auch bat0 in der Client-Bridge auftauchen.

Du hast doch eine IP (192.168.2.22/16), wie kommst du darauf, dass du kein DHCP-Lease bekämst?

warmsurfer · 13. Januar 2017 um 14:12

Jetzt habe ich bei
network.client.ifname=‚eth1 bat0‘ konfiguriert.

Nach einem Neustart bekomme ich nun auch eine IP-Adresse im Clientnetz.

Bezog sich auf das Clientnetz, nicht auf das WAN-Interface, welches in meinem Intranet hängt.

Aber: Dank deinem alles entscheidenden Tipp funktioniert nun

Sollte man das nicht in ein Wiki aufnehmen?:

SD-Karte mit dem Beta-Image (später werden die Module auch im Stable-Train verfügbar sein) bespielt
Gluon über das WAN-Interface (eingebautes Interface) eingerichtet
Den Raspberry mit dem WAN-Interface an das Intranet anschließen und den ASIX-Adapter an des Raspberry sowie an einen Switch oder Access-Point verbinden.
Mittels SSH
uci set network.client.ifname=‚eth1 bat0‘
uci commit
reboot
ausführen.

Nach ca. 5-10 Minuten sollte nun das Clientnetzwerk am ASIX-Adapter verfügbar sein.

PS:

Wenn ich aktuell den Text mit 4 Leerzeichen einrücke, wird dieser nicht als vorformatierter Text in der Vorschau angezeigt?!

psy · 13. Januar 2017 um 15:27

Wenn man das USB-Nic schon vor der Konfiguration anschließt sollte das automatisch passieren. Ansonsten ist das halt doch ein sehr spezieller Fall, in dem man sich eh mehr mit der Administration auseinandersetzen und daher einlesen sollte.

Ich bin mir nicht 100% sicher, aber mit 4 Leerzeichen einrücken entspricht nicht genau der Funktion die ich meine (auch wenn es scheinbar etwas ähliches tut). Was ich meinte ist das einschließen des gepasteten Textes in `.

`Dein Text`

wird dann zu:

Dein Text

Auch erreichbar über das </> Symbol bei den Textformatierungen.

warmsurfer · 13. Januar 2017 um 16:01

Genau das ist aber nicht passiert.
Das USB-NIC wird beim Boot zwar kurz für ca. 4 Sekunden aktiv, geht dann aber wieder aus.
Bei der Konfiguration über LuCI war es die ganze Zeit über angeschlossen.

Es wurde am Anfang auch nach der Konfiguration auch noch nicht unter ifconfig gelistet.
Erst nachdem ich

ifconfig eth2 up

eingegeben hatte, war das Interface da.

warmsurfer · 3. März 2017 um 17:24

Hallöchen zusammen,

seit ein paar Tagen bekomme ich zwar eine gültige IP/Gateway vom Freifunk-DHCP zugewiesen, allerdings funktioniert/antwortet der DNS-Server 185.66.194.8 nicht. Wenn ich unter Windows den DNS 8.8.8.8 eintrage funktioniert der Internetzugriff über alle Browser wunderbar. Von meinem Intranet kann ich den DNS-Server 185.66.194.8 pingen, im Freifunk-Netz nicht.

Raspberry habe ich bereits neu gestartet (Gluon 0.3.1-beta)

Wird der DNS-Server irgendwo vor dem VPN-Tunnel oder danach blockiert?

Danke & schönen Abend!

warmsurfer · 10. November 2017 um 16:47

Hallöchen zusammen,

ich wärme das Thema mal auf, da seit gestern das Raspberry Pi kein Clientnetz mehr ausgibt.
Da ich bei mir die aktuelle Beta einsetze (mit Autoupdate) habe ich die Vermutung, dass hier ein Update meine Konfig geändert hat. Wurde vor kurzem hier etwas an den Interfaces oder an der Behandlung des IPv4/IPv6 Verkehrs geändert?
Sehr komisch: Bei mir taucht weder am Router an der Firewall eine Reaktion auf, noch wird von einem Dienst auf dem Raspberry eine CPU-Last erzeugt. Es scheint so, als würde hier schon beim “Bootstrapping” etwas schief laufen, alle Dienste sind auf 0% Auslastung.
Auf das Gerät komme ich wunderbar über SSH.
Ein Ping ist vom Raspberry aus auf mein Gateway im Intranet möglich, auch ein Ping an 8.8.8.8 funktioniert. Was nicht funktioniert, ist eine Namensauflösung von google.de bzw. ipv6.google.com.
“batctl gw” zeigt keine Gateways.

Hat jemand eine Idee?

Danke & einen schönen Abend .

warmsurfer · 10. November 2017 um 17:11

So wie es aussieht, dann er definitiv die Freifunk-Adressen nicht auflösen:
Im Log steht:

Fri Nov 10 18:01:55 2017 daemon.info fastd[1224]: resolving host `albufer3.ffka.net' failed: Try again
Fri Nov 10 18:01:55 2017 daemon.info fastd[1224]: resolving host `albufer5.karlsruhe.freifunk.net' for peer <mesh_vpn_backbone_peer_alb5>...
Fri Nov 10 18:01:59 2017 daemon.info fastd[1224]: resolving host `albufer4.karlsruhe.freifunk.net' failed: Try again
Fri Nov 10 18:01:59 2017 daemon.info fastd[1224]: resolving host `albufer7.karlsruhe.freifunk.net' failed: Try again
Fri Nov 10 18:02:00 2017 daemon.info fastd[1224]: resolving host `albufer0.karlsruhe.freifunk.net' for peer <mesh_vpn_backbone_peer_alb0>...
Fri Nov 10 18:02:00 2017 daemon.info fastd[1224]: resolving host `albufer5.karlsruhe.freifunk.net' failed: Try again
Fri Nov 10 18:02:01 2017 daemon.info fastd[1224]: resolving host `albufer2.ffka.net' for peer <mesh_vpn_backbone_peer_alb2>...

Wurde etwas an der Auflösung geändert, evtl. ein externer IPv6-DNS-Server gesetzt? Ich habe einen Dual-Stack-Anschluss von der Telekom. Aber generell kann ich von meinem PC aus problemlos Auflösungen auf IPv6 durchführen. Was muss ich hier anfassen?

jnsp · 10. November 2017 um 18:02

Liegt wohl an folgendem Bug

Wir haben in der Ortenau das gleiche Problem. Du kannst temporär in /tmp/resolv.conf einen anderen Nameserver eintragen, oder einfach ein stable release benutzen

warmsurfer · 10. November 2017 um 20:57

Danke für den Hinweis. Wenn ich in der Datei mein Gateway eintrage und mit
/etc/init.d/dnsmasq restart
den Dienst neustarte funktioniert die Auflösung wieder, wunderbar!

herrbett · 11. November 2017 um 19:45

Wichtig beim Debugging zu wissen ist auch, das wir zurzeit nur albufer0, 1 und 2 haben. Die anderen Hosts sind angelegt, lösen zur Zeit aber nicht auf.

Das ganze ermöglicht uns ohne Software Updates neue Gateways in Betrieb zu nehmen.