Alfred macke

[Dominik Heidler]

Hi,

ich habe das Problem jetzt mal reproduziert und dabei gleich mal einen
FASTD Dissector für Wireshark geschrieben [1] (einen ALFRED Dissector
gab es zub Glück schon [2]).

Wenn man mit Alfred die id 64 abfragt, wird der ALFRED_REQUEST per UDP
an den Master geschickt, der daraufhin antwortet. Der Master Packt so
viele "Facts" (=Die Infos zur ID x über genau einen Router) wie möglich
in je ein PUSH Paket. Die Pakete sind durchnummeriert. Am Ende sendet
der Master ein TRANSACTION_FINISHED Paket, dass die Anzahl der
gesendeten PUSH Pakete enthält. Wenn das Transaction
TRANSACTION_FINISHED Paket verloren geht, kommt es zu dem längeren
Timeout vor dem Fehler. Sobald z.B. PUSH_id=1 verloren geht, aber
PUSH_id=2 ankommt, wird auch abgebrochen, da ja auch hier ein
Übertragungsfehler sichtbar ist. Genau diese beiden Fehler habe ich
immer wieder reproduzieren können.

Wenn man die id 65 abfragt, liegen keine Daten vor, sodass keine PUSH
Pakete sondern nur das TRANSACTION_FINISHED Paket (mit Eintrag: 0 PUSH
Pakete übertragen) korrekt empfangen werden muss.

[1] https://github.com/asdil12/fastd-dissector
[2] https://github.com/basros/alfred-dissector

Grüße,
Dominik

Am 22.11.2015 um 19:25 schrieb Peter Muehlenbrock:
> Hallo Dominik
> die Funktionsweise vom Alfred mit Master/Slave/Client habe ich schon
> verstanden.
> Den Mastermode hatte ich nur testweise aktiviert, um zu prüfen  ob die
> Kommunikation wenigstens zwischen 2 Mastern auf FF Routern funktioniert.
> Was sie ganz offensichtlich nicht tut. Dito nicht zwischen Master/Slave.
> 
> Das mit Curl/wget/crawl  ist mir auch bekannt, Genauso mache  ich das
> aktuell so.
> Mir erschien es nur ganz reizvoll, die Monitoringdaten von einem Router
> abzuholen und nicht jeden einzeln zu crawlen. Zumal sie ja jetzt eh
> schon im Netz per Alfred verschickt werden. Und das ja wohl auch der
> Sinn von Alfred ist, das diese Daten bei Bedarf im gesamten Netz
> verfügbar sind.
> 
> 
> Den Tipp mit dem Firewall ist hilfreich. Das könnte der Grund sein und
> das werde ich mal ausprobieren bei Gelegenheit.
> Vielleicht können die Experten die Alfredpakete ja defaultmässig in der
> nächsten Version auch durch den Firewall durchlassen :-). Das hat keinen
> Nachteil, aber den Vorteil dass man bei Bedarf Alfred dann auch auf
> einem FF Router  sinnvoll nutzen kann.
> 
> Peter
> 
> 
> 
> 
> 
> 
> 
> 
> Am 22.11.2015 um 16:54 schrieb Dominik Heidler:
>> Hi,
>>
>> ich nehme mal an, du hast versucht, alfred als master auf dem Freifunk
>> Router laufen zu lassen.
>>
>> Lass Alfred bitte nicht im Master mode laufen, da sonst die Alfred-daten
>> aller router deiner Hood auch über deinen Router laufen.
>>
>> Wenn du alfred nicht als master laufen lässt und "alfred -r 64"
>> eingibst, fragt der alfred dienst auf deinem Router beim alfred-master
>> nach, welche Daten es für id 64 gibt. Der alfred-master schickt die
>> daten an den alfred dienst auf deinem router und der wiederum gibt sie
>> an den alfred-client zurück, der sie dann ausgibt.
>>
>> Wenn der alfred-dienst auf deinem Router im master mode läuft, sendet er
>> alle 10 sekunden ein MASTER_ANOUNCEMENT Paket an alle Router deiner
>> Hood. Die Router entscheiden dann, zu welchem alfred-master die
>> Verbindung am bessten ist und schicken ihre statusdaten dorthin.
>> Unser alfred-master empfängt die MASTER_ANOUNCEMENT Pakete von deinem
>> Router ebenfalls. Jedes mal, wenn ein Router Statusdaten an unseren
>> alfred-master sendet, leitet dieser die Daten an alle ihm bekannten
>> alfred-master weiter. Das selbe macht auch dein Router in die andere
>> Richtung.
>> Wenn du hier auf deinem Router "alfred -r 64" eingibst, wird nur beim
>> lokalen alfred-master angefragt, der diese Anfrage ohne weitere
>> Netzwerkkommunikation beantworten kann, denn jeder alfred-master hollte
>> immer alle Daten des Netzwerks (also in unserem Fall der Hood) haben.
>>
>> Den Request failure bekommst du vmtl wenn der Request zwischen deinem
>> alfred-dienst und dem alfred-master bei der Übertragung verloren geht.
>> Es ist immerhin eine größere Datenmenge, die ohne Fehlerkorrektur per
>> UDP übertragen wird (wenn die Daten verloren gehen, ist es nicht so
>> schlimm für uns - sie werden ja nach 5 Minuten erneut gesendet).
>>
>> Am 22.11.2015 um 07:30 schrieb Peter Muehlenbrock:
>>> zuverlässig die xml Daten des eigenen Knotens an, aber nicht die der
>>> anderen. Dann gibt es auch keinen read request failure.
>>
>> Evtl verhindert die Firewall deines Routers das versenden deiner Master
>> Anouncement Pakete. Die Firewall filtert ja broadcasts um Traffic zu sparen.
>>
>>> Das Versenden der xml Daten an die FF Map monitoring.franken...
>>> funktioniert aber wie erwartet, auch im Mastermode.
>>> Was also ist anders bei dem Alfred Master auf der FFMap Serverseite,
>>> dass es dort hinhaut ?
>>
>> Unser alfred-master läuft nicht auf einem Router sondern auf einem
>> Server, der per VPN direkt im Freifunk Netz hängt, und hat auch eine
>> andere Firewall Konfiguration, sodass die Master Anouncement Pakete
>> (hoffentlich) alle Router erreichen.
>> Wenn ich jetzt "alfred -r 64" auf unserem Server aufrufe, fragt der nur
>> über eine lokale Verbindung (ein UNIX Socket bei dem Übertragungsfehler
>> ausgeschlossen sind) beim alfred-master-dienst an und bekommt die
>> geforderten Daten direkt aus dem cache vom alfred-master.
>>
>>
>> Aber wie gesagt: Wenn du die statusdaten deiner Router holen willst,
>> empfehle ich dir, sie per http mit curl zu holen.
>>
>>
>> Grüße,
>> Dominik
>>
> 
>