<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body><div><div style="font-family: Calibri,sans-serif; font-size: 11pt;">Hallo zusammen,<br><br>Kann man das nicht auf tcp umstellen? Dann ist zwar das Grundproblem, der Fragmentierung nicht behoben, aber die Übertragung sollte wesentlich besser laufen.<br><br>Grüße Jan</div></div><div dir="ltr"><hr><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Von: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:dominik@heidler.eu">Dominik Heidler</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Gesendet: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">25.11.2015 16:02</span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">An: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:peter.muehlenbrock@nefkom.info">peter.muehlenbrock@nefkom.info</a>; <a href="mailto:franken-dev@freifunk.net">franken-dev@freifunk.net</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Betreff: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">Re: Alfred macke</span><br><br></div>Hi,<br><br>ich habe es jetzt nochmal genau mitgeschnitten:<br>Die gesamten Daten passen in ca 6 PUSH UDP Pakete (+ ein Transmission<br>Complete Paket).<br>Die PUSH Pakete sind größer als die MTU. Deshalb werden sie auf IPv6<br>Level fragmentiert - jedes Fragment hat 1448 Byte.<br>Jedes UDP Paket wird also in ca 45 IP Fragmente aufgeteilt.<br>Insgesamt werden also ca 360 Fragmente in je einem Frame übertragen.<br>Fragmentierungen auf VPN Level und darunter habe ich jetzt nicht betrachtet.<br>Wenn auch nur ein einziges Fragment nicht korrekt übertragen wird, ist<br>die ganze Übertragung fehlgeschlagen.<br><br>Grüße,<br>Dominik<br><br>Am 25.11.2015 um 10:48 schrieb Dominik Heidler:<br>> Ich habe den Server gepingt und konnte bei 60 pings keinen Paket loss feststellen.<br>> <br>> Am 25. November 2015 09:48:32 MEZ, schrieb peter.muehlenbrock@nefkom.info:<br>>><br>>><br>>> Hallo Dominik, <br>>><br>>> nachdem ich die Firewall Rule geändert habe, funktioniert das Announcen<br>>> des Masters jetzt auch auf meinem Router (s.a. auch den Patch, den ich<br>>> verschickt habe) <br>>><br>>> Ich bekomme jetzt manchmal alle Infos der Knoten, meistens aber nur<br>>> eine<br>>> Teilmenge. Letztere sind vermutlich die Router die ich lokal habe, dazu<br>>> kommen aber immer noch ein paar wenige andere. ich vermute es gibt noch<br>>> weitere master im netz, nicht nur der am gateway. <br>>><br>>> Ich denke das Problem liegt daran - wie Du ja auch geschrieben hast-<br>>> dass der Transfer der gesamten Datenmenge in einem Rutsch oft nicht<br>>> klappt und dann die Pakete verworfen werden. <br>>><br>>> Eine Abhilfe wäre vielleicht, ein paar mehr Master zu betreiben, so das<br>>> die Einzeltransfers nicht so lang sind. Aber ein bischen seltsam ist es<br>>> schon, dass anscheinend doch so viele Paketverluste auftreten, dass ein<br>>> Transfer von ein paar hundert KB oft schon nicht klappt. Und das ja<br>>> nicht via Funkstrecken, sondern Gateway--Router mit VPN <br>>><br>>> Peter <br>>><br>>> Am 2015-11-25 09:29, schrieb Dominik Heidler: <br>>><br>>>> Hi,<br>>>><br>>>> ich habe das Problem jetzt mal reproduziert und dabei gleich mal<br>>> einen<br>>>> FASTD Dissector für Wireshark geschrieben [1 [1]] (einen ALFRED<br>>> Dissector<br>>>> gab es zub Glück schon [2 [2]]).<br>>>><br>>>> Wenn man mit Alfred die id 64 abfragt, wird der ALFRED_REQUEST per<br>>> UDP<br>>>> an den Master geschickt, der daraufhin antwortet. Der Master Packt so<br>>>> viele "Facts" (=Die Infos zur ID x über genau einen Router) wie<br>>> möglich<br>>>> in je ein PUSH Paket. Die Pakete sind durchnummeriert. Am Ende sendet<br>>>> der Master ein TRANSACTION_FINISHED Paket, dass die Anzahl der<br>>>> gesendeten PUSH Pakete enthält. Wenn das Transaction<br>>>> TRANSACTION_FINISHED Paket verloren geht, kommt es zu dem längeren<br>>>> Timeout vor dem Fehler. Sobald z.B. PUSH_id=1 verloren geht, aber<br>>>> PUSH_id=2 ankommt, wird auch abgebrochen, da ja auch hier ein<br>>>> Übertragungsfehler sichtbar ist. Genau diese beiden Fehler habe ich<br>>>> immer wieder reproduzieren können.<br>>>><br>>>> Wenn man die id 65 abfragt, liegen keine Daten vor, sodass keine PUSH<br>>>> Pakete sondern nur das TRANSACTION_FINISHED Paket (mit Eintrag: 0<br>>> PUSH<br>>>> Pakete übertragen) korrekt empfangen werden muss.<br>>>><br>>>> [1] https://github.com/asdil12/fastd-dissector [1]<br>>>> [2] https://github.com/basros/alfred-dissector [2]<br>>>><br>>>> Grüße,<br>>>> Dominik<br>>>><br>>>> Am 22.11.2015 um 19:25 schrieb Peter Muehlenbrock:<br>>>> Hallo Dominik die Funktionsweise vom Alfred mit Master/Slave/Client<br>>> habe ich schon verstanden. Den Mastermode hatte ich nur testweise<br>>> aktiviert, um zu prüfen ob die Kommunikation wenigstens zwischen 2<br>>> Mastern auf FF Routern funktioniert. Was sie ganz offensichtlich nicht<br>>> tut. Dito nicht zwischen Master/Slave. Das mit Curl/wget/crawl ist mir<br>>> auch bekannt, Genauso mache ich das aktuell so. Mir erschien es nur<br>>> ganz reizvoll, die Monitoringdaten von einem Router abzuholen und nicht<br>>> jeden einzeln zu crawlen. Zumal sie ja jetzt eh schon im Netz per<br>>> Alfred verschickt werden. Und das ja wohl auch der Sinn von Alfred ist,<br>>> das diese Daten bei Bedarf im gesamten Netz verfügbar sind. Den Tipp<br>>> mit dem Firewall ist hilfreich. Das könnte der Grund sein und das werde<br>>> ich mal ausprobieren bei Gelegenheit. Vielleicht können die Experten<br>>> die Alfredpakete ja defaultmässig in der nächsten Version auch durch<br>>> den Firewall durchlassen :-). Das hat keinen Nachteil, aber den Vorteil<br>>> dass man bei<br>>> Bedarf Alfred dann auch auf einem FF Router sinnvoll nutzen kann. Peter<br>>> Am 22.11.2015 um 16:54 schrieb Dominik Heidler: Hi, ich nehme mal an,<br>>> du hast versucht, alfred als master auf dem Freifunk Router laufen zu<br>>> lassen. Lass Alfred bitte nicht im Master mode laufen, da sonst die<br>>> Alfred-daten aller router deiner Hood auch über deinen Router laufen.<br>>> Wenn du alfred nicht als master laufen lässt und "alfred -r 64"<br>>> eingibst, fragt der alfred dienst auf deinem Router beim alfred-master<br>>> nach, welche Daten es für id 64 gibt. Der alfred-master schickt die<br>>> daten an den alfred dienst auf deinem router und der wiederum gibt sie<br>>> an den alfred-client zurück, der sie dann ausgibt. Wenn der<br>>> alfred-dienst auf deinem Router im master mode läuft, sendet er alle 10<br>>> sekunden ein MASTER_ANOUNCEMENT Paket an alle Router deiner Hood. Die<br>>> Router entscheiden dann, zu welchem alfred-master die Verbindung am<br>>> bessten ist und schicken ihre statusdaten dorthin. Unser alfred-master<br>>> empfängt die<br>>> MASTER_ANOUNCEMENT Pakete von deinem Router ebenfalls. Jedes mal, wenn<br>>> ein Router Statusdaten an unseren alfred-master sendet, leitet dieser<br>>> die Daten an alle ihm bekannten alfred-master weiter. Das selbe macht<br>>> auch dein Router in die andere Richtung. Wenn du hier auf deinem Router<br>>> "alfred -r 64" eingibst, wird nur beim lokalen alfred-master angefragt,<br>>> der diese Anfrage ohne weitere Netzwerkkommunikation beantworten kann,<br>>> denn jeder alfred-master hollte immer alle Daten des Netzwerks (also in<br>>> unserem Fall der Hood) haben. Den Request failure bekommst du vmtl wenn<br>>> der Request zwischen deinem alfred-dienst und dem alfred-master bei der<br>>> Übertragung verloren geht. Es ist immerhin eine größere Datenmenge, die<br>>> ohne Fehlerkorrektur per UDP übertragen wird (wenn die Daten verloren<br>>> gehen, ist es nicht so schlimm für uns - sie werden ja nach 5 Minuten<br>>> erneut gesendet). Am 22.11.2015 um 07:30 schrieb Peter Muehlenbrock:<br>>> zuverlässig die xml Daten des eigenen Knotens an, aber nicht die der<br>>> anderen. Dann gibt es auch keinen read request failure. Evtl verhindert<br>>> die Firewall deines Routers das versenden deiner Master Anouncement<br>>> Pakete. Die Firewall filtert ja broadcasts um Traffic zu sparen. Das<br>>> Versenden der xml Daten an die FF Map monitoring.franken...<br>>> funktioniert aber wie erwartet, auch im Mastermode. Was also ist anders<br>>> bei dem Alfred Master auf der FFMap Serverseite, dass es dort hinhaut ?<br>>> Unser alfred-master läuft nicht auf einem Router sondern auf einem<br>>> Server, der per VPN direkt im Freifunk Netz hängt, und hat auch eine<br>>> andere Firewall Konfiguration, sodass die Master Anouncement Pakete<br>>> (hoffentlich) alle Router erreichen. Wenn ich jetzt "alfred -r 64" auf<br>>> unserem Server aufrufe, fragt der nur über eine lokale Verbindung (ein<br>>> UNIX Socket bei dem Übertragungsfehler ausgeschlossen sind) beim<br>>> alfred-master-dienst an und bekommt die geforderten Daten direkt aus<br>>> dem cache vom alfred-master. Aber wie gesagt: Wenn du die statusdaten<br>>> deiner Router holen willst,<br>>> empfehle ich dir, sie per http mit curl zu holen. Grüße, Dominik<br>>><br>>><br>>><br>>> Links:<br>>> ------<br>>> [1] https://github.com/asdil12/fastd-dissector<br>>> [2] https://github.com/basros/alfred-dissector<br>> <br><br>-- <br>franken-dev mailing list<br>franken-dev@freifunk.net<br>http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net<br></body></html>