<br><br><div class="gmail_quote">2011/9/1 Erich N. Pekarek <span dir="ltr"><<a href="mailto:erich@pekarek.at">erich@pekarek.at</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<u></u>

  
    
    
  
  <div bgcolor="#ffffff" text="#000000">
    Am 2011-09-01 09:36, schrieb Markus Kittenberger:<div class="im"><br>
    <blockquote type="cite">
      <div class="gmail_quote">2011/9/1 Erich N. Pekarek <span dir="ltr"><<a href="mailto:erich@pekarek.at" target="_blank">erich@pekarek.at</a>></span><br>
        <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
          Hallo!<br>
          <div>
            <br>
            <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
              Ethernet port und Treiber Support (->  ad-hoc mode
              waere nett ;-) )<br>
              <br>
              a.<br>
            </blockquote>
          </div>
          Nett ja, aber Ad-hoc-Mode wird möglicherweise überschätzt.</blockquote>
        <div>partly ACK</div>
        <div>wie hast du dir ap/client setup denn genau vorgestellt?</div>
      </div>
    </blockquote>
    <br></div>
    Ein Router im VAP-Mode mit einem Master und mehreren Clients (einer
    pro Partner)</div></blockquote><div>ok passt, so hatte ich es eh vermutet,..  (-;</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#ffffff" text="#000000">
, IP-Setup statisch, </div></blockquote><div>das ist vorerst egel olsr und routing als auch ap/client mode legt keinen wert daruaf was für ips konfiguriert sind,..</div><div>(insofern koennen wir prinzipiell weiter chaotisch ips konfigurierern (-;)</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#ffffff" text="#000000">Bridges.<br></div></blockquote><div>bridge? </div><div>was willst zambridgen?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#ffffff" text="#000000">
    Ein Vorteil wäre, dass die somit quasi-dedizierte Verbindungen
    zustande kommen, was der Stabilität und dem Durchsatz der Links
    sicherlich zu  Gute kommt.</div></blockquote><div>sicher?</div><div>die VAPs laufen auf der gleichen frequenz, und stören sich wohl mindest genausogerne untereinander wie die adhoc links.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#ffffff" text="#000000">
    Das wäre aber noch im Detail zu testen. Bei den großen Nodes ist das
    freilich so keine Lösung, außer man verwendet ESSIDs wieder, sodass
    es zum Gruppieren von Links kommt.<br></div></blockquote><div>das würd ich immer machen, also ein node (mit 4 VAPs) kann maximal 3 clients zu anderen APs haben</div><div>jedoch ein AP (eines grossen nodes) kann prinzipiell beliebig viele clients haben </div>
<div>(während der AP eines kleinen node idr kaum clients hat)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#ffffff" text="#000000"><div class="im">
<blockquote type="cite"><div class="gmail_quote"><div>ich denk auf jedem wifi soviel VAPs wie geht, ist imho
          schlechter als adhoc</div>
        <div>(zumindest bzgl olsr traffic)</div>
      </div>
    </blockquote></div>
    Was erst noch zu zeigen wäre. (Im Falle einer Brigde bspw. wird das
    nicht eintreten).<br></div></blockquote><div>wieso soll eine bridge das verhindern?</div><div><br></div><div>das problem ist das die selbe olsr message in jedem VAP einzeln gesendet werden muss , anstatt eines einzigem broadcasts an alle die es hören können,..</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#ffffff" text="#000000">
    <small><small><small> (wobei es mich brennend interessieren würde,
          ob beispielsweise BATMANd im der Realität wirklich das
          Broadcastproblem gegenüber olsr effektiv senkt.)</small></small></small></div></blockquote><div>inwiefern sollte er das?</div><div><br></div><div>afair sendet er doch ebenso boadcasts für seinen protokolltraffic</div>
<div>(und mit üblichen settings mehr davon als olsrd es tut)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#ffffff" text="#000000"><div class="im">
<br></div><div class="im"><blockquote type="cite"><div class="gmail_quote"><div>aber AP mode und powersave gibts eigenltich nit</div>
      </div>
    </blockquote></div>
    Das nicht, aber der Node muss dann nicht jedes Schrottsignal, das
    bei ihm ankommt verarbeiten</div></blockquote><div>der node verarbeitet eh nur broadcasts,..</div><div>und das wifi muss weiterhin jedes schrottsignal auf seiner frequenz soweit "lesen" um zu wissen das es nicht für es gedacht ist,..</div>
<div>(weiters ists idr stromverbrauchmaessig voellig egal, ob nur rauschen oder "lesbare" signale daherkommen)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#ffffff" text="#000000">, wodurch die Leistung vernachlässigbar
    sinkt. (Was ebenfalls noch zu testen wäre). Es reicht ja schon, wenn
    die Luft ein bisserl sauberer wird ;-)</div></blockquote><div>durch nicht empfangen wird die luft ja nit sauberer,.</div><div><br></div><div>durch das mit den VAPs vervielfachte senden der oslrd pakete, und evt auch mehr beacons für all die Vaps, wirds dann hingegen eher dreckiger,.. </div>
<div><br></div><div>lg MArkus</div></div>