TS: Tethering über WLAN-Client ins LAN

Hello,

ich habe versucht, meinen Tethering-Hotspot vom Samsung Tab4 (Android 4.x) mittels WLAN-Client für das LAN nutzbar zu machen. Laut diverser Beschreibungungen ist das auch mit dem Router WR1043N-V3 (V5 hat keine WDS-Funktion mehr) mittels der WDS-Funktion möglich.

Leider meldet sich der Router nicht beim Tablet an.

Mein alter Linux-Lappi kann hingegen ungehindert zugreifen über seinen WLAN-Client.

Woran könnte es liegen?

Geht das nicht (mehr) mit allen Android-Geräten?

Glück Auf
Tom vom Berg

-- Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.

Akzeptierte Antworten zum Thema:

  1. In der Regel funktioniert die Verschlüsselung bei WDS herstellerübergreifend nur mit WEP.

    Quelle: elektronik-kompendium.de

    Folgendes sollte bei Dir Alarm auslösen:

    Hinweis: WEP gilt als veraltet und sollte nicht mehr verwendet werden. Ein WLAN sollte immer mit WPA2 (IEEE 802.11i) abgesichert werden. WLAN-Geräte, die WPA2 nicht unterstützen, sollten dringend ausgetauscht und nicht mehr eingesetzt werden. Ab 2013 dürfen neue Access Points kein WEP mehr anbieten. Ab 2014 dürfen WLAN-Geräte, wie zum Beispiel Notebooks und WLAN-Sticks kein WEP mehr unterstützen.

    Quelle: elektronik-kompendium.de

    • Entweder das "Linux-Lappi" kann das alte, unsichere und verworfene Zeug noch, was daran liegen kann, dass es das im Verkaufszustand nicht konnte, erst nach der Installation von Linux…

    • Oder aber das Linux-Lappi versteht zufällig "die nicht hersteller-übergreifende" Implementierung von WPA2 auf diesem Access Point, das Tablet indes nicht.

    • Oder Du hast auf dem Tablet das WLAN - hier die Verschlüsselung - schlicht falsch konfiguriert.

    1. Hello,

      neee, falsch vertanden...

      Tablet stellt Access-Point per Tethering zur Verfügung und verwendt selbstverständlich WPA2. WPA3 kann es noch nicht.

      Der Lappi, noch mit Debian 7 bestückt, kann mit seinem WLAN-Client auf den Access-Point des Tablets zugreifen.

      Die Router und übrigen Access-Points kommen aber nicht drauf auf den Hotspot des Tablets, obwohl sie seine Metadaten richtig lesen können.

      [Ergänzung]:
      Ich kann den Laptop auch mittels USB-Tethering mit dem Tablet verbinden.
      Habe ich da jetzt eine Chance, die freie LAN-Schnittstelle (eth0) als WAN-Zugang bereitzustellen?

      Reicht es dafür, das Routing einzuschalten? Welche Routen müsste ich wo eintragen? Wie sieht es dann aus mit DHCP(-Weiterleitung) usw.?

      Glück Auf
      Tom vom Berg

      -- Es gibt nichts Gutes, außer man tut es!
      Das Leben selbst ist der Sinn.
      1. [Ergänzung]: Ich kann den Laptop auch mittels USB-Tethering mit dem Tablet verbinden. Habe ich da jetzt eine Chance, die freie LAN-Schnittstelle (eth0) als WAN-Zugang bereitzustellen?

        Ja. Man kann mit einem Laptop ein eigenes Netzwerk mit Internetzugang aufziehen. Man könnte fast meinen, ich hätte die Frage selbst gestellt um ein wenig spammen zu können...

        Ich habe dazu noch einen "TP-Link TL-WA855RE WLAN Repeater" (€ 23.00) geordert, weil nicht jeder WLAN-Chip als Access-Point arbeiten kann (Das Ding tut das...) und stelle mit ein paar Skripten ein eigenes WLAN zur Verfügung. Oder ich nehme einen Switch und Kabel mit, dann gibt es LAN. Allerdings nur wenn das Seminarthema "fette" Netzwerkleistung erfordert. VM-Ware wäre ein Kandidat.

        Gemacht habe ich das, weil in den Gästenetzen von Hotels (und sogar Schulungsräumen in Firmen!) ein gegenseitiger Zugriff der Rechner aufeinander nicht möglich ist.

        1. Hello J.,

          vielen Dank für die Anleitung. Scheint genau das zu sein, was ich benötige.

          Muss ich mir aber genauer ansehen, was da genau passiert, damit ich es dann in Zukunft auch alleine hochziehen kann.

          Ich benötige diese Möglichkeiten für den Test von Balancern/Concentratern. Dafür benötige ich mehrere verschieden starke Internetzugänge (min. 4) als WANs auf Kabel.

          Glück Auf
          Tom vom Berg

          -- Es gibt nichts Gutes, außer man tut es!
          Das Leben selbst ist der Sinn.
          1. Ich benötige diese Möglichkeiten für den Test von Balancern/Concentratern. Dafür benötige ich mehrere verschieden starke Internetzugänge (min. 4) als WANs auf Kabel.

            Klingt a) spannend und b) nach meinen Lieblingssportarten. Das ich mich als Freiberufler prostituiere ist wahrscheinlich bekannt.

            Hauptsache, ich muss nichts mit Windows machen...

        2. Nachtrag:

          Die Konfiguration geht via Textdatei /root/bin/seminarnet.settings.

          Dort einfach die richtigen Geräte eintragen. Lass aber die Finger von den Netzwerkadressen, das zieht Mehraufwand nach sich - den ich in den Skipten wegen des Mangels an Nutzen nicht berücksichtigt habe.

          Immerhin stammt das Zeug aus dem grandiosen und erinnerungswürdigen "Jeden-Tag-Badewetter-" Sommer anno 2018...

        3. Hello,

          in welcher Reihenfolge müssen denn welche Aktionen stattfinden?

          1. Einrichtung von Komponemten
          2. Aufruf von Skripten
          3. ...

          Glück Auf
          Tom vom Berg

          -- Es gibt nichts Gutes, außer man tut es!
          Das Leben selbst ist der Sinn.
          1. Ich habe die Dateien jetzt nochmal als Tar-Files abgelegt. Wegen des "Hardcore-Cachings" wirst Du [F5] drücken müssen.

            Bevor wir anfangen: Mit Debian 6 wird das womöglich out of the box nichts. Kann sein, dass ich irgendwo modernere Befehle verwende, mit dem alten, anno 2016 "abgelaufenen" Zeug wie Squeeze hab ich das nicht getestet. Gibt es dafür noch Repos?

            Erster Schritt: Installation der nötigen Pakete.

            Zweiter Schritt (Router/Server): Du brauchts die Router-Server.tar.gz. Einfach mit Root-Rechten auspacken, die Verzeichnisse beginnen auf der Wurzel Deines Dateisystems.

            wget -O /tmp/Router_Server.tar.gz 'https://code.fastix.org/showFile.php?file=Projekte/Linux:Netzwerk%20f%C3%BCr%20Seminare/Router_Server.tar.gz&download=1'; su; cd /; tar -xpzf /tmp/Router_Server.tar.gz;

            wäre wohl richtig.

            Danach /root/bin/setFileRights.sh ausführen.

            # als Root cd /root/bin bash setFileRights.sh

            Hast Du Linux-Clients, die den (nicht unbedingt nötigen!) Proxy nicht automatisch updaten, dann kann das /etc/profile.d/set_http_proxy.sh. Die stört auch nicht, wenn die Clients nicht in dem Netz sind. In Gegenteil ist das eine gute Idee, wenn die Proxys (wie in vielen Firmennetzen) per proxy.pac oder wpad-Datei "beworben" werden. Windows-Clients suchen die immer.

            (Freilich kannst Du auf die Proxys (Squid, Privoxy) auch verzichten).

            Dritter Schritt: Mit ip address show oder dem älteren ifconfig kannst Du auf Deinem Router feststellen, welches Netzgerät das Internet liefert. Das, und das Gerät an welches Du den Switch oder AccessPoint hängen willst, trägst Du in /root/bin/seminarnet.settings ein.

            Fummle nicht an den Einstellungen unterhalb von

            ## Netzwerkeinstellungen für das Seminarnetz

            herum. Es sei denn Du hast alle Dateien mal durchgesehen und weißt also, was Du dann noch manuell ändern musst...

            Vierter Schritt: Wenn alles installiert und konfiguriert und angeschlossen ist, machst Du Dir Gedanken, was wohl die Skripte

            machen...

            Nochwas: Die Clients sollten nicht booten bevor das Seminarnet läuft. ... Sonst wird das nichts mit DHCP.

            1. Hello,

              danke nochmal. Komponenten und Reihenfolge soweit verstanden.

              Ich würde dann gerne noch verstehen:

              • Konfiguration von Bind
              • Die Firewall/Masquerading-Regeln.
              • DHCP-Konfiguration

              Da kämpfe ich mich erst noch durch. Ist alles schon wieder über drei Jahre her, dass ich es (fast) auswendig konnte.

              Und dann muss ich das Ganze dreimal aufbauen mit Hilfe aller alten Laptops, die ich noch zu Linux überreden konnte und den alten Handies, die mit Hilfe von Prepaid-Karten o. ä. Internet-Hotspots zur Verfügung stellen können. Virtualisiert klappt das mit dem USB-Tethering (noch) nicht. Dazu dann noch mein wackeliger "Festnetzanschluss" (der heißt so, weil er nur an Festtagen funktioniert höhöhö), macht zusammen vier Zugänge. Da müssen dann auch die IPs in deinen Skripten angepasst werden.

              Dann kann ich endlich die Geräte testen, ob sie nur balancen, oder auch trunken (wie das versprochen wird).

              Glück Auf
              Tom vom Berg

              -- Es gibt nichts Gutes, außer man tut es!
              Das Leben selbst ist der Sinn.
              1. Und dann muss ich das Ganze dreimal aufbauen mit Hilfe aller alten Laptops, die ich noch zu Linux überreden konnte

                Äh. Vorsicht!

                DHCP-Server sollte es - jedenfalls in dieser Konfiguration - nur einen pro Netz geben. Mit "Netz" meine ich das Zeug, welches sich auf OSI-Level 2 (via ARP-Adressen) unterhält.

                Virtualisiert klappt das mit dem USB-Tethering (noch) nicht.

                Das sollte eigentlich egal sein. Je nach Virtualisierungssoftware kann es aber schwierig werden. Am gängigsten ist es wohl, das USB-Gerät als normales Netzgerät des Hosts (Virtualisierungsserver) in Betrieb zu nehmen und für die Gäste zu "bridgen".

                Geräte testen, ob sie nur balancen, oder auch trunken

                Macht das nicht etwas wie route oder ip route?

                1. Hello,

                  Äh. Vorsicht!

                  DHCP-Server sollte es - jedenfalls in dieser Konfiguration - nur einen pro Netz geben. Mit "Netz" meine ich das Zeug, welches sich auf OSI-Level 2 (via ARP-Adressen) unterhält.

                  Du meinst also eine Broadcast-Domäne!?

                  Wenn die DHCP-Server normal arbeiten, müssten sich auch mehrere in einer BCD per Protokoll untereinander abstimmen, selbst wenn sie überlappende IP-Bereiche verwalten.

                  Glück Auf
                  Tom vom Berg

                  -- Es gibt nichts Gutes, außer man tut es!
                  Das Leben selbst ist der Sinn.
                  1. Wenn die DHCP-Server normal arbeiten, müssten sich auch mehrere in einer BCD per Protokoll untereinander abstimmen, selbst wenn sie überlappende IP-Bereiche verwalten.

                    Definiere "normal arbeiten".

                    Ich hab nicht grundlos geschrieben:

                    DHCP-Server sollte es - jedenfalls in dieser Konfiguration - nur einen pro Netz geben.

                    (Den fetten Teil habe ich mal wegen des neuen Interesses verändert.)

                    1. Hello,

                      Wenn die DHCP-Server normal arbeiten, müssten sich auch mehrere in einer BCD per Protokoll untereinander abstimmen, selbst wenn sie überlappende IP-Bereiche verwalten.

                      Definiere "normal arbeiten".

                      Streng nach Protokoll.

                      Glück Auf
                      Tom vom Berg

                      -- Es gibt nichts Gutes, außer man tut es!
                      Das Leben selbst ist der Sinn.