<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi,</p>
<p>so, es funktioniert nun alles. Falls sonst mal jemand ein
ähnliches Problem hat, hier ein paar Worte dazu:<br>
</p>
<p>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.</p>
<p>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.<br>
</p>
<p>Also habe ich ein weiteres Interface hinzugefügt und dieses im
Configfile /etc/config/network an die entsprechende Bridge
gebunden.</p>
<p><img src="cid:part1.3EFC9E3A.E60F1A7E@litzinetz.de" alt="">
</p>
<p>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.</p>
<p>So far - danke für euren Input!</p>
<p>Gruß</p>
<p>Daniel<br>
</p>
<br>
<div class="moz-cite-prefix">On 27.02.2017 21:29, Daniel Litzbach
wrote:<br>
</div>
<blockquote
cite="mid:9a90cb11-c899-78a8-0cfd-81557f230adb@litzinetz.de"
type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<p>Hi all,</p>
<p>sorry, ich muss euch nochmal wegen dem Offloader behelligen.</p>
<p>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.</p>
<p>Auf meinem Endgerät:</p>
<p>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<br>
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<br>
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<br>
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<br>
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<br>
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<br>
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<br>
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<br>
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<br>
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<br>
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<br>
</p>
<p>Die DHCP-Anfrage geht Richtung Offloader raus.<br>
</p>
<p>Der Request kommt am Offloader auch an, ich kann ihn im tcpdump
auf eth0 sehen... Allerdings wird er nicht beantwortet.<br>
</p>
<br>
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?<br>
<br>
Die Portgruppe habe ich gecheckt:<br>
<br>
<img shrinktofit="true"
src="cid:part2.3D4E06E7.6E7F3ECC@litzinetz.de" alt=""><br>
<br>
...jemand eine Idee? :-/<br>
<br>
Danke und Gruß<br>
<br>
Daniel<br>
<div class="moz-cite-prefix">On 26.02.2017 21:21, Daniel Litzbach
wrote:<br>
</div>
<blockquote
cite="mid:2535fa78-33e8-2e2a-fe03-ab2f035c3f8a@litzinetz.de"
type="cite">
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
<p>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 :)</p>
<p>Schönen Abend zusammen!<br>
</p>
<br>
<div class="moz-cite-prefix">On 26.02.2017 21:07, Erik Tews
wrote:<br>
</div>
<blockquote
cite="mid:28C207D9-BAB4-48FF-9320-C6435C9D3EAA@datenzone.de"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
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.<br>
<br>
<div class="gmail_quote">Am 26. Februar 2017 20:35:38 MEZ
schrieb Daniel Litzbach <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:dl@litzinetz.de"><dl@litzinetz.de></a>:
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;"> Hi,<br>
<br>
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...<br>
<br>
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.<br>
<br>
Gruß<br>
<br>
<div class="gmail_quote">Am 26. Februar 2017 20:32:13 MEZ
schrieb Erik Tews <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:erik@datenzone.de"><erik@datenzone.de></a>:
<blockquote class="gmail_quote" style="margin: 0pt 0pt
0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;"> 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.<br>
<br>
Gruß Erik<br>
<br>
<div class="gmail_quote">Am 26. Februar 2017 20:14:55
MEZ schrieb Daniel Litzbach <a
moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:dl@litzinetz.de"><dl@litzinetz.de></a>:
<blockquote class="gmail_quote" style="margin: 0pt
0pt 0pt 0.8ex; border-left: 1px solid rgb(204,
204, 204); padding-left: 1ex;">
<p>Hi all,<br>
<br>
ich habe ein kleines Problem mit einem neu
aufgesetzten Offloader und hoffe, Ihr könnt mit
weiterhelfen.<br>
<br>
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:<br>
<br>
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:<br>
<br>
<font face="Courier 10 Pitch">20:03:54.647120
ARP, Request who-has 10.226.181.1 tell
10.226.181.19, length 46<br>
20:03:54.647145 ARP, Reply 10.226.181.1 is-at
00:0c:29:44:f6:2a, length 28<br>
20:03:55.647297 ARP, Request who-has
10.226.181.1 tell 10.226.181.19, length 46<br>
20:03:55.647326 ARP, Reply 10.226.181.1 is-at
00:0c:29:44:f6:2a, length 28<br>
20:03:57.937366 ARP, Request who-has
10.226.181.1 tell 10.226.181.19, length 46<br>
20:03:57.937387 ARP, Reply 10.226.181.1 is-at
00:0c:29:44:f6:2a, length 28<br>
20:03:58.937125 ARP, Request who-has
10.226.181.1 tell 10.226.181.19, length 46<br>
20:03:58.937157 ARP, Reply 10.226.181.1 is-at
00:0c:29:44:f6:2a, length 28<br>
20:03:59.937418 ARP, Request who-has
10.226.181.1 tell 10.226.181.19, length 46<br>
20:03:59.937452 ARP, Reply 10.226.181.1 is-at
00:0c:29:44:f6:2a, length 28</font><br>
<br>
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.<br>
<br>
Danke für euren Input.<br>
<br>
Gruß</p>
</blockquote>
</div>
<br>
</blockquote>
</div>
<br>
</blockquote>
</div>
<br>
-- <br>
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail
gesendet. </blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</body>
</html>