[ffda] Problem mit Offloader

[Erik Tews]

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.
>
>-- 
>Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>gesendet.

-- 
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/20170226/08ce69ec/attachment.html>