<p>Wie ja eigentlich schon bekannt sein sollte ist filesharing für/bei funkfeuer böse (-;</p><p>wers nbicht glaubt hier der hintergrund:</p><p>filesharing macht viele connections,..</p><p>und die einzelnen funkfeuer-router haben (um NAT machen zu können) conntrack aktiviert,..</p>
<p>und conntrack bedeutet packet inspection, um alle connections auseinenanderzuhalten, <br>und wenn es zuviele conenctions sind werden pakete einfach gedropped,.. </p><p>allerdings wird conntrack für den GESAMTEN traffic gemacht, also nicht nut der ins/aus dem LAN, sondern auch für jeglichen TRANSIT traffic,..</p>
<p>und genaus das macht filesharing xfach-böse, da es durch die vielen connections nicht nur am eigenen router, sondern auch auf allen weiteren routern auf der defaultroute massig ressourcen für conntrack bindet,..</p><p>
lediglich die 5ghz streken welche bis dato alelsamt nicht routen sondern bridgen sind davon unbehelligt,..</p><p>fällt nun eine solche aus, ist s dann leichtmal nicht nur bißchen langsamer sondern fast völlig hinüber,.. </p>
<p>---</p><p>nungut technisch seh ich folgende lösungsmöglichekeiten,..</p><p>A am roofnode p2p blocken (einfacher) oder shapen (komplizierter)</p><p>B conntrack für den TRANSIT-traffic abschalten, weil da brauchts eh keiner, dafür gibts im iptables auch das NOTRACK target<br>
allerdings ist das erste seit "monaten" standardmässig dabei, (als patch gibts das schon bald 10 Jahre)<br></p><p>kamikaze kann es afaik (konfigurieren muss man es aber trotzdem!), aber unsere whiterussian (freifunkfirmware) linksys und buffalos können das noch nciht,..<br>
</p><p>somit müsste sich wer die mühe machen den iptables patch für NOTRACK nach openwrt/whiterussian zu porten,..</p><p>---</p><p>nur eins vorweg,.. ich werd mir die (zwar überschaubare) mühe für B nicht machen (da eh schon ausreichend beschäftigt, und auch kein filesharing user)</p>
<p>allerdings neige ich dazu irgendwann einfach so filesharing komplett zu blocken,..</p><p>weil hier ein beispiel was das blocken von jeweils einer einzigen ip bewirkte (20:44 und 23:34)</p><p>ersteres behob den massiven packetloss aufgrund überlastung des routers am leichtwicht, zweite ip behob dann auch die irre latenzen, als folge von 95% load am router,..</p>
<p><a href="http://193.238.157.78/~markus/connstat/view.php?host=193.238.158.154&nojs=&date=20081225">http://193.238.157.78/~markus/connstat/view.php?host=193.238.158.154&nojs=&date=20081225</a></p><p>(und heute brachte ein ähnliches (aufsummierts) filesharing problem die rosensteingassse zur fall)</p>
<p>lg Markus</p>