[ffda] Problem mit Offloader

Daniel Litzbach dl at litzinetz.de
Di Feb 28 18:08:59 CET 2017


Hi,

so, es funktioniert nun alles. Falls sonst mal jemand ein ähnliches
Problem hat, hier ein paar Worte dazu:

Zunächst mal scheint Gluon die virtuellen E1000-Interfaces nicht zu
mögen - die waren nach einem Reboot immer weg :-/ Umstellung auf VMXNET
3 scheint zu helfen.

Zum eigentlichen Problem: So wie ich es verstanden hatte, ist der
Betrieb des Offloaders mit zwei Interfaces vorgesehen - einem externen
für den Tunnelaufbau und einem internen zum Meshen. Dazu gibt es extern
wie intern eine Bridge, in der das entsprechende Interface gebunden ist.
Per default befindet sich das interne Interface also in der
meshing-bridge. Ich war davon ausgegangen, dass meshing sowie
Freifunk-Netz über dieselbe Bridge laufen - scheint nicht so zu sein! In
der meshing-Bridge wird wirklich nur gemesht. In der client-Bridge
hingegen, die wohl NICHT an ein Interface gebunden ist, läuft der
eigentliche Freifunk-Traffic. Das ist kein Problem, wenn der Offloader
wirklich ein Offloader sein soll - also lediglich die Backbone-Anbindung
für weitere APs bereitstellt. In meinem Fall aber soll er viel mehr ein
Gateway sein, an das ich meine Firewall anbinde, um aus meinem privaten
Netz das Freifunk-Netz (Masquerading-NAT) erreichen zu können sowie um
später auch Dienste auf dem ESX bereitstellen zu können. Da reicht das
meshing nicht mehr aus, ich brauche einen direkten Zugang zum
Freifunk-Netz ohne weitere Knoten, nur mit dem Offloader.

Also habe ich ein weiteres Interface hinzugefügt und dieses im
Configfile /etc/config/network an die entsprechende Bridge gebunden.

Der Eintrag "option ifname eth2" bindet das Interface an die Bridge.
Dieses Interface befindet sich nun zusammen mit einem Interface meiner
Firewall auf einem vSwitch und siehe da - die Firewall bekommt eine IP.
Das Meshing-Interface steckt momentan in einem Blackhole-Netz, da ich es
nicht brauche. Falls es aber mal benötigt wird, kann es auf einen
Ethernet-Port des ESX gelegt oder als VLAN rausgetaggt werden.

So far - danke für euren Input!

Gruß

Daniel


