nun ist alles richtig konfiguriert, <br><br>alle nodes bis jetzt den roofnode als nachbarn gesehen haben (<a href="http://78.41.112.2">78.41.112.2</a> (via tunnel) bzw. <a href="http://78.41.112.60">78.41.112.60</a> im funknetz)<br>
sollten nun den zusätzlichen nachbar <a href="http://78.41.112.252">78.41.112.252</a> sehen, das ist der devserver<br>und auch der der devserver sieht diese nodes (-; <br><a href="http://devserver.tunnel.wien.funkfeuer.at:8000/nodes">http://devserver.tunnel.wien.funkfeuer.at:8000/nodes</a><br>
<br>lg Markus<br><br><div><span class="gmail_quote">On 5/17/08, <b class="gmail_sendername">Andreas Marksteiner</b> <<a href="mailto:andreas@marksteiner.net">andreas@marksteiner.net</a>> wrote:</span><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
Hallo,<br><br><br> Markus Kittenberger wrote:<br> > leider hat die eneu konfiguration doch mehr probleme gemacht,..<br> > es gab ordentlich packetloss (seltsamerweise nur auf den funkstrecken<br> > und nicht auf den tunnels, ursache noch unklar)<br>
 ><br> > hat leider recht lange gedauert bis ich diese bemerkt hab,..<br> > sorry,..<br><br><br>egal. jedenfalls danke auch von mir.<br><br> finde es gut, wenn wir eine lösung finden, die einen stabilen betrieb<br>
 vom funknetz ermöglicht und nebenbei auch die olsr entwicklung - in<br> gewissem rahmen - ein testfeld hat.<br><br> olsr weiterentwicklung ist sicher wichtig und ohne olsr gäbst das netz<br> auch nicht in der jetzigen form. allerdings darf man das funknetz auch<br>
 nicht als reines testnetz sehen, wir wollen es ja auch verwenden können.<br><br> hab auch letztens 3 devices rebooten müssen, damit ich wieder eine<br> funktionierende durchgehende default route bekommen hab.<br><br> hab da nicht so den einblick bzw. vielleicht ist genau das das problem.<br>
 entweder arbeiten zuviele köche an der<br> new-olsr-versions-go-funkfeuer-netz baustelle, oder es gibt keinen plan<br> wie das ablaufen soll.<br><br> imo wäre es nicht schlecht wenn es einen für alle nachzulesenden plan<br>
 gäbe, wie die vorgehensweise und status für/von deployments neuer olsr<br> versionen im funknetz ist.<br><br> stelle mir vor, wenn wir etwas hätten wie<br> - 2 wochen betrieb in einem testfeld (und wenn sich das virtualisiert<br>
 nicht realisiern läßt, dann halt ein testbed aus beispielsweise 20<br> realen devices) mit routen-feed bzw. gateway zum funknetz, damit es<br> realistischer wird<br> - 2 wochen betrieb auf ausgewählten knoten bzw. von testusern, die sich<br>
 wirklich um ihre knoten kümmern bzw. die stabilität dieser test knoten<br> speziell gemonitored wird<br> - announcement auf mailinglisten mit aufruf zum flächendeckenden upgrade<br> via bereitgestelltem ipkg<br> - je nachdem, wie gut alte und neue olsr versionen verträglich sind eine<br>
 übergangsfrist - danach (beispielsweise 1 Monat) bei usern die nodes<br> online haben, welche nicht upgedatet sind, auf ein captive portal mit<br> hinweis und link zu upgrades.<br><br> die olsr versionen dürften ja untereinander auch nicht immer voll<br>
 kompatibel sein, da wäre es vermutlich nicht schlecht eine "empfohlene"<br> version fürs funknetz auf einer webpage zu announcen. unterschiedliche<br> versionen wurden imo mit unterschiedlichem nachdruck bzw. angestossen<br>
 durch unterschiedliche leute verteilt und es ist nach und nach ein<br> gewisses versions durcheinander im netz entstanden?<br><br> nur so eine anmerkung - sicher nicht allgemein anwendbar und auch<br> verbesserungswürdig.<br>
<br><br> Grüße, Andi.<br><br></blockquote></div><br>