Keine Verbindung vom Offloader ins WAN

Moin zusammen,

ich habe einen Offloader (Download bei Freifunk Pinneberg) aufgesetzt, bekomme jedoch keine Verbindung ins Internet.
Ein im (W)LAN verbundenes Handy (Android) gibt immer die Meldeung „Verbunden, kein Internet“. Das Handy bekommt eine IP Adresse vom Offloader, DHCP im LAN scheint daher zu funktionieren (der Vollständigkeit halber: IP-Adresse des Handy = 192.168.0.103 / Gateway 192.168.0.254 / Subnetz 255.255.255.0 / DNS 192.168.0.254)

Auf dem Offloader angemeldet bekomme ich ebenfalls keine Verbindung zu irgendeinem Server. Mein Offloader hängt hinter einer Fritz-Box. In der Fritz Box habe ich den entsprechenden Anschluss komplett freigeschaltet. (Internet → Fritz.box → Offloader → Handy)
Der Offloader selbst ist mit einer Virtualbox-VM aufgebaut und hat eine statische IP (192.168.178.220).

Was muss ich ggf. noch konfigurieren, damit ich vom Offloader eine Internetverbindung bekomme?

Danke
Gerhard

Hier noch einige weitere Daten:

Der offloader hat folgende Interfaces:

$ vboxmanage showvminfo FreifunkHeinrichBoellStr | grep NIC
NIC 1:                       MAC: 080027917579, Attachment: Bridged Interface 'enp2s0', Cable connected: on, Trace: off (file: none), Type: 82540EM, Reported speed: 0 Mbps, Boot priority: 0, Promisc Policy: allow-vms, Bandwidth group: none
NIC 2:                       MAC: 08002793BF61, Attachment: Bridged Interface 'enp3s0', Cable connected: on, Trace: off (file: none), Type: 82540EM, Reported speed: 0 Mbps, Boot priority: 0, Promisc Policy: allow-vms, Bandwidth group: none
NIC 3:                       disabled
NIC 4:                       disabled
NIC 5:                       disabled
NIC 6:                       disabled
NIC 7:                       disabled
NIC 8:                       disabled
$

Am NIC2 (MAC xx:BF:61 / enp3s0) ist meine Fritzbox / das WAN, am NIC 1 das LAN

Auf dem Offloader sehe ich folg. Interfaces:

root@ffpi-elmshorn-heinrich-boell-str:~# 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: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop
    link/ether 72:1d:d9:76:15:3f brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-client qlen 1000
    link/ether 08:00:27:91:75:79 brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-wan qlen 1000
    link/ether 08:00:27:93:bf:61 brd ff:ff:ff:ff:ff:ff
5: teql0: <NOARP> mtu 1500 qdisc noop qlen 100
    link/void
6: br-client: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
    link/ether 08:00:27:91:75:79 brd ff:ff:ff:ff:ff:ff
    inet6 fde8:21c6:9d82:0:a00:27ff:fe91:7579/64 scope global dynamic
       valid_lft 86080sec preferred_lft 14080sec
    inet6 fe80::a00:27ff:fe91:7579/64 scope link
       valid_lft forever preferred_lft forever
7: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
    link/ether 4a:78:0c:40:f6:d8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.220/24 brd 192.168.178.255 scope global br-wan
       valid_lft forever preferred_lft forever
    inet6 fd00::4878:cff:fe40:f6d8/64 scope global dynamic
       valid_lft 7101sec preferred_lft 3501sec
    inet6 fe80::4878:cff:fe40:f6d8/64 scope link
       valid_lft forever preferred_lft forever
8: local-node@br-client: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
    link/ether 16:41:95:40:f7:dc brd ff:ff:ff:ff:ff:ff
    inet 10.137.0.1/16 brd 10.137.255.255 scope global local-node
       valid_lft forever preferred_lft forever
    inet6 fde8:21c6:9d82::1/128 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::1441:95ff:fe40:f7dc/64 scope link
       valid_lft forever preferred_lft forever
