[WLANware] Suche nach fastd-Bugreports

Fri Feb 7 17:22:18 CET 2014

Moin,
ich bin gerade einem Bug in fastd auf der Spur, der in sehr seltenen
Fällen dazu führt, dass ein fastd-Client "vergisst", dass er sich wieder
mit seinen Peers verbinden will. Ich bin nicht sicher, ob der Bug in
fastd v11 neu ist, oder auch vorher schon drin war.

Der Bug tritt nur sehr sporadisch auf, und ich habe es bisher nicht
geschafft, ihn absichtlich zu reproduzieren. Wenn jemand Debug-Logs von
einem fastd in diesem Zustand hat (am besten sollten die Logs sowohl den
heilen als auch den kaputten Zustand enthalten, und vielleicht noch die
Ausgabe nach einem SIGUSR1 im kaputten Zustand), wäre es cool, wenn man
mir die zukommen lassen könnte, damit ich das Problem besser analysieren
kann.

Auf OpenWRT kann man in /etc/config/fastd den syslog_level auf 'debug'
setzen, ein Eintrag "option log_size '1024'" unter "config system" in
/etc/config/system und anschließender Reboot sind hilfreich, um den
Ringbuffer von logread auf ein angemessenes Maß zu vergrößern, sodass
man tatsächlich die relevanten Logs findet.

Grüße,
NeoRaider / Matthias
Freifunk Lübeck

On 12/29/2013 03:04 AM, Matthias Schiffer wrote:
> Moin,
> hiermit release ich fastd Version 11 \o/
> 
> Neben einen kleinen, aber feinen Bugfixes gibt es diesmal eine Menge
> Änderungen an der internen Infrastruktur. Dadurch kann fastd jetzt eine
> Menge mehr Verschlüsselungsmethoden unterstützen, wodurch der "Fast and
> Secure Tunnelling Daemon" nun tatsächlich "fast" ist ;)
> 
> Eine Liste von unterstützten Methoden gibt es unter
> https://projects.universe-factory.net/projects/fastd/wiki/Methods . Auf
> dieser Seite habe ich auch ein paar Benchmarks veröffentlicht;
> insbesondere die Kombination salsa2012+gmac möchte ich hervorheben, da
> diese auf einem TL-WR1043ND ganze 14.9 MBit/s schafft (das dreifache vom
> bisher favorisierten xsalsa20-poly1305), und auf einem TL-WDR3600 19.3
> Mbits/sec. Auf modernen CPUs, die Salsa20/12 mit SSE und GHASH mit
> PCLMUL beschleunigen können, schafft fastd jetzt problemlos mehr als 600
> MBit/s.
> 
> Am Handshake hat sich auch eine Menge getan: Das Handshake-Protokoll
> wurde angepasst, damit keine Downgrade-Angriffe mehr möglich sind (ein
> Angreifer konnte damit zwei Peers zu einer Session mit der schwächsten
> gemeinsam unterstützten Verschlüsselungsmethode zwingen) - wobei das
> wohl in den meisten bisherigen Setups nicht relevant ist, da eh fast
> immer nur eine Methode in der Config-Datei erlaubt ist.
> 
> Um die Abwärtskompatiblität zu fastd-Versionen vor v11 gewährleisten,
> wird der alte Handshake per Default weiterhin unterstützt. Dies kann
> durch die neue Config-Option 'secure handshakes yes|no' konfiguriert
> werden - wobei es ausreicht, wenn die Option auf einer Seite von zwei
> Peers auf yes gesetzt ist, um die alten Handshakes zwischen diesen zu
> verhindern. Der Default wird in einer der nächsten fastd-Versionen auf
> yes geändert werden, wobei no auf jeden Fall noch für ein paar Jahre
> unterstützt werden wird. Wo nicht alle Hosts auf fastd v11 aktualisiert
> werden können, aber zumindest eine klare Client-Server-Topologie
> vorliegt, sollten einfach die Server auf v11 aktualisiert und secure
> handshakes auf no gesetzt, und neue Clients mit secure handshakes yes
> konfiguriert werden.
> 
> Außerdem wird mit dem neuen Handshake jetzt das standardisierte
> HKDF-Verfahren statt einem einfachen SHA256-Hash verwendet, um aus den
> Handshake-Daten die symmetrischen Schlüssel abzuleiten (nicht, dass das
> alte Verfahren irgendwie unsicher war, aber der Standard ist einfach
> noch sichererer ;) ).
> 
> Es gibt auch neue Auswahl bei den Implementierungen der
> Crypto-Algorithmen: So kann aes128-ctr jetzt aus OpenSSLs libcrypto
> genommen werden (was durch AES-NI ganz schön schnell ist), und libsodium
> kann NaCl als Drop-in-Replacement ersetzen (vom letzterem ist allerdings
> in der aktuellen Version von libsodium zumindest auf amd64-Systemen
> wegen eines Bugs abzuraten - in der git-Version ist der Bug bereits gefixt.
> 
> Für Salsa20, Salsa20/12 & GHASH gibt es wie oben erwählt jetzt
> optimierte Implementierungen für moderne x86- und amd64-CPUs, die die
> SSE- bzw. PCLMULQDQ-Instruction-Sets verwenden.
> 
> Der Support für die Konfiguration von mehreren Remotes für einen
> einzelnen Peers wurde ausgebaut: Es wird jetzt jede Adresse, auf die ein
> angegebener Hostname auflöst, in Betracht gezogen, und nicht nur die
> erste - insbesondere wird jetzt also bei Hosts mit AAAA- und A-Record
> sowohl IPv6 als auch IPv4 ausprobiert, wenn der Host nicht expliziert
> als IPv6- oder IPv4-only konfiguriert ist.
> 
> Durch die neuen Funktionen ist das fastd-Binary etwas gewachsen; solange
> nur eine Methode einkompiliert wird, bleibt es aber weiterhin unter
> 100KB (OpenWRT, Target ar71xx).
> 
> Von der mit fastd entwickelten libuecc ist gleichzeitig v4 erschienen,
> die jetzt auch dynamisch linkbar ist.
> 
> Die Dokumentation unter
> https://projects.universe-factory.net/projects/fastd/wiki/Documentation
> ist bereits auf den neuen Stand gebracht; Sources findet man unter wie
> immer unter https://projects.universe-factory.net/projects/fastd/files ,
> Pakete für die üblichen Distributionen werde ich den nen nächsten Tagen
> veröffentlichen.
> 
> Grüße,
> NeoRaider / Matthias
> Freifunk Lübeck
> 
> 
> 
> _______________________________________________
> Freifunk.luebeck-devel mailing list
> Freifunk.luebeck-devel at asta.uni-luebeck.de
> https://lists.asta.uni-luebeck.de/mailman/listinfo/freifunk.luebeck-devel
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freifunk.net/pipermail/wlanware-freifunk.net/attachments/20140207/0e376486/attachment.pgp>