Keine Verbindung nach Firmware-Update

Lyve · 19. Dezember 2018 um 22:17

Hallo zusammen,

ich wurde netterweise von @CyrusFox darauf hingewiesen, dass mein Knoten veraltet sei und habe ihn daher heute aktualisiert. Leider konnte ich keine Verbindung mehr herstellen, daher habe ich alles gelöscht und den Knoten komplett neu aufgesetzt. Leider habe ich immer noch keine Verbindung.

Hinweis: Ich betreibe gluon-ddorf-v1.6.3-113-x86-generic auf einem VMware ESX Host. Das Ziel ist, Leuten freies WLAN in Allerheiligen durch mein Internet zur Verfügung zu stellen. Andere Knoten sind nicht in Reichweite.

Nach allem was ich mir so im Netz ergoogeln konnte scheine ich ein völlig anderes Problem zu haben, das sonst niemand hat

Symptome sind:

br-wan hat eine IP erhalten, hat also Internet, über SSH komme ich rein und ein ping auf der Konsole an z.B. 8.8.8.8 funktioniert, die Namensauflösung funktioniert aber z.B. nicht, ein ping google.de schlägt fehlt. Habe aber gelesen das sei normal.
cat /var/log/lastlog ist leer
/lib/gluon/site.conf existiert nicht, die wurde auf mehreren Seiten erwähnt
batctl o / batctl gwl zeigen beiden eine leere Liste
Clients, die sich per WLAN verbinden erhalten keine IP-Adresse, offenbar läuft kein DHCP-Server

Hier die Ausgabe von logread:

Wed Dec 19 23:04:24 2018 daemon.info dnsmasq[3392]: started, version 2.78 cachesize 150
Wed Dec 19 23:04:24 2018 daemon.info dnsmasq[3392]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC no-ID loop-detect inotify
Wed Dec 19 23:04:24 2018 daemon.info dnsmasq[3392]: using local addresses only for domain lan
Wed Dec 19 23:04:24 2018 daemon.warn dnsmasq[3392]: no servers found in /tmp/resolv.conf.auto, will retry
Wed Dec 19 23:04:24 2018 daemon.info dnsmasq[3392]: read /etc/hosts - 4 addresses
Wed Dec 19 23:04:24 2018 daemon.info dnsmasq[3392]: read /tmp/hosts/dhcp.cfg02411c - 0 addresses
Wed Dec 19 23:04:30 2018 kern.info kernel: [ 16.990640] batman_adv: bat0: IGMP Querier appeared
Wed Dec 19 23:04:30 2018 kern.info kernel: [ 16.990994] batman_adv: bat0: MLD Querier appeared
Wed Dec 19 23:04:30 2018 daemon.info td-client: Selected vpn02-dom3.freifunk-neuss.de:12003 as the best broker.
Wed Dec 19 23:04:31 2018 daemon.info td-client: Tunnel successfully established.
Wed Dec 19 23:04:31 2018 daemon.notice netifd: Interface ‚mesh_vpn‘ is enabled
Wed Dec 19 23:04:31 2018 daemon.notice netifd: Network device ‚mesh-vpn‘ link is up
Wed Dec 19 23:04:31 2018 daemon.notice netifd: Interface ‚mesh_vpn‘ has link connectivity
Wed Dec 19 23:04:31 2018 daemon.notice netifd: Interface ‚mesh_vpn‘ is setting up now
Wed Dec 19 23:04:31 2018 daemon.notice netifd: Interface ‚mesh_vpn‘ is now up
Wed Dec 19 23:04:32 2018 kern.info kernel: [ 18.919348] batman_adv: bat0: Adding interface: mesh-vpn
Wed Dec 19 23:04:32 2018 kern.info kernel: [ 18.919693] batman_adv: bat0: The MTU of interface mesh-vpn is too small (1364) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
Wed Dec 19 23:04:32 2018 kern.info kernel: [ 18.920987] batman_adv: bat0: Interface activated: mesh-vpn
Wed Dec 19 23:04:32 2018 user.notice firewall: Reloading firewall due to ifup of mesh_vpn (mesh-vpn)
Wed Dec 19 23:04:34 2018 daemon.notice netifd: Interface ‚client‘ is now up
Wed Dec 19 23:04:34 2018 user.notice firewall: Reloading firewall due to ifup of client (br-client)
Wed Dec 19 23:04:46 2018 kern.notice kernel: [ 33.350930] random: nonblocking pool is initialized
Wed Dec 19 23:05:00 2018 daemon.warn td-client: Got termination signal, shutting down tunnel…
Wed Dec 19 23:05:00 2018 daemon.notice netifd: Network device ‚mesh-vpn‘ link is down
Wed Dec 19 23:05:00 2018 daemon.notice netifd: Interface ‚mesh_vpn‘ has link connectivity loss
Wed Dec 19 23:05:00 2018 kern.info kernel: [ 47.806555] batman_adv: bat0: Interface deactivated: mesh-vpn
Wed Dec 19 23:05:00 2018 kern.info kernel: [ 47.807377] batman_adv: bat0: Removing interface: mesh-vpn
Wed Dec 19 23:05:00 2018 daemon.notice netifd: Interface ‚mesh_vpn‘ is disabled
Wed Dec 19 23:05:07 2018 user.notice tunneldiger-watchdog: No neighbours on mesh-vpn interface, restarted tunneldigger.
Wed Dec 19 23:05:07 2018 daemon.info td-client: Performing broker selection…
Wed Dec 19 23:05:09 2018 daemon.debug td-client: Broker usage of vpn01-dom3.freifunk-neuss.de:12003: 2293
Wed Dec 19 23:05:09 2018 daemon.debug td-client: Broker usage of vpn02-dom3.freifunk-neuss.de:12003: 1638
Wed Dec 19 23:05:18 2018 daemon.info td-client: Selected vpn02-dom3.freifunk-neuss.de:12003 as the best broker.
Wed Dec 19 23:05:19 2018 daemon.info td-client: Tunnel successfully established.
Wed Dec 19 23:05:19 2018 daemon.notice netifd: Interface ‚mesh_vpn‘ is enabled
Wed Dec 19 23:05:19 2018 daemon.notice netifd: Network device ‚mesh-vpn‘ link is up
Wed Dec 19 23:05:19 2018 daemon.notice netifd: Interface ‚mesh_vpn‘ has link connectivity
Wed Dec 19 23:05:19 2018 daemon.notice netifd: Interface ‚mesh_vpn‘ is setting up now
Wed Dec 19 23:05:19 2018 daemon.notice netifd: Interface ‚mesh_vpn‘ is now up
Wed Dec 19 23:05:19 2018 kern.info kernel: [ 66.398079] batman_adv: bat0: Adding interface: mesh-vpn
Wed Dec 19 23:05:19 2018 kern.info kernel: [ 66.398458] batman_adv: bat0: The MTU of interface mesh-vpn is too small (1364) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
Wed Dec 19 23:05:19 2018 kern.info kernel: [ 66.399808] batman_adv: bat0: Interface activated: mesh-vpn
Wed Dec 19 23:05:19 2018 user.notice firewall: Reloading firewall due to ifup of mesh_vpn (mesh-vpn)