9: mesh-vpn: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1426 qdisc tbf master bat0 qlen 500
    link/ether 4a:78:0c:40:f6:df brd ff:ff:ff:ff:ff:ff
    inet6 fe80::4878:cff:fe40:f6df/64 scope link
       valid_lft forever preferred_lft forever
10: primary0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1532 qdisc noqueue master bat0
    link/ether 4a:78:0c:40:f6:db brd ff:ff:ff:ff:ff:ff
11: bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-client
    link/ether 08:00:27:91:75:79 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::a00:27ff:fe91:7579/64 scope link
       valid_lft forever preferred_lft forever
root@ffpi-elmshorn-heinrich-boell-str:~#

also eth1 = WAN, eth0 = LAN
Hinweis… Auf meiner Fritzbox ist die MAC-Adresse des BR-WAN freigegeben

Auf dem Offloader bekomme ich jedoch keine Internet-Verbindung:

root@ffpi-elmshorn-heinrich-boell-str:~# nslookup google.de
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

nslookup: can't resolve 'google.de': Name or service not known
root@ffpi-elmshorn-heinrich-boell-str:~# ping -c 3 142.250.181.195
PING 142.250.181.195 (142.250.181.195): 56 data bytes

--- 142.250.181.195 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
root@ffpi-elmshorn-heinrich-boell-str:~# # das ist die IP von google
root@ffpi-elmshorn-heinrich-boell-str:~# ping 192.168.178.1
PING 192.168.178.1 (192.168.178.1): 56 data bytes
^C
--- 192.168.178.1 ping statistics ---
11 packets transmitted, 0 packets received, 100% packet loss
root@ffpi-elmshorn-heinrich-boell-str:~# # meine fritz box
root@ffpi-elmshorn-heinrich-boell-str:~# arp -a
IP address       HW type     Flags       HW address            Mask     Device
192.168.178.1    0x1         0x0         1c:ed:6f:50:88:d1     *        br-wan
root@ffpi-elmshorn-heinrich-boell-str:~# ip route
default via 192.168.178.1 dev br-wan
10.137.0.0/16 dev local-node  src 10.137.0.1
192.168.178.0/24 dev br-wan  src 192.168.178.220
root@ffpi-elmshorn-heinrich-boell-str:~#

Firmware Version 0.9.1

Netzwerk/WAN-Konfiguration

root@ffpi-elmshorn-heinrich-boell-str:~# uci show network.wan
network.wan=interface
network.wan.ifname='eth1'
network.wan.multicast_querier='0'
network.wan.peerdns='0'
network.wan.auto='1'
network.wan.type='bridge'
network.wan.macaddr='4a:78:0c:40:f6:d8'
network.wan.proto='static'
network.wan.ipaddr='192.168.178.220'
network.wan.netmask='255.255.255.0'
network.wan.gateway='192.168.178.1'
root@ffpi-elmshorn-heinrich-boell-str:~#
  1. Ein Gluon-Knoten hat keine IPv4-Verbindung ins Mesh.
  2. 192er für Mesh ist eher ungewöhnlich? Typischerweise nehmen Freifunk-Gruppen bei Gluon größere Bereiche aus 10/8, also eher /22 bis /20 je Gateway, aus $Gründen.

Also die IP-Konfig auf dem Offloader sieht eigentlich gut aus. Ich würde daher ein Problem in der Konfiguration von vbox vermuten und mittels tcpdump auf dem Host überprüfen, ob was Richtung fritzbox tatsächlich raus geht. Vielleicht noch irgendwo NAT oder Firewall aktiv?

Eentuell auch mit logread mal schauen, ob mehr auffällt.

Das andere Merkwürdige ist die IP-Adresse die Dein Handy bekommen hat. Wie ist denn die Strecke zwischen dem virtuellem lan und dem physischen Handy? Ist da ein WLAN-Router beteiligt, der selbst IP-Adressen an Client vergibt?

1 „Gefällt mir“

