|
|
| Line 1: |
Line 1: |
| − | {{TOCright}}
| + | This page has been moved to my BLOG at http://blog.kr8.de |
| − | | |
| − | == Stichwörter ==
| |
| − | * [[LAN]]
| |
| − | * Wireless LAN
| |
| − | * [[Wireless Access Point]] - '''Hotspot'''
| |
| − | * WiFi (Wireless Fidelity)
| |
| − | * IEEE 802.11b (11 Mbit/s)
| |
| − | * IEEE 802.11g (54 Mbit/s)
| |
| − | * IEEE 802.11n (150 Mbit/s pro Datenstrom - z.B. 300 Mbit/s mit zwei Strömen in MMO-Technik)
| |
| − | * 2,4 Gigahertz-Band (wie [[Bluetooth]]) (Wellenlänge = 12 cm)
| |
| − | * WDS (Wireless Distribution System, Teil von IEEE 892.11 für WLAN-Repeater)
| |
| − | | |
| − | == Software==
| |
| − | * '''Easy WiFi Radar'''
| |
| − | * WIFI Studio
| |
| − | * inSSIDer
| |
| − | * Vistumbler
| |
| − | | |
| − | == Accesspoints, Antennen und Repeater ==
| |
| − | Im Zuge meines Einstiegs in die ADSL ([[InternetZugang]] über Broadband / Cable) mit dem [[DrayTek]] Vigor2500We wollte das Ganze gleich damit verbinden, in die WLAN-Technik einzusteigen, da ich bereits zwei Notebooks habe, die eine eingebaute WLAN-Karte haben und weil wir diesen Sommer so schönes Terrassenwetter haben/hatten.
| |
| − | | |
| − | Der [[DrayTek]] als [[WLAN Access Point]] funktioniert gut. Nur das mit der <b>Reichweite ist ein Riesenproblem:</b> Als ADSL-Modem muss das Ding in der Nähe des ISDN-NTBAs stehen. Der NTBA ist im Arbeitszimmer auf der Fensterwand (Strassenseite). Die Terrasse befindet sich auf der anderen Seite zum Innenhof hin ca 20 Meter Luftlinie. Das schafft der DrayTek Vigor2500We teilweise garnicht mehr. Da sind dann einige Mauern eines Altbaus von 1925 zuviel im Wege....
| |
| − | | |
| − | Grundsätzlich also die Erkenntniss: So ein integriertes Gerät ist prinzipiell ungeeignet, da es einerseits als ADSL-Modem in der Näche des ISDN-NTBAs stehen muss, andererseits als [[WLAN Access Point]] zentral in der Mitte des Nutzungsbereichs (Wohnung/Terrasse) stehen muss. Das ist häufig ein Gegensatz. Wenn man noch nicht alle Computer auf wireless umstellen will, benötigt man den DrayTek Vigor2500We auch noch als Ethernet-Switch in der Nähe seiner Alt-Computer; z.B. im Arbeitszimmer. Das ergibt zusätzliche Restriktionen für den Standort des Geräts.
| |
| − | | |
| − | [http://www.draytek.info/Produkte/Vigor2500We/Daten-Vigor2500We.html|DrayTek 2500We] für 29,90 statt für 250,00 Euro. Router mit integriertem ADSL-Modem (U-R2), 4-Port-Switch mit Auto-Uplink-Funktion und WLAN nach IEEE 802.11b.
| |
| − | | |
| − | Da die Antennen bei mir zuhause nicht den gewünschten Erfolg bringen, habe ich mich jetzt entschieden einen '''Repeater''' einzusetzen. Da die Repeater-Technologie nicht standardisiert ist, geht man auf Nummer sicher, wenn man Accesspoint und Repeater baugleich wählt. Ich habe mir deshalb '''zwei''' [[D-Link DWL 2100AP]] angeschaft. Einer ist als [[Access Point]] konfiguriert, der andere als Repeater. Nachdem ich die Firmware von v1.01eu auf v2.10eu upgeradet hatte, hat das ganze dann auch gut funktioniert. Der Accesspoint steht im Arbeitszimmer (Strassenseite), der Repeater im Badezimmer (Mitte/zum Innenhof) und der Notebook mit WLAN-Karte auf der Terrasse (Innenhof). Die Funktion [[WLAN Access Point]] im DrayTek ist nun abgeschaltet.
| |
| − | | |
| − | == WLAN im Notebook ==
| |
| − | Damit eine Notebook (ComputerLonzo) PCMCIA-WLAN-Karte optimal zum Access Point passt, sollte der verwendete Chipsatz identisch sein.
| |
| − | * D-Link DWL G650M Atheros Chipsatz mit Super-G, MIMO und Turbo-Funktion
| |
| − | * Netgear WG511T & Netgear WAG511
| |
| − | | |
| − | == Meine WLAN-Konfiguration ==
| |
| − | Ich verwende zwei [[D-Link DWL 2100AP]]. Einer fungiert als '''Access Point''', der andere als '''Repeater'''.
| |
| − | | |
| − | == WLAN Checker ==
| |
| − | | |
| − | Zur Anzeige der drahtlosen Netzwerke in der nähren Umgebung (Signalstärke, Channels etc.) benutze ich: [[Inssider]] http://www.metageek.net/products/inssider
| |
| − | | |
| − | == WLAN Kloning ==
| |
| − | Im c't magazin 6/2009 vom 2.3.2009 gab es ein kleines Programm "c't WLAN Kloner". Das kann aus einer vorhandenen aktiven WLAN-Verbindung die
| |
| − | Verbindungsdaten auslesen und in eine [[XML]]-Datei schreiben. So exporttierte Daten können auf einem anderen Rechner wieder "importiert" werden.
| |
| − | | |
| − | Damit das läuft, sind unter [[WindowsXP]] oder [[Windows Vista]] folgende Voraussetzungen erforderlich:
| |
| − | * Installation des Microsoft Wireless LAN-API (KB918997)
| |
| − | * Starten des Service "Wireless Zero Configuration" (deutsch: "Automatische WLAN Konfiguration")
| |
| − | | |
| − | == Aus der Wikipedia ==
| |
| − | The 802.11b amendment to the original standard was ratified in 1999. 802.11b has a maximum raw data rate of 11 Mbit/s and uses the same CSMA/CA media access method defined in the original standard. Due to the CSMA/CA protocol overhead, in practice the maximum 802.11b throughput that an application can achieve is about 5.9 Mbit/s over TCP and 7.1 Mbit/s over UDP.
| |
| − | | |
| − | In June 2003, a third modulation standard was ratified: 802.11g. This flavour works in the 2.4 GHz band (like 802.11b) but operates at a maximum raw data rate of 54 Mbit/s, or about 24.7 Mbit/s net throughput like 802.11a. It is fully backwards compatible with b and uses the same frequencies. Details of making b and g work well together occupied much of the lingering technical process. In older networks, however, the presence of an 802.11b participant significantly reduces the speed of an 802.11g network.
| |
| − | | |
| − | == DHCP Client Recovery From Failure to Obtain an IP Address ==
| |
| − | The dependency of DHCP clients on servers is not a problem as long as DHCP is functioning normally and a host can get a lease, and in fact has many benefits that we have explored. Unfortunately, a number of circumstances can arise that result in one of the DHCP processes not resulting in a lease for the client. The client may not be able to obtain a lease, re-acquire one after reboot, or renew an existing lease. There are many possible reasons why this might happen:
| |
| − | * The DHCP server may have experienced a failure, or may be taken down for maintenance;
| |
| − | * The relay agent on the client's local network may have failed;
| |
| − | * Another hardware malfunction or power failure may make communication impossible;
| |
| − | * The network may have run out of allocatable addresses.
| |
| − | Without a lease, the host has no IP address, and without an address, the host is effectively dead in the water. The base DHCP specification doesn't really specify any recourse for the host '''in the event that it cannot successfully obtain a lease'''. It is essentially left up to the implementor to decide what to do, and when DHCP was first created, many host implementations would simply display an error message and leave the host unusable until an administrator or user took action.
| |
| − | | |
| − | Clearly this is far from an ideal situation. It would be better if we could just have a DHCP client that is unable to reach a server '''automatically configure itself'''. In fact, the IETF reserved a special IP address block for this purpose. This block, 169.254.0.1 through 169.254.255.254 (or 169.254.0.0/16 in classless notation) is reserved for autoconfiguration, as mentioned in RFC 3330:
| |
| − | | |
| − | “Hosts obtain these addresses by auto-configuration, such as when a DHCP server may not be found.”
| |
| − | | |
| − | Strangely, however, no TCP/IP standard has yet been defined to specify how such autoconfiguration works. To fill the void, Microsoft created an implementation that it calls '''Automatic Private IP Addressing (APIPA)'''. Due to Microsoft's market power, APIPA has been deployed on millions of machines, and has thus become a de facto standard in the industry.
| |
| − | | |
| − | <br />Quelle: http://www.tcpipguide.com/free/t_DHCPAutoconfigurationAutomaticPrivateIPAddressingA.htm
| |
| − | | |
| − | -- Main.DietrichKracht - 29 May 2005
| |
