Re: Erfahrungsbericht: Devolo/MicroLink dLAN-Adpater (HomePlug)

On Thu, Oct 27, 2005 at 03:59:16PM +0200, Oliver Fromme wrote:
> Bernd Walter <ticso(at)cicely12.cicely.de> wrote:
> > On Thu, Oct 27, 2005 at 12:02:38PM +0200, Oliver Fromme wrote:
> > > Die Kaufentscheidung hatte für mich diverse Gründe:
> > > 1. Fliegende Verkabelung wollte ich (und meine Freundin)
> > > nicht haben, weil's einfach sch*** aussieht, als Stol-
> > > perfalle und Staubfänger fungiert, beim Absaugen nervt
> > > usw. Auch Kabelkanäle o.ä. an die Wände zu tackern ist
> > > doof und stört optisch in einer frisch renovierten
> > > Wohnung.
> >
> > Ich höhre das Argument in letzter Zeit sehr oft.
> > Mir ist unverständlich, wie Leute aus unserer Branche vergessen
> > können bei einer Renovierung gleich das Cat-5 in die Wand zu legen.
>
> Wohnst Du zur Miete? Hat sich Dein Vermieter einverstanden

Nein, wusste nicht, dass ein kleiner Schlitz in der Wand bereits
ein Problem darstellt.

> > > 2. Löcher durch 30 cm Stahlbeton bohren ist nicht spaßig.
> >
> > Äh - doch, seit ordendliche Bohrhammer bezahlbar geworden sind ist
> > das sehr wohl spaßig.
>
> Ich habe mir einen von einem Bekannten geliehen, um zwi-
> schen Serverraum (Abstellkammer) und meinem Arbeitszimmer
> ein Loch zu bohren. Ich kenne Deinen Stahlbeton nicht,
> aber meiner hat mich dazu veranlaßt, von weiteren solchen
> Aktionen Abstand zu nehmen.

Ich habe während der Lehre reichlich Löcher gebohrt.
So problematisch empfinde ich das nicht.

> Im eigenen Haus kann man natürlich tun und lassen, was man
> will (naja, fast), sofern man bereit ist, die Kosten dafür
> zu tragen, aber wenn man zur Miete wohnt, gibt es schon
> gewisse Einschränkungen.

Die kosten für ein paar Meter Kabel sind nicht sonderlich hoch.
Ich habe aber auch der Vorteil, dass der Keller direkt darunter
ist und ich meist nur einmal nach unter bohren muss, im Keller kann
ich dann schnell durch die Lehrrohre an der Decke überall hin
verteilen.

> > > Also habe ich diese »dLAN«-Teile gekauft, die Netzwerkdaten
> > > über die vorhandenen Stromleitungen übertragen. Es sind
> > > kleine Kästchen (etwa so groß wie Steckernetzteile), die
> > > man direkt in eine Steckdose steckt, und auf der anderen
> > > Seite ist eine Ethernet-Buchse. Über sechs LEDs wird der
> > > Verbindungsstatus auf dLAN- und Ethernet-Seite angezeigt.
> > > Netzwerktechnisch verhalten sie sich wie eine Ethernet-
> > > Bridge, d.h. jeder Adapter hat eine Mac-Adresse (aber keine
> > > IP-Adresse). dLAN-seitig wird DESpro als Verschlüsselung
> > > eingesetzt (transparent).
> >
> > Aha - eine eigene Mac, d.h. die machen auch eine Loop-detection?
> > Ansonsten dürften die ja ohne auskommen.
>
> Haben Ethernet-Bridges nicht grundsätzlich eine MAC? Ich
> habe jedenfalls noch kein solche ohne MAC gesehen. Sonst
> wär's ja nur eine Art Hub.

Sollten sie haben, weil die Spanning-Tree machen sollten, aber
die Realität sieht anders aus.
Fertige Switch ICs kommen ohne MAC, genauso wie NIC.
Jetzt kann der Hersteller allerdings darauf verzichten ein externes
EEPROM mit MACs anzuklemmen.
Idalerweise sollte jeder Port eine eigene MAC haben.
Der Switch sollte in Regelmässigen Abständen Testpackete verschicken,
die er mit seiner MAC als Absender versieht.
Die Testpackete werde durch flooding verteilt.
Wenn der Switch nun sein eigenes Packet an einem anderen Port
reinkommen sieht hat er eine Schleife entdeckt und weiß auch
gleich welche Ports verbunden sind.
Aufwendiger ist es mit Spanning-Tree, da kann dann eine Schleife
gezielt behandelt werden, aber das brauche ich dir wohl nicht zu
erklären.
Spanning-Tree ist in billigen Switchen unüblich, viele haben
halt nicht mal MACs und können deshalb nicht mal die vereinfachte
Schleifenerkennung.

> Wie dem auch sei, die MAC wird auch vom Konfigurations-Tool
> verwendet, um die Adapter auseinanderzuhalten (in Verbin-
> dung mit einem Identifier, der jeweils auf der Unterseite
> aufgedruckt ist) und ihnen Keys für die Verschlüsselung zu-
> zuweisen. Desweiteren gibt es ein Info-Tool, das alle im
> Netz gefundenen Adapter mit den aktuellen (Brutto-)Daten-
> raten anzeigt, auch hierbei werden die MAC-Adressen zur
> Identifizierung verwendet.