Wenn man Gluon in VMs aufsetzt muss man der Virtuellen Maschine den Promiscous Mode auf dem Netzwerkinterface erlauben.
Das ist bei VirtualBox unter „erweitert“ und standardmäßig auf „verweigern“

Vielleicht liegt es daran?

1 „Gefällt mir“

Das ist ein dokumentiertes Thema bei VMWare; bei KVM ist mir dies nie auf die Füße gefallen? (Lies: gilt AFAICS nicht generell, sondern ist abhängig vom Hypervisor.)

EDIT: wollte mir das gerade mal ansehen, aber http:/­/pinneberg.freifunk.net/{anything} läuft mit Firefox 107.0.1 immer auf die gleiche Seite hinaus :frowning: (Nein, am Adblocker liegt’s nicht.) Odd.

Hast Du den letzten Schritt (»Dies ist der öffentliche Schlüssel deines Freifunkknotens. Erst nachdem er auf den Servern des Pinneberger Freifunk-Projektes eingetragen wurde, kann sich dein Knoten mit dem Pinneberger Mesh-VPN zu verbinden. Bitte schicke dazu diesen Schlüssel […]«) am Ende der Installation vorgenommen?

FFPI-FW 0.9.1 ist Gluon v2016; um die DNS-Server vom WAN-Uplink zu nutzen, muß die Anfrage von der Gruppe gluon-fastd gemacht werden:

root@ffpi-5254007877ce:~# /sbin/start-stop-daemon -c root:gluon-fastd -S -x nslookup google.de
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

Name:      google.de
Address 1: 2a00:1450:4001:803::2003 fra07s30-in-x2003.1e100.net
Address 2: 142.250.74.195 fra24s02-in-f3.1e100.net

Traceroute geht damit auch, aber Du mußt sicher nur IPv4-Adressen zurückbekommen vom DNS:

root@ffpi-5254007877ce:~# /sbin/start-stop-daemon -c root:gluon-fastd -S -x traceroute twitter.com
traceroute to twitter.com (104.244.42.193), 30 hops max, 46 byte packets
 1  fritz.box (192.168.175.1)  1.220 ms  1.093 ms  1.420 ms
 2  *  *  *
 3  de-gut01a-cr01-eth-6-0-1410.gut.unity-media.net (81.210.137.138)  36.451 ms  20.596 ms  32.767 ms
 4  de-fra01b-rc2-ae-65-0.aorta.net (84.116.191.125)  31.330 ms  25.463 ms  51.253 ms
 5  de-bfe18a-rt01-lag-1.aorta.net (84.116.190.34)  31.894 ms  23.674 ms  33.039 ms
 6  cr1-fra1.twttr.com (80.81.192.10)  43.715 ms  46.737 ms  20.440 ms
 7  104.244.42.193 (104.244.42.193)  27.501 ms  16.868 ms  34.332 ms
root@ffpi-5254007877ce:~# /sbin/start-stop-daemon -c root:gluon-fastd -S -x traceroute google.com
traceroute to google.com (2a00:1450:4001:831::200e), 30 hops max, 46 byte packets
 1traceroute: sendto: Address family not supported by protocol

Dein Ping tut bei mir allerdings:

root@ffpi-5254007877ce:~# ping -c 3 142.250.181.195
PING 142.250.181.195 (142.250.181.195): 56 data bytes
64 bytes from 142.250.181.195: seq=0 ttl=114 time=28.511 ms
64 bytes from 142.250.181.195: seq=1 ttl=114 time=23.723 ms
64 bytes from 142.250.181.195: seq=2 ttl=114 time=26.774 ms

--- 142.250.181.195 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 23.723/26.336/28.511 ms

Ich nutze aber auch KVM und nicht VirtualBox. Ggf. die Promisc-Einstellungen in VirtualBox checken, wie schon geschrieben wurde.

Wie schon gefragt wurde: vergibt Dein Accesspoint hinter dem Offloader IPs aus 192.168.0.0/24? Weil FFPI nutzt im Mesh 10.137.0.0/16, siehe local-node@br-client. Ohne Verbindung zum Mesh bekommst Du in einem Gluon-(batman-)Netz i. d. R. keine IPv4-Adresse zugewiesen; dies macht das Gateway, nicht der lokale Gluon-Knoten. Das scheint auch bei FFPI 0.9.1 nicht anders zu sein.