Ich weiß irgendwie einfach gar nicht wo ich anfangen soll zu suchen. „td-client: Tunnel successfully established.“ hört sich erstmal irgendwie richtig an, aber mir ist schleierhaft, warum ich dann keine Internet-Adressen von der Konsole erreiche und warum auf dem Client-Netz kein DHCP läuft, damit WLAN-Clients eine IP-Adresse erhalten.

Sind die Tunneladressen für Düsseldorf / Neuss denn richtig? Ich hatte irgendwie erwartet, dass dort weniger Neuss und mehr Düsseldorf steht

Vielen Dank für Hilfe!

Nils

Lyve · 20. Dezember 2018 um 20:01

Hier mal die Ausgabe von ip a:

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 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: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 26:b1:99:5b:26:4a brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-client state UP qlen 1000
link/ether 00:0c:29:d9:0a:a3 brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-wan state UP qlen 1000
link/ether 00:0c:29:d9:0a:ad brd ff:ff:ff:ff:ff:ff
5: teql0: mtu 1500 qdisc noop state DOWN qlen 100
link/void
6: br-client: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 00:0c:29:d9:0a:a3 brd ff:ff:ff:ff:ff:ff
inet6 fd00:ff30:13::20c:29ff:fed9:aa3/64 scope global dynamic
valid_lft 86103sec preferred_lft 14103sec
inet6 fe80::20c:29ff:fed9:aa3/64 scope link
valid_lft forever preferred_lft forever
7: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 4e:6c:03:e0:60:70 brd ff:ff:ff:ff:ff:ff
inet 192.168.21.132/24 brd 192.168.21.255 scope global br-wan
valid_lft forever preferred_lft forever
inet6 fe80::4c6c:3ff:fee0:6070/64 scope link
valid_lft forever preferred_lft forever
8: local-port@local-node: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-client state UP qlen 1000
link/ether 00:0c:29:d9:0a:a3 brd ff:ff:ff:ff:ff:ff
9: local-node@local-port: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 16:41:95:40:f7:13 brd ff:ff:ff:ff:ff:ff
inet 10.30.95.254/20 brd 10.30.95.255 scope global local-node
valid_lft forever preferred_lft forever
inet6 fd00:ff30:13::ffff/128 scope global deprecated
valid_lft forever preferred_lft 0sec
inet6 fe80::1441:95ff:fe40:f713/64 scope link
valid_lft forever preferred_lft forever
10: primary0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1532 qdisc noqueue master bat0 state UNKNOWN qlen 1000
link/ether 4e:6c:03:e0:60:73 brd ff:ff:ff:ff:ff:ff
inet6 fe80::4c6c:3ff:fee0:6073/64 scope link
valid_lft forever preferred_lft forever
11: bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-client state UNKNOWN qlen 1000
link/ether 00:0c:29:d9:0a:a3 brd ff:ff:ff:ff:ff:ff
inet6 fe80::20c:29ff:fed9:aa3/64 scope link
valid_lft forever preferred_lft forever
21: mesh-vpn: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1364 qdisc fq_codel master bat0 state UNKNOWN qlen 1000
link/ether 4e:6c:03:e0:60:77 brd ff:ff:ff:ff:ff:ff
inet6 fe80::4c6c:3ff:fee0:6077/64 scope link
valid_lft forever preferred_lft forever

Lyve · 20. Dezember 2018 um 20:09

Noch ein paar Dinge, die ich nicht verstehe.

Desöfteren wird erwähnt, dass man versuchen soll ein „next_node“ zu pingen. Das soll angeblich in der site.json versteckt sein, bei mir jedoch gibt es diese Einträge nicht. Weiß da jemand Rat?

Auch seltsam ist, dass ich keinerlei Einträge unter uci show für fastd sehe.

Da ich gelesen habe, dass dieser Output auch oft angefragt wird:

batctl if
primary0: active
mesh-vpn: active

nomaster · 5. Januar 2019 um 11:56

For the record: das Problem wurde mittlerweile gelöst. Im Chat kam heraus, dass eine Fehlkonfiguration Probleme verursacht fast, wegen der wie die MAC-Adresse des Systems auf eine Blacklist setzen mussten. Sie wurde nun frei gegeben.