[Berlin-wireless] Tempo Tempo

Marco Tidow martidow
Di Jun 26 15:53:43 CEST 2007


On Tue, Jun.26. 10:43 +0200, Rolf Pfeiffer wrote:
> Am Dienstag, 26. Juni 2007 01:56 schrieb Marco Tidow:
> > wie erwähnt, RTS/CTS arbeitet nur "cell-local".  weitere wifi-nets kommen
> > in theoretischen arbeiten irgendwie nie vor...
> >
> Genau diese Pille mag ich ohne Überprüfung nicht schlucken. Mag sein, das sich 
> einige Implementationen nicht daran halten - aber standardkonform heisst: 
> Klappe halten bei JEDEM empfangenen RTS oder CTS.

stimmt, so *lese* ich 802.11-1999.pdf - section 7.2.1.1 auch.
  (http://standards.ieee.org/getieee802/download/802.11-1999.pdf)

sehe ich mir aber die "Einschachtelung" des MAC-frames (in dem Control-frames,
also u.a. RTS,CTS,*ACKs, enthalten sind)  in den PLCP-frame an, findet sich
noch der PHY-header mit info über burst-betrieb etc. den jedes devices auch
erstmal richtig dekodieren muß, um den MAC-frame richtig zu verarbeiten,
lies:
  RTS/CTS *auch anderer netze* mit anderen wifi-parametern und -fähigkeiten
  mitzukriegen, das enthaltene "duration field" zur ermittlung der
  angekündigten contention-period auf dem channel richtig auszuwerten.

sieht für mich nach einer menge platz für bugs + inkompatibilitäten grade für
"alte" wifi-devices aus, bzw. nach raum für interpretation seitens der
einzelnen hersteller, grade wenn burst-modi, short-preamble etc. ins spiel
kommen.
(ECMA-368.pdf - Abschnitt 10 PLCP sublayer ff.
  http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-368.pdf)



> Die Frage heißt also nicht RTS/CTS ja oder nein, sondern: unter welchen 
> Rahmenbedingungen? Wie realistisch sind die?

No.
bin an dieser stelle zuerst pragmatiker, ich schau mir an ob ein setup tut,
mit aktiviertem RTS jedenfalls oft garnicht, damit war´s das für mich, gibt
für mich erstmal wichtigere aspekte auf MAC-level (bit-raten automatik).

kriege so vielleicht nicht zuerst das "ideale" funknetz, aber dafür eins,
das funk-tioniert, an dessen relevanteren schrauben ich zunächst weiter-
hantieren kann ;-)



> Die Moral von der Geschicht:
> Wichtiger als RTS/CTS ist eine SAUBERE Trennung von Nah- und Fernlinks. Bei 
> Ersteren durch strikte Begrenzung der Reichweite (Sendeleistung, geneigte 
> Antennen), bei Letzteren durch möglichst schmalen Abstrahl-Winkel (=hoher 
> Gewinn) UND kleine Nebenkeulen. Dann gibts auch keine 60 Netze.

Nack.
die 60 Netze hast Du am Boxi, wenn ich kismet in der mitte des platzes auf
einer prism2-pcmcia starte.  nix externe antenne, onboard-print only.

  *das* ist die art realität, von der ich ausgehe,
wo´s *ohne* antennen-gimmicks "out-of-the-box" laufen *muß*
 - dann läuft´s überall sonst auch;

selbst mit besseren antennen ;-)
aber man merkt dann wenigstens, was sie wirklich bringen.


beispiel:

hab´ gestern über 8 hops quer durch f´hain was in treptow fixen *müssen*,
damit die "unkul"-en  dort heute im büro wieder netz haben.

hat   *pro cmd-line*    ´ne halbe stunde gebraucht, kein witz!


und auf dem weg ist jede menge "tolles equipment" verbaut...



bloß:

ein

  ping -s 1500  104.130.2.245

liefert grade eben

    --- 104.130.2.245 ping statistics ---
    26 packets transmitted, 1 packets received, 96% packet loss
    round-trip min/avg/max = 142.2/142.2/142.2 ms


"96% packet loss"


tja,
                  *das* kann es einfach nicht sein!!!



mache ich dasselbe auf "meinen" routern am boxi mit stummeln und bi-quads,
wieder über 7-hops, merk´ ich kaum, das die shell auf nummer 7
nicht auf meinem laptop direkt läuft.
(tatsächlich *gehören* die kisten mir bis auf zwei natürlich *nicht*)


habe das thema seit monaten hier immer mal wieder angeschnitten, und
wir können noch lange diskutieren, bin ja auch nicht abgeneigt bei sowas;

aber bis der stein des weisen gefunden ist, muß das netz trotzdem, erstmal,
wenigstens sub-optimal *laufen* !

marco





Mehr Informationen über die Mailingliste Berlin