Ist Dein Knoten denn verbunden? Meiner nicht, ich habe aber auch den fastd-Schlüssel nicht eingesandt …

root@ffpi-5254007877ce:~# batctl gwl
      Gateway      (#/255)           Nexthop [outgoingIF]: advertised uplink bandwidth ... [B.A.T.M.A.N. adv 2016.2, MainIF/MAC: primary0/e2:4c:0c:2a:2b:2b (bat0)]
No gateways in range ...

Ansonsten ist noch logread ggf. hilfreich:

root@ffpi-5254007877ce:~# logread | tail -20
Wed Dec 21 04:10:23 2022 daemon.info fastd[1956]: resolving host `gate03.freifunk-pinneberg.de' for peer <mesh_vpn_backbone_peer_gate03>...
Wed Dec 21 04:10:23 2022 daemon.info fastd[1956]: resolved host `gate03.freifunk-pinneberg.de' successfully
Wed Dec 21 04:10:30 2022 daemon.info fastd[1956]: sending handshake to <mesh_vpn_backbone_peer_gate05>[217.172.186.141:10000]...
Wed Dec 21 04:10:30 2022 daemon.info fastd[1956]: resolving host `gate05.freifunk-pinneberg.de' for peer <mesh_vpn_backbone_peer_gate05>...
Wed Dec 21 04:10:30 2022 daemon.info fastd[1956]: resolved host `gate05.freifunk-pinneberg.de' successfully
Wed Dec 21 04:10:35 2022 daemon.info fastd[1956]: sending handshake to <mesh_vpn_backbone_peer_gate01>[81.7.14.115:10000]...
Wed Dec 21 04:10:35 2022 daemon.info fastd[1956]: resolving host `gate01.freifunk-pinneberg.de' for peer <mesh_vpn_backbone_peer_gate01>...
Wed Dec 21 04:10:35 2022 daemon.info fastd[1956]: resolved host `gate01.freifunk-pinneberg.de' successfully
Wed Dec 21 04:10:38 2022 daemon.info fastd[1956]: sending handshake to <mesh_vpn_backbone_peer_gate04>[213.133.108.18:10000]...
Wed Dec 21 04:10:38 2022 daemon.info fastd[1956]: resolving host `gate04.pinneberg.freifunk.net' for peer <mesh_vpn_backbone_peer_gate04>...
Wed Dec 21 04:10:38 2022 daemon.info fastd[1956]: resolved host `gate04.pinneberg.freifunk.net' successfully
Wed Dec 21 04:10:44 2022 daemon.info fastd[1956]: sending handshake to <mesh_vpn_backbone_peer_gate03>[85.114.135.191:10000]...
Wed Dec 21 04:10:44 2022 daemon.info fastd[1956]: resolving host `gate03.hoogi.de' for peer <mesh_vpn_backbone_peer_gate03>...
Wed Dec 21 04:10:44 2022 daemon.info fastd[1956]: resolved host `gate03.hoogi.de' successfully
Wed Dec 21 04:10:52 2022 daemon.info fastd[1956]: sending handshake to <mesh_vpn_backbone_peer_gate05>[217.172.186.141:10000]...
Wed Dec 21 04:10:52 2022 daemon.info fastd[1956]: resolving host `gate05.hoogi.de' for peer <mesh_vpn_backbone_peer_gate05>...
Wed Dec 21 04:10:52 2022 daemon.info fastd[1956]: resolved host `gate05.hoogi.de' successfully
Wed Dec 21 04:10:54 2022 daemon.info fastd[1956]: sending handshake to <mesh_vpn_backbone_peer_gate01>[81.7.14.115:10000]...
Wed Dec 21 04:10:54 2022 daemon.info fastd[1956]: resolving host `gate01.hoogi.de' for peer <mesh_vpn_backbone_peer_gate01>...
Wed Dec 21 04:10:54 2022 daemon.info fastd[1956]: resolved host `gate01.hoogi.de' successfully

Die fastd-Peers antworten meinem Knoten (Offloader) nicht, IIRC das typische Verhalten von fastd bei »geh’ weg, ich kenn’ Dich nicht!« (sofern man die Peers anpingen kann).

Danke für die vielen Antworten.

@rotanid @wusel … das mit dem Promiscous mode habe ich auch schon gelesen, muss aber gestehen, dass ich bis heute nicht ganz verstanden habe was da passiert. An dieser Einstellung habe ich in Virtualbox auch schon Änderungen vorgenommen, aber kein geändertes Verahlten bemerkt. Sicherheitshalber habe ich den Promiscous-Mode jetzt auf „erlauben für allen VMs und den Host“ gestellt.
Danch konnte ich aber wiederum keine Änderung feststellen. ping google funktionierte nicht

@wusel zu deinem Hinweis bzgl. der Gruppe gloun-fastd.

/sbin/start-stop-daemon -c root:gluon-fastd -S -x nslookup google.de

Ich habe keine Idee, was da jetzt passiert ist. Nachdem ich diesen Befehl eingegeben habe, wurde meine ssh-Session beendet (warum auch immer). Nach dem erneuten anmelden kommt das openWrt-Banner. Bisher war unter dem Banner immer ein Getränke-Rezept, das ist jetzt nicht mehr da.
Und interessanterweise funktioniert jetzt auch der ping …


BusyBox v1.28.4 () built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 18.06-SNAPSHOT, r8077+27-7cbbab7246
 -----------------------------------------------------
root@ffpi-elmshorn-heinrich-boell-str:~# 
root@ffpi-elmshorn-heinrich-boell-str:~# ping -c 2 google.de
PING google.de (142.250.179.195): 56 data bytes
64 bytes from 142.250.179.195: seq=0 ttl=117 time=13.270 ms
64 bytes from 142.250.179.195: seq=1 ttl=117 time=11.744 ms

--- google.de ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 11.744/12.507/13.270 ms
root@ffpi-elmshorn-heinrich-boell-str:~#
root@ffpi-elmshorn-heinrich-boell-str:~# batctl gwl
[B.A.T.M.A.N. adv openwrt-2018.1-13, MainIF/MAC: primary0/4a:78:0c:40:f6:db (bat0/08:00:27:91:75:79 BATMAN_IV)]
  Router            ( TQ) Next Hop          [outgoingIf]  Bandwidth
  4a:02:9e:2f:eb:62 (221) be:21:52:f9:95:64 [  mesh-vpn]: 1000.0/1000.0 MBit
  a2:f3:f7:e2:59:3f (221) be:21:52:f9:95:64 [  mesh-vpn]: 100.0/100.0 MBit
* be:21:52:f9:95:64 (251) be:21:52:f9:95:64 [  mesh-vpn]: 100.0/100.0 MBit
  1a:32:b5:98:23:92 (221) be:21:52:f9:95:64 [  mesh-vpn]: 1000.0/1000.0 MBit
root@ffpi-elmshorn-heinrich-boell-str:~#

Mein Handy bekommt jetzt auch eine 10.137/er IP-Adresse und auch Internet. Wie schon oben erwähnt ist mir nicht klar, was da passiert ist.
Aber trotzdem vielen Dank.

Dein Knoten hat sich auf eine neuere Firmware aktualisiert …

EDIT: da AFAICS autoupdater keine DNS-Auflösung hat ohne Mesh, wurde vermutlich Dein fastd-Key erst jetzt auf die Gateways verteilt, dadurch konnte der Autoupdater sich dann, nach Herstellung der Verbindung ins Freifunk-Netz, eine neue Liste holen und feststellen, daß es eine neuere Version gibt und auf jene aktualisieren.

du hattest irgendeine seeehr alte Firmware benutzt…

nun ja, das was auf der ffpi-Webseite angeboten wurde: x86-64-virtualbox → 0.9.1