[Wien] [Core] viviroof & devserver

[Markus Kittenberger]

nun ist alles richtig konfiguriert,

alle nodes bis jetzt den roofnode als nachbarn gesehen haben
(78.41.112.2(via tunnel) bzw.
78.41.112.60 im funknetz)
sollten nun den zusätzlichen nachbar 78.41.112.252 sehen, das ist der
devserver
und auch der der devserver sieht diese nodes (-;
http://devserver.tunnel.wien.funkfeuer.at:8000/nodes

lg Markus

On 5/17/08, Andreas Marksteiner <(spam-protected)> wrote:
>
> Hallo,
>
>
> Markus Kittenberger wrote:
> > leider hat die eneu konfiguration doch mehr probleme gemacht,..
> > es gab ordentlich packetloss (seltsamerweise nur auf den funkstrecken
> > und nicht auf den tunnels, ursache noch unklar)
> >
> > hat leider recht lange gedauert bis ich diese bemerkt hab,..
> > sorry,..
>
>
> egal. jedenfalls danke auch von mir.
>
> finde es gut, wenn wir eine lösung finden, die einen stabilen betrieb
> vom funknetz ermöglicht und nebenbei auch die olsr entwicklung - in
> gewissem rahmen - ein testfeld hat.
>
> olsr weiterentwicklung ist sicher wichtig und ohne olsr gäbst das netz
> auch nicht in der jetzigen form. allerdings darf man das funknetz auch
> nicht als reines testnetz sehen, wir wollen es ja auch verwenden können.
>
> hab auch letztens 3 devices rebooten müssen, damit ich wieder eine
> funktionierende durchgehende default route bekommen hab.
>
> hab da nicht so den einblick bzw. vielleicht ist genau das das problem.
> entweder arbeiten zuviele köche an der
> new-olsr-versions-go-funkfeuer-netz baustelle, oder es gibt keinen plan
> wie das ablaufen soll.
>
> imo wäre es nicht schlecht wenn es einen für alle nachzulesenden plan
> gäbe, wie die vorgehensweise und status für/von deployments neuer olsr
> versionen im funknetz ist.
>
> stelle mir vor, wenn wir etwas hätten wie
> - 2 wochen betrieb in einem testfeld (und wenn sich das virtualisiert
> nicht realisiern läßt, dann halt ein testbed aus beispielsweise 20
> realen devices) mit routen-feed bzw. gateway zum funknetz, damit es
> realistischer wird
> - 2 wochen betrieb auf ausgewählten knoten bzw. von testusern, die sich
> wirklich um ihre knoten kümmern bzw. die stabilität dieser test knoten
> speziell gemonitored wird
> - announcement auf mailinglisten mit aufruf zum flächendeckenden upgrade
> via bereitgestelltem ipkg
> - je nachdem, wie gut alte und neue olsr versionen verträglich sind eine
> übergangsfrist - danach (beispielsweise 1 Monat) bei usern die nodes
> online haben, welche nicht upgedatet sind, auf ein captive portal mit
> hinweis und link zu upgrades.
>
> die olsr versionen dürften ja untereinander auch nicht immer voll
> kompatibel sein, da wäre es vermutlich nicht schlecht eine "empfohlene"
> version fürs funknetz auf einer webpage zu announcen. unterschiedliche
> versionen wurden imo mit unterschiedlichem nachdruck bzw. angestossen
> durch unterschiedliche leute verteilt und es ist nach und nach ein
> gewisses versions durcheinander im netz entstanden?
>
> nur so eine anmerkung - sicher nicht allgemein anwendbar und auch
> verbesserungswürdig.
>
>
> Grüße, Andi.
>
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20080518/3a933f3b/attachment.htm>