On 27.02.2017 21:29, Daniel Litzbach wrote:
>
> Hi all,
>
> sorry, ich muss euch nochmal wegen dem Offloader behelligen.
>
> Er ist nun online und auch auf der Karte zu sehen. Am internen
> Interface (das Freifunk-Netz, also nicht das WAN-Interface über das
> der Tunnel aufgebaut wird) sollte mein Endgerät ja nun eingentlich via
> DHCP eine IP vom Freifunk-Netz bekommen, richtig? Broadcast-Traffic
> sehe ich jede Menge, aber mein DHCP-Request wird nicht beantwortet.
>
> Auf meinem Endgerät:
>
> 17:57:27.636497 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
> Request from 00:0c:29:44:f6:3e, length 300
> 17:57:30.821137 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
> Request from 00:0c:29:44:f6:3e, length 300
> 17:57:34.097645 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
> Request from 00:0c:29:44:f6:3e, length 300
> 17:57:41.522161 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
> Request from 00:0c:29:44:f6:3e, length 300
> 17:57:50.530076 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
> Request from 00:0c:29:44:f6:3e, length 300
> 17:57:54.550193 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
> Request from 00:0c:29:44:f6:3e, length 300
> 17:57:59.335007 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
> Request from 00:0c:29:44:f6:3e, length 300
> 17:59:21.163281 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
> Request from 00:0c:29:44:f6:3e, length 300
> 17:59:27.355334 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
> Request from 00:0c:29:44:f6:3e, length 300
> 17:59:34.234201 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
> Request from 00:0c:29:44:f6:3e, length 300
> 18:00:40.080056 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
> Request from 00:0c:29:44:f6:3e, length 300
>
> Die DHCP-Anfrage geht Richtung Offloader raus.
>
> Der Request kommt am Offloader auch an, ich kann ihn im tcpdump auf
> eth0 sehen... Allerdings wird er nicht beantwortet.
>
>
> Muss ich auf den bridge-port dumpen anstelle von eth0? Auf eth0 sehe
> ich jedenfalls die Broadcasts aus dem FF-Netz wenn ich die Filter für
> DHCP weglasse, also sollte das doch eigentlich stimmen, oder?
>
> Die Portgruppe habe ich gecheckt:
>
>
>
> ...jemand eine Idee? :-/
>
> Danke und Gruß
>
> Daniel
> On 26.02.2017 21:21, Daniel Litzbach wrote:
>>
>> Danke für eure Antworten. Dank Andreas hab ich die Lösung aber schon
>> - der ESX war schuld. Bzw. eigentlich ich, weil ich zu dämlich war
>> die Port Security in der Portgruppe richtig zu konfigurieren :)
>>
>> Schönen Abend zusammen!
>>
>>
>> On 26.02.2017 21:07, Erik Tews wrote:
>>> Das geht mit opkg in etwa genau so gut wie mit dpkg, die
>>> Abhängigkeiten musst du von Hand auflösen, nach so 15 Minuten
>>> fummelei sollte es gehen. Alternativ wenn ssh geht eventuell per SSH
>>> zu einem http Proxy Port forwarding machen und das so installieren.
>>>
>>> Am 26. Februar 2017 20:35:38 MEZ schrieb Daniel Litzbach
>>> <dl at litzinetz.de>:
>>>
>>>     Hi,
>>>
>>>     danke für deine Antwort. Stimmt, ich kann die ARP-Table checken.
>>>     Mach ich gleich mal. Denke aber, dass die leer sein wird, sonst
>>>     würde er ja nicht ständig broadcasten...
>>>
>>>     opkg ist schwierig ohne Verbindung :) oder kann ich Pakete auch
>>>     manuell via SCP draufladen und installieren? Komme aus der
>>>     Debian-Welt, da ist das mit dpkg ja kein Problem.
>>>
>>>     Gruß
>>>
>>>     Am 26. Februar 2017 20:32:13 MEZ schrieb Erik Tews
>>>     <erik at datenzone.de>:
>>>
>>>         Hi, zumindest ob sie richtig interpretiert werden kannst du
>>>         glaube ich auch mit arp bzw. im proc Dateisystem
>>>         herausfinden, für openwrt gibt es auch tcpdump, das kann mit
>>>         opkg installiert werden.
>>>
>>>         Gruß Erik
>>>
>>>         Am 26. Februar 2017 20:14:55 MEZ schrieb Daniel Litzbach
>>>         <dl at litzinetz.de>:
>>>
>>>             Hi all,
>>>
>>>             ich habe ein kleines Problem mit einem neu aufgesetzten
>>>             Offloader und hoffe, Ihr könnt mit weiterhelfen.
>>>
>>>             Der Offloader wurde auf einem VMWare ESXi installiert
>>>             (VMDK-Image von der FFDA-Website), hat zwei Interfaces
>>>             und bootet auch sauber hoch. Ich kann die
>>>             Konfigurationspage über 192.168.1.1 erreichen, alles in
>>>             Ordnung. Nun das Problem:
>>>
>>>             Ich habe dem Offloader eine feste IP (10.226.181.19 bzw.
>>>             fd00:6151:aff3:1337::19) in meinem LAN konfiguriert. Das
>>>             Gateway ist 10.226.181.1 bzw. fd00:6151:aff3:1337::1. Um
>>>             sicherzugehen, dass ich die Interfaces des Offloaders
>>>             auf dem ESX nicht falsch zuordne, habe ich erstmal beide
>>>             ins interne Netz gesteckt. So sollte der Offloader auf
>>>             jeden Fall eine Verbindung bekommen. Tut er aber nicht.
>>>             Auch über DHCP bezieht er keine IP. Auf meinem Gateway
>>>             sehe ich nun folgendes im tcpdump:
>>>
>>>             20:03:54.647120 ARP, Request who-has 10.226.181.1 tell
>>>             10.226.181.19, length 46
>>>             20:03:54.647145 ARP, Reply 10.226.181.1 is-at
>>>             00:0c:29:44:f6:2a, length 28
>>>             20:03:55.647297 ARP, Request who-has 10.226.181.1 tell
>>>             10.226.181.19, length 46
>>>             20:03:55.647326 ARP, Reply 10.226.181.1 is-at
>>>             00:0c:29:44:f6:2a, length 28
>>>             20:03:57.937366 ARP, Request who-has 10.226.181.1 tell
>>>             10.226.181.19, length 46
>>>             20:03:57.937387 ARP, Reply 10.226.181.1 is-at
>>>             00:0c:29:44:f6:2a, length 28
>>>             20:03:58.937125 ARP, Request who-has 10.226.181.1 tell
>>>             10.226.181.19, length 46
>>>             20:03:58.937157 ARP, Reply 10.226.181.1 is-at
>>>             00:0c:29:44:f6:2a, length 28
>>>             20:03:59.937418 ARP, Request who-has 10.226.181.1 tell
>>>             10.226.181.19, length 46
>>>             20:03:59.937452 ARP, Reply 10.226.181.1 is-at
>>>             00:0c:29:44:f6:2a, length 28
>>>
>>>             Der Offloader fragt also nach der MAC des Gateways, da
>>>             er darüber ins Internet möchte um seinen Tunnel
>>>             aufzubauen. Er bekommt auch eine Antwort - und fragt
>>>             dann erneut. Hat jemand von euch eine Idee, wieso? In
>>>             gluon scheint es keinen tcpdump zu geben, aber eventuell
>>>             ein anderes Tool zum debuggen? Würde gerne sehen, ob die
>>>             ARP-Replys am Offloader auch ankommen.
>>>
>>>             Danke für euren Input.
>>>
>>>             Gruß
>>>
>>>
>>>
>>>
>>> -- 
>>> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. 
>>
>>
>>
>
>
>

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.freifunk.net/pipermail/darmstadt-freifunk.net/attachments/20170228/c9ae8fb8/attachment.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : mpldhemdkcekghlj.png
Dateityp    : image/png
Dateigröße  : 31860 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.freifunk.net/pipermail/darmstadt-freifunk.net/attachments/20170228/c9ae8fb8/attachment.png>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : image/png
Dateigröße  : 3984 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.freifunk.net/pipermail/darmstadt-freifunk.net/attachments/20170228/c9ae8fb8/attachment-0001.png>


Mehr Informationen über die Mailingliste darmstadt