Ah - klar, das geht nicht ohne.

> > > Erste positive Punkte, die mir auffielen: Die RJ45-Buchse
> > > hat Auto-MDI/X, d.h. man braucht keine Cross-over-Kabel und
> > > kann beliebig Endgeräte, Switches usw. anschließen. Zwei-
> > > tens verbrauchen die Adapter im Betrieb (unter Last) nur
> > > 4 Watt. Schaltet man den Rechner aus, gehen sie nach 5 Mi-
> > > nuten automatisch in Stand-by und verbrauchen dann nur noch
> > > die Hälfte.
> >
> > Das erscheint mir auch wenig, im Vergleich zu einem Kabel ist
> > das aber denoch reichlich.
>
> Im Vergleich zu den Materialkosten sind die Stromkosten
> aber vernachlässigbar gering. Cat5-Kabel, Kabelkanäle,
> Arbeitsaufwand für's Verlegen usw. dürfte erheblich mehr
> sein.

Kommt sicherlich auf die jeweilige Situtation an.
Aber schon mal gut zu wissen, dass das generel funktioniert.

> > Bei älteren Anlagen sind bisweilen auch die Schraubklemmen nicht
> > mehr fest - macht Sinn die anzuziehen, wenn man eh gerade mal
> > dran kommt.
>
> Und wenn man gerade einen Elektriker zur Hand hat, denn
> wenn man selbst an der Elektroinstallation herumbastelt,
> erlischt der Versicherungsschutz im Falle eines Unfalls,
> Brandes o.ä. (Ist natürlich auch eine Frage der Nachweis-
> barkeit, aber Versicherungen kommen da auf die interessan-
> testen Ideen, besonders wenn es um hohe Schadenssummen
> geht.)

Mir ist es persönlich lieber, dass es den Brandfall, den die
Versicherung ansonsten bezahlen würde gar nicht erst gibt.
Abgesehen davon wird dir auch keiner ernsthaft vorwerfen können
Klemmschrauben angezogen zu haben.

> > Bei 3ms sollte das nicht so viel ausmachen, die Werte sind ja
> > schließlich für Internetverbindungen vorkonfiguriert.
>
> Die Default-Werte sind für kleinere "Bandbreite * RTT"-
> Produkte vorkonfiguriert -- das trifft in der Tat auf typi-
> sche Heim-Internetverbindungen zu (geringe Bandbreite),
> aber auch auf normale LAN-Verbindungen (geringe RTT).
> Im Fall von dLAN ist aber sowohl die RTT (deutlich) größer
> als bei LAN-Verbindungen, als auch die Bandbreite größer
> als bei Internet-Verbindungen -- d.h. das Produkt ist
> größer.

Ja, aber 3ms ist bei der Bandbreite nicht groß.

> Wieviel es tatsächlich ausmacht, weiß ich nicht. Viel-
> leicht hast Du recht und es macht nicht so viel aus, aber
> ich werde es auf jeden Fall ausprobieren.
>
> > Bei 20ms brauchst du bei der Bandbreite aber in der Tat mehr
> > recvspace - so an die 120k.
>
> Ja, wobei erschwerend hinzukommt, daß mein Server nur ein
> 1 GHz Nehemiah ist (aus Stromspargründen).

Ich erkenne jetzt bei den Werten nicht den Zusammenhang.

> > Das Problem war aber, dass es bei einigen Systemen Probleme mit
> > Werte über 32k gibt - müsste man entsprechend in den Anwendungen
> > anpassen.
>
> Hmm, der Default von recvspace ist doch bereits 64k. Ver-
> wechselst Du da vielleicht was? Normalerweise sollte die
> Anwendung davon auch nichts merken.

Kann sein, dass ich das mit send verwechsel, dann liegt das Problem
eben bei 64k.
Ursprünglich war nur 64k vorgesehen, durch Bugs in TCP-Implementationen
geht es auf einer Seite nicht mit 64k.
Es gibt für mehr als 64k Erweiterungen, aber auch die sind nicht
Problemfrei im Fallback.
Ja, die Anwendung sollte davon nicht viel sehen, aber defaultwerte
müssen mit dem ganzen Internet zurecht kommen, da gibt es immer
Fehlerhafte Implementationen.
Es bleibt also nur, dass die jeweilige Anwendung gezielt die Buffer
bei den bedürftigen Verbindungen erhöht.
Bei einer Maschine, die nur Interne Verbindungen hat, ist das natürlich
was anderes.
Aber man sollte auch nicht vergessen, dass der Buffer pro TCP-Socket
gebraucht wird und sich somit auch am kmem bedient.

> Wie auch immer -- wenn's ein Problem gibt, werde ich es
> merken. :-)

Klar, aber meist wird man bei einem Problem mit einem externen Server
nicht an die TCP-Einstellungen denken.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message