staging.inyokaproject.org

Hallo

Ich habe mal ne Frage habe mir einen tp-link WDR3600 zu gelegt da ich das mit dem openwrt und Auto Login script ideal fand für mein nächstes Projekt nur leider bekomme ich keine Verbindung zu dem Telekom fon Netz siehe Bilder ich hoffe mir kann jemand helfen

Vielen dank schonmal im Voraus

PortProxy schrieb:

Hallo,

ich habe das Login-Skript mal etwas vereinfacht und hier https://github.com/JsBergbau/TelekomFonHotspotLogin zur Verfügung gestellt. Es geht auch noch ein bisschen darüber hinaus um z.B. die MAC-Adresse zu ändern oder es berücksichtigt den Fall, dass man mit einem Surfstick den abgesetzten Linux-Rechner steuern kann.

Hallo PortProxy und alle anderen engagierten und interessierten,

ich bin zwar kein Linux-Neuling (Umstieg im Desktop-Bereich von Win auf Ubuntu vor 10 Jahren) aber beim bash-scripting gerade Einsteiger und immer wieder überrascht, wie vielseitig und flexibel unix/linux sein kann. Trotz der langen Zeit mit GUIs zieht's mich nun immer mehr zur Konsole. Habe dein Skript an meine Bedürfnisse angepasst und auch noch etwas erweitert (die "echte", harte Programmierarbeit (HTML W3B etc.) war ja bereits vorhanden): - Unterdrücken der doch noch recht langen Ausgabe der HTML-Header (obwohl bei curl bereits der quiet-Parameter gesetzt war) - Auswertung des aktuellen Verbindungszustandes und Ausgabe entsprechender Meldungen, die in ein Log-File umgeleitet werden - weniger codelastig, dafür mehr dokumentatorisch: Erläuterungen und Lösungsvorschläge für mögliche Probleme (mehr als Gedankenstütze gedacht, falls das Script monatelang läuft und dann auf einmal nicht mehr) - alles in englisch gehalten

Was hat es mit dem cookie auf sich? Wird das für die anderen Scripte benötigt (MAC-Adresse spoofen, Routing)? Ich hab's erstmal drin gelassen.

Anwendung: Das Skript läuft auf einem RPI (dient u.a. als VPN-Endpunkt eines Site-2-Site-Routings) ; dieser greift über NAPT-Firewall-Gateway / Transfernetz auf einen TP-940N in der DMZ (dd-wrt) zu, der als wireless-client wiederum am Telekom_FON-Accespoint hängt. Das Skript wird als cronjob regelmäßig ausgeführt und läuft wunderbar...endlich kein manuelles Anmelden mehr und sämtliche Geräte hinter dem Firewall-Gateway haben stets Zugriff aufs Internet und auch das VPN. Wenn ich alles richtig verstanden habe, werden die Zugangsdaten per TLS (https) verschlüsselt übertragen und sind somit erstmal vor einfachen Abhörattacken geschützt. Wichtig bei dieser Variante war mir, dass die Zugangsdaten nicht auf einem Host abgelegt sind, was sich in der DMZ bzw. direkt am ungesicherten Zugangsnetz befindet. Zudem bin ich mit raspian OS vertrauter als mit busybox und natürlich kann man beim RPI schnell mal was aus dem repository installieren...das wird bei busybox schon schwieriger (wenig Flash-Speicher im Router + kein apt).

Login-Script:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

#!/bin/bash

# login-credentials
user="username%40t-online.de"
pw="password"

# local network interface
device="eth0"

# hint +  accesscheck-host
delcheck="./hintcookie"
inetaccesscheckhost="1.1.1.1"

# user-agent spoofed to Firefox to make our automated login look more like a manual one (being less suspicious)
# connection-establish-timeout, so the script will not hang if login is already done (there is no response from 8.8.8.8 due to missing re-direct)

 d=$(date)
 echo "$d ----------start of script--------"
 d=$(date)
 echo "$d waiting up to 5s to examine if there is an http-connection-redirect initiated from the Telekom_FON-network..."
 d=$(date)
 echo "$d (redirect is executed => auto-login will be processed ; no redirect takes place => already logged in, no further action)"
daten=$(curl -A 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0' -s --connect-timeout 5 --insecure --location --interface $device --cookie-jar hintcookie http://8.8.8.8)
loginURL=$(echo "$daten" | grep -oP '(?<=<LoginURL>).*(?=</LoginURL>)' | sed -r 's/\&amp;/\&/g') # replace &amp; with & in last step

# echo 2
echo "$loginURL" > /dev/null

antwort=$(curl -A 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0' -s --insecure --location --interface $device --location-trusted --cookie-jar hintcookie --header 'cache-control: no-cache' --header 'content-type: application/x-www-form-urlencoded' --data "UserName=${user}&FNAME=0&button=Login&OriginatingServer=http%3A%2F%2Fgoogle.de&Password=${pw}" "$loginURL") > /dev/null

echo "$antwort" > /dev/null


# checko for hint-cookie and delete, if it exists
if [ -f "$delcheck" ];
then 

      rm $delcheck > /dev/null
fi

      
if ping -q -c1 "$inetaccesscheckhost" > /dev/null; 
      
then
     d=$(date) 
     echo "$d Permisson to internet access via Telekom_FON is granted (successfully tested by ICMP echo-request / -reply to/from $inetaccesscheckhost)."
     echo "$d ----------end of script----------"
else
     d=$(date)
     echo "$d Permission to internet access via Telekom_FON seems NOT to be granted - ICMP echo-request / -reply to $inetaccesscheckhost failed."
     echo "$d Refer to solve_connection_problems.txt for possible solutions."
     echo "$d ----------end of script----------"
fi

Logout-Script:

1
2
3
4
5
6
7
8
9

#!/bin/bash

# fetching Logout-URL from WLAN-controller to close the actual session:
curl -s -A 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0' http://172.17.2.1:3990/logoff > /dev/null
d=$(date)
echo "$d----------start of script----------"
echo "$d Logged out successfully from internet access via Telekom_FON." >> log.txt
echo "$d Your local WLAN/IP-parameters may still be persisent until you disconnect from the SSID 'Telekom_FON'." >> log.txt
echo "$d----------end of script------------"

Und hier schließlich noch die Erläuterungen und Hinweise (resolve_connection_problems.txt):

If you expieriene problems to get internet access doing the following steps might help:

1. Execute the login-script once again - sometimes this is necessary because the WLAN controller didn't catch the login-request.
   You may automatically and regulary run the script, e.g. by a cronjob.
   If you are already logged in the script will recognize this and will stay calm (only giving status-report and not sending your login-credentials unecessarily often).
2. Check your network interface: make sure you have referenced it according to your OS in the script (e.g. eth0 or wlan0).
3. Check your login-credentials: make sure there are no typing-mistakes and you have embedded them correctly URL-encoded in the script. 
   (With '@' they contain at least one special character and you might be using further special characters like '#', '*', etc., which have to be encoded, too.)
   Note: also take care of securing your credentials from unauthorized access (minimum security can be achieved by setting local filesystem access rights).   
4. Check your layer1-6-connections to Telekom_FON-Hotspot - e.g. try to open the loginpage from another WLAN-client than that one this script is executed on and log in manually.
   If failure occurs at this point the script won't work, too.
------------------
Possible causes for connection errors and how to resolve them:
a)layer 1+2 disconnection => re-connect to the SSID
  As long as there is good RSSI / S/N-ratio this shoud not happen ; the wirelss link can stay up for days permanently if both interfaces do so, too.
b)layer 3-6 parameters lost or no more valid => release and renew IP-parameters via DHCP on the client (existing upper layer session connections 4-6 will be closed by the WLAN-controller when a DHCP-release or -ack is performed)
  Simply re-boot your client if you don't know how to manage IP-parameters directly.
  You may also script commands like ifdown/ifup etc..

  There are two different, network-sided time-outs which lead to blocking internet access:
  - 15min network traffic inactivity: there was no traffic exchange between your client and the internet for 15min
    => this should not be a problem: every average client has at least a few services running in the background that regulary access the internet (e.g. NTP)  
  - 6hrs general session time-out: enforced closure of session, regardless of other parameters or states

To work around a) and b) reliably it may be necessary to tempoarily spoof the MAC address of your client's wireless adaptor to another value than that used previously.
If you don't, you might have to wait up to 10min until the AP or DHCP-server lets you in again (seems to be an issue in the Telekom_FON-netinfrastructure).
You may include this with scripting in point b).
-----------------
Please also keep in mind that the 'Telekom_FON'-accesspoints are operated by non-commercial, private individuals. 
This means that an operator may stop the service anytime for any period of time. 
In that case you could scan your wireless enviornement hopefully to find another accesspoint with the SSID 'Telekom_FON' from another operator within your wireless range.
The new AP has another MAC-address so if your wireless client does not support automatic layer2-roaming you'll have to manually re-connect to associate.
----------------
Last but not least: take care of your privacy and lock out eavesdroppers!
Since we are using a fully open, unsecured wireless network you should take care of your online privacy when transfering personal data:
- only use TLS-secured connections (https, imaps etc.)
- use a VPN-service of your choice to tunnel all your traffic ;
  => you may set up the L2TP/IPsec (IKE/Xauth PSK) 'wlan-vpn.t-mobile.net' with your already existing credentials (not tested yet)
----------------

Auszug aus der generierten Log-Datei (Fehlermeldung mit Logout-Script simuliert):

Mo 10. Aug 01:01:01 BST 2020 ----------start of script--------
Mo 10. Aug 01:01:01 BST 2020 waiting up to 5s to examine if there is an http-connection-redirect initiated from the Telekom_FON-network...
Mo 10. Aug 01:01:01 BST 2020 (redirect is executed => auto-login will be processed ; no redirect takes place => already logged in, no further action)
Mo 10. Aug 01:01:06 BST 2020 Permisson to internet access via Telekom_FON is granted (successfully tested by ICMP echo-request / -reply to/from 1.1.1.1).
Mo 10. Aug 01:01:06 BST 2020 ----------end of script----------
Mo 10. Aug 01:02:01 BST 2020 ----------start of script--------
Mo 10. Aug 01:02:01 BST 2020 waiting up to 5s to examine if there is an http-connection-redirect initiated from the Telekom_FON-network...
Mo 10. Aug 01:02:01 BST 2020 (redirect is executed => auto-login will be processed ; no redirect takes place => already logged in, no further action)
Mo 10. Aug 01:02:01 BST 2020 Permission to internet access via Telekom_FON seems NOT to be granted - ICMP echo-request / -reply to 1.1.1.1 failed.
Mo 10. Aug 01:02:01 BST 2020 Refer to solve_connection_problems.txt for possible solutions.
Mo 10. Aug 01:02:01 BST 2020 ----------end of script----------

Viele Grüße und viel Spaß beim Ausprobieren!

ToDo: - die Scripte noch verfeinern / intelligenter gestalten (u.a. Redundanzen Echo-Befehlen bündeln) - Fehlerabfrage / -meldungen verfeinern (was genau ist Ursache für gescheiterte Internetverbindung? Welche Netzwerkschichten / Verbindungsabschnitte sind up/down? z.B. ping möglich und wenn ja, wohin (extern, WAN/Intranet Hotspot, DMZ, intern) ; DNS-Abfragen möglich (diese funktionieren OHNE vorherigen Login)

P.S.: Die von der Telekom angegeben Werte für die Time-Outs scheinen nicht ganz korrekt zu sein: DHCP-lease ist bei mir 10min statt 15 (sofern das was mit dem Auto-Logout bei ausbleibendem Datenverkehr zu tun hat) und das generelle Schließen der Online-Sitzung nach 6h (Unterbrechnung müsste mindestens für 10s auftreten, wenn das Login-Script genau im richtigen Moment ausgeführt wird) konnte ich auch nicht feststellen. Unterbrechungen gab es immer nur sporadisch alle ca. 12-24h.

Mittlerweile hab' ich das Skript noch weiter angepasst: - als Test-Referenz für den Zugang zum Internet statt 1.1.1.1 (cloudflare) oder 8.8.8.8 (google) gmx.net eingetragen → falsche Fehlermeldungen aufgrund von Paketverlusten von ca. 10-15 Meldungen / Tag auf 0 reduziert (ich dachte zunächst, dass es an Überlastung des lokalen Telekom_FON-APs liegen würde aber nach genauerem Schicht2- und -3-Monitoring konnte dies ausgeschlossen werden)

- curl-Option "--insecure" entfernt ; mittlerweile verfügen die Telekom_FON-APs bzw. deren Landing-Page des Captive-Portals über gültige TLS-Zertifikate ; aufgrund der fehlenden Layer2-Absicherung des offenen WLANs (kein WPA/WPA2!) ist dies unbedingt zu empfehlen, um die Zugangsdaten während der Übertragung gegen Abhören zu sichern!

- Neustrukturierung des Konzeptes der Checks und aussagekräftiger Fehlermeldungen in Anlehung an einzelne Verbindungsschichten

- Beschränkung der Ausgabe auf Fehlermeldungen, um Log-Datei gering und nur mit den wesentlichen Inhalten zu füllen (Auskommentierung bei Bedarf einfach entfernen)

- nachvollziehbare Dokumentation (Kommentare im Code)

- Ansätze für automatische Erkennung der IP-Parameter des lokalen Telekom_FON-Netzwerkes (aktuell 172.17.2.0/24)

- Auslagerung von Parametern aus dem Codeblock per Variablen den Kopf des Skriptes zwecks Verwaltung an zentraler Stelle

ToDo:

- Auslagerung echo-Fehlermeldungen (mehrere Zeilen) aus den jeweiligen Code-Blöcken in geeignete Speicher (Variablen, Arrays, externe Textdatei...)

- automatische Erkennung der Ethernet-Schnittstelle, die eine Route zum Telekom_FON-Netzwerk bereit stellt ; dies wäre über eine Auswertung der Login-URL des Captive-Portals mittels Probing auf allen verfügbaren Schnittstellen möglich

- automatische Erkennung IP-Parameter des Telekom_FON-Netzwerkes über mehrere IP-Netzabschnitte hinweg (pivates LAN <> |stateful NAPT-Firewall| <> DMZ-LAN |stateful NAPT-Firewall| <> Telekom_FON-LAN) ; auch dies wäre z.B. durch Auswertung der Login-URL des Captive-Portals möglich

- Erstellen eines grafischen Schemas / Übersicht zwecks besserer Verständlichkeit

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123

#!/bin/bash

# login-credentials
user="user%40t-online.de"
pw="password"

# local network interface
device="wlp3s0"

# assumption: already connected to Telekom_FON-accesspoint on layer 1-3.
# local connection should be possible permanently for days (regardless of internet access)
# standard DHCP-lease-time is 10min but will renewed seamlessly without connection breakup

# automatically examine default gateway to check for basic connectivity later
# experimental ; to be prepared if Telekom_FON changes local IP-adressing parameters...
# note: only works if the host the script is executed on is directly connected to Telekom_FON (must be the first hop / gateway!)
# read x x df_gw x< <(ip route g 1)

# or alternatively: manually examine and define default gateway
df_gw="172.17.2.1"

# external host for ICMP-check
InetAccessCheckhost="gmx.net"

# external URL to request for grabbing the Telekom_FON-captive-portal-URL
GrabCaptivePortalURL="http://gmx.net"

# referrer to the troubleshooting-guide
tr_sh="for further trouble-shooting refer to ./tr_sh.txt"


# some parameters for the curl command:
# user-agent spoofed to Firefox to make our automated login look more like a manual one (being less suspicious)
# connection-establish-timeout, so the script will not hang if there's a problem with catching the login-URL


# deactivating start-report-output of the script (only needed for verbose logging...)
# d=$(date)
# echo "$d [#1] Checking if internet access is already established..."
  ping -q -c1 "$InetAccessCheckhost" > /dev/null;
 
  if [ $? -eq 0 ]

     then
          : # no-op-command from old fashioned, historical Thomson shell
     # we normally just want to get errors in the log ; feel free to activate, if you also want (a lot of!) succeeding messages from the watchdog...
     # d=$(date)
     #echo "$d [check#1] passed (ping to $InetAccessCheckhost)."
     #echo "$d Internet access already established."
     #echo "$d ---------- end of script ----------"
     #echo ""

     else
     d=$(date)
     echo "$d [check#1/3] watchdog external failed (ping to $InetAccessCheckhost)"
     echo "$d [check#2/3] probing to internal Telekom_FON-accesspoint..."

       
       ping -q -c1 "$df_gw" > /dev/null;

       if [ $? -eq 0 ]

	  then
	  d=$(date)
	  echo "$d [check#2/3] internal probe successful (ping to $df_gw)"
          echo "$d             => not logged in ;"
	  echo "$d             => executing auto-login (may take up to 10s...)"

          # request and catch login-URL ; connecting to some external host will result in redirecting to the Telekom_FON login-landing page, if not logged in
          daten=$(curl -A 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0' -s --connect-timeout 5 --location --interface $device $GrabCaptivePortalURL)
          loginURL=$(echo "$daten" | grep -oP '(?<=<LoginURL>).*(?=</LoginURL>)' | sed -r 's/\&amp;/\&/g') # replace &amp; with & in last step

          # output for monitoring the previously caught login-URL - only needed for debugging
          # echo "$loginURL"


          # open modified login-URL with pre-definded login-credentials
          # normally this URL would be generated locally in your browser from the credentials you entered manually into the login page's form as soon as you click on the login-button
          # redirect output to /dev/null to stay calm (full header output only needed for debugging)
          antwort=$(curl -A 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0' -s --location --interface $device --location-trusted --header 'cache-control: no-cache' --header 'content-type: application/x-www-form-urlencoded' --data "UserName=${user}&FNAME=0&button=Login&OriginatingServer=http%3A%2F%2Fduckduckgo.com&Password=${pw}" "$loginURL") > /dev/null

	  # giving the Telekom_FON-network a little time to process the login (creating and assigning session parameters)...
	  sleep 5s
          # output for monitoring previously processed login-data (full header output only needed for debugging)
          # echo "$antwort"

          d=$(date)
	  echo "$d [check#3/3] verifying that internet access has really been established..."
          
	  ping -q -c1 "$InetAccessCheckhost" > /dev/null;
 
            if [ $? -eq 0 ]

              then
              d=$(date)
              echo "$d [check#3/3] passed (ping to $InetAccessCheckhost)"
              echo "$d             => internet access re-established"
	      echo "$d ---------- end of script ----------"
              echo ""

              else
              d=$(date)
              echo "$d [check#3/3] failed - automated login-attempt didn't work (2nd try ping to $InetAccessCheckhost)"
	      echo "$d             a) Make sure login-credentials are valid and correctly embedded at the top of the script."
	      echo "$d             b) Try again later or take a more verbose, debugging look at the script's output:"
	      echo "$d                => Remove '#' before URL-based echo-commands and/or the '/dev/null'-redirect."
	      echo "$d                => $tr_sh"
              echo "$d ---------- end of script ----------"
	      echo ""

	    fi


          else
          d=$(date)
          echo "$d [check#2/3] internal probe failed (ping to $df_gw)"
          echo "$d             => no connection to Telekom_FON-accesspoint"
	  echo "$d             => $tr_sh"
	  echo "$d ------------ end of script ------------"
	  echo ""

       fi	  
  fi

Beispiele für die Log-Ausgaben (ich leite die Ausgaben mit ">>" im Cronjob in eine Datei um):

So sollte es idealerweise aussehen, alle 24h Login (vermutlich eine netzseitigen Zwangstrennung durch Telekom_FON ; die in den Telekom-Foren immer wieder erwähnte Zwangstrennung nach 6h schneit nicht korrekt zu sein):

So 20. Sep 23:45:11 BST 2020 [check#1/3] watchdog external failed (ping to gmx.net)
So 20. Sep 23:45:11 BST 2020 [check#2/3] probing to internal Telekom_FON-accesspoint...
So 20. Sep 23:45:11 BST 2020 [check#2/3] internal probe successful (ping to 172.17.2.1)
So 20. Sep 23:45:11 BST 2020             => not logged in ;
So 20. Sep 23:45:11 BST 2020             => executing auto-login (may take up to 10s...)
So 20. Sep 23:45:18 BST 2020 [check#3/3] verifying that internet access has really been established...
So 20. Sep 23:45:18 BST 2020 [check#3/3] passed (ping to gmx.net)
So 20. Sep 23:45:18 BST 2020             => internet access re-established
So 20. Sep 23:45:18 BST 2020 ---------- end of script ----------

Mo 21. Sep 23:46:11 BST 2020 [check#1/3] watchdog external failed (ping to gmx.net)
Mo 21. Sep 23:46:11 BST 2020 [check#2/3] probing to internal Telekom_FON-accesspoint...
Mo 21. Sep 23:46:11 BST 2020 [check#2/3] internal probe successful (ping to 172.17.2.1)
Mo 21. Sep 23:46:11 BST 2020             => not logged in ;
Mo 21. Sep 23:46:11 BST 2020             => executing auto-login (may take up to 10s...)
Mo 21. Sep 23:46:18 BST 2020 [check#3/3] verifying that internet access has really been established...
Mo 21. Sep 23:46:18 BST 2020 [check#3/3] passed (ping to gmx.net)
Mo 21. Sep 23:46:18 BST 2020             => internet access re-established
Mo 21. Sep 23:46:18 BST 2020 ---------- end of script ----------

Di 22. Sep 23:47:11 BST 2020 [check#1/3] watchdog external failed (ping to gmx.net)
Di 22. Sep 23:47:11 BST 2020 [check#2/3] probing to internal Telekom_FON-accesspoint...
Di 22. Sep 23:47:11 BST 2020 [check#2/3] internal probe successful (ping to 172.17.2.1)
Di 22. Sep 23:47:11 BST 2020             => not logged in ;
Di 22. Sep 23:47:11 BST 2020             => executing auto-login (may take up to 10s...)
Di 22. Sep 23:47:27 BST 2020 [check#3/3] verifying that internet access has really been established...
Di 22. Sep 23:47:27 BST 2020 [check#3/3] passed (ping to gmx.net)
Di 22. Sep 23:47:27 BST 2020             => internet access re-established
Di 22. Sep 23:47:27 BST 2020 ---------- end of script ----------

Und so sieht es aus, wenn Fehler auftreten:

Probleme beim Verbinden zum Netzzugang (association to SSID, DHCP-acknowledge):

Mi 16. Sep 04:16:02 BST 2020 [check#1/3] watchdog external failed (ping to gmx.net)
Mi 16. Sep 04:16:02 BST 2020 [check#2/3] probing to internal Telekom_FON-accesspoint...
Mi 16. Sep 04:16:02 BST 2020 [check#2/3] internal probe failed (ping to 172.17.2.1)
Mi 16. Sep 04:16:02 BST 2020             => no connection to Telekom_FON-accesspoint
Mi 16. Sep 04:16:02 BST 2020             => for further trouble-shooting refer to ./tr_sh.txt
Mi 16. Sep 04:16:02 BST 2020 ------------ end of script ------------

Probleme beim Login-Vorgang (Freischaltung Internet-Zugriff):

Mi 16. Sep 17:06:11 BST 2020 [check#1/3] watchdog external failed (ping to gmx.net)
Mi 16. Sep 17:06:11 BST 2020 [check#2/3] probing to internal Telekom_FON-accesspoint...
Mi 16. Sep 17:06:11 BST 2020 [check#2/3] internal probe successful (ping to 172.17.2.1)
Mi 16. Sep 17:06:11 BST 2020             => not logged in ;
Mi 16. Sep 17:06:11 BST 2020             => executing auto-login (may take up to 10s...)
Mi 16. Sep 17:06:17 BST 2020 [check#3/3] verifying that internet access has really been established...
Mi 16. Sep 17:06:27 BST 2020 [check#3/3] failed - automated login-attempt didn't work (2nd try ping to gmx.net)
Mi 16. Sep 17:06:27 BST 2020             a) Make sure login-credentials are valid and correctly embedded at the top of the script.
Mi 16. Sep 17:06:27 BST 2020             b) Try again later or take a more verbose, debugging look at the script's output:
Mi 16. Sep 17:06:27 BST 2020                => Remove '#' before URL-based echo-commands and/or the '/dev/null'-redirect.
Mi 16. Sep 17:06:27 BST 2020                => for further trouble-shooting refer to ./tr_sh.txt
Mi 16. Sep 17:06:27 BST 2020 ---------- end of script ----------

Ergänzung: Ausführen des Skriptes auf einem openWRT-System - getestet auf BusyBox v1.30.1 openWRT 19.07.3, r11063-85e04e9f46, Hardware TP-Link CPE210

- openWRT nutzt eine angepasste, abgespeckte Shell, siehe https://openwrt.org/docs/guide-developer/write-shell-script

1. Skript per scp auf den Speicher von openWRT kopieren und absichern (rwx nur für root setzen = chmod 700 /<Pfad>/script.sh)

2. Skript in vim öffnen und in der ersten Zeile #/bin/bash! durch #/bin/sh! ersetzen (sonst erkennt die ash-Shell das Skript nicht)

3. Internetzugang am openWRT-Gateway bereitstellen (z.B. manuell bei Telekom_FON anmelden)

4. Paketlisten von openWRT auf den aktuellen Stand bringen...

1

opkg update

...und anschließend

1

opkg install curl grep

ausführen, um die benötigten Pakete zu installieren bzw. auf den neusten Stand zu bringen (bei mir hat curl gefehlt und grep war veraltet, sodass es die im Skript übergebenen Parameter nicht korrekt verarbeiten konnte)

5. Aufrufen des Skripts:

1

/<Pfad>/skript.sh

zusätzliche Tipps für die Sicherheit

1. Nicht die Zugangsdaten des Hauptbenutzers verwenden sondern einen (kostenlosen) Inklusivnutzer im Telekom-Kundenportal erstellen. Sollten die Zugangsdaten doch mal in falsche Hände geraten (wie bereits erwähnt: offenes, ungeschütztes WLAN im 24h-Betrieb!) so braucht man nicht gleich den gesamten Anschluss des Hauptbenutzers sperren.

2. Eine zeitgleiche Mehrfachanmeldung an verschiedenen Telekom_FON-Accesspoints mit denselben Zugangsdaten ist möglich. Zwecks besserer Verwaltung / Übersicht sollte jedoch für jede Anwendung ein eigener Mitbenutzer mit eigenen Zugangsdaten erstellt werden (nützlich bei Missbrauchsfällen).

3. VPN nutzen, um das Mitlesen der eigenen Aktivitäten am ungeschützten WLAN durch Fremde zu unterbinden (z.B. TOR Browser nutzen oder VPN gleich direkt in openWRT einrichten)

4. Das private LAN nicht direkt mit Telekom_FON koppeln, sondern über ein sog. Transfernetz / DMZ. Die Gateways inklusive Firewalls auf beiden Seiten des Transfernetzes sollten idealerweise auf unterschiedlichen Systemen/Produkten basieren (z.B. bei mir eine Fritzbox hinter dem CPE210). Dies erschwert es Angreifern, bestimmte Sicherheitslücken gezielt auszunutzen.

5. Sensible (Zugangs-)daten bzw. VPN-Endpunkte auf abgetrennten Netz- und Speicherbereichen ablegen (nicht auf Hosts, die als Gateway zwischen DMZ und Zugangsnetz dienen)

Hallo,

das Script funktioniert immer noch tadellos.

Gibt es auch die Möglichkeit, dass das Script auf einem Android 10 (mit root) lauffähig gemacht werden kann?

LG M

Das Skript funktioniert weiterhin. Allerdings habe ich noch nicht rausgefunden, wo man /lib/functions.sh herbekommt; daher musste ich es etwas umschreiben. Muss man da ein bestimmtes OpenWRT opkg installieren?

Wenn man sich nicht mit einem Telekom-Konto, sondern mit einem Fon-Konto anmelden möchte, muss man den data-String im Post-Aufruf um &partner=fon ergänzen. Sollte entsprechend mit den anderen Partnern funktionieren.

gschwarz schrieb:

Das Skript funktioniert weiterhin. Allerdings habe ich noch nicht rausgefunden, wo man /lib/functions.sh herbekommt; daher musste ich es etwas umschreiben. Muss man da ein bestimmtes OpenWRT opkg installieren?

Wenn man sich nicht mit einem Telekom-Konto, sondern mit einem Fon-Konto anmelden möchte, muss man den data-String im Post-Aufruf um &partner=fon ergänzen. Sollte entsprechend mit den anderen Partnern funktionieren.

bei mir (GL.inet AR 150 net ext) ist die /lib/functions.sh enthalten, sie ist auch in den Base Files enthalten: https://github.com/openwrt/openwrt/blob/master/package/base-files/files/lib/functions.sh

ich hab heute mal versucht, das gute Skript von vmlinuz-kernel einzubinden, allerdings scheint irgendwas nicht zu funktionieren.

Ich hab alles soweit konfiguriert (openwrt auf einem gl.inet gl-ar-150) und das Skript lässt sich ausführen. Allerdings kommt immer folgendes:

+ user=491711234567
+ pw=a00-b00-c00
+ device=wwan2
+ df_gw=172.17.2.1
+ InetAccessCheckhost=gmx.net
+ GrabCaptivePortalURL=https://telekom.portal.fon.com
+ tr_sh='for further trouble-shooting refer to ./tr_sh.txt'
+ date
+ d='Tue Nov 16 21:47:51 CET 2021'
+ echo 'Tue Nov 16 21:47:51 CET 2021 [#1] Checking if internet access is already established...'
Tue Nov 16 21:47:51 CET 2021 [#1] Checking if internet access is already established...
+ ping -q -c1 gmx.net
+ '[' 1 -eq 0 ]
+ date
+ d='Tue Nov 16 21:48:01 CET 2021'
+ echo 'Tue Nov 16 21:48:01 CET 2021 [check#1/3] watchdog external failed (ping to gmx.net)'
Tue Nov 16 21:48:01 CET 2021 [check#1/3] watchdog external failed (ping to gmx.net)
+ echo 'Tue Nov 16 21:48:01 CET 2021 [check#2/3] probing to internal Telekom_FON-accesspoint...'
Tue Nov 16 21:48:01 CET 2021 [check#2/3] probing to internal Telekom_FON-accesspoint...
+ ping -q -c1 172.17.2.1
+ '[' 0 -eq 0 ]
+ date
+ d='Tue Nov 16 21:48:01 CET 2021'
+ echo 'Tue Nov 16 21:48:01 CET 2021 [check#2/3] internal probe successful (ping to 172.17.2.1)'
Tue Nov 16 21:48:01 CET 2021 [check#2/3] internal probe successful (ping to 172.17.2.1)
+ echo 'Tue Nov 16 21:48:01 CET 2021             => not logged in ;'
Tue Nov 16 21:48:01 CET 2021             => not logged in ;
+ echo 'Tue Nov 16 21:48:01 CET 2021             => executing auto-login (may take up to 10s...)'
Tue Nov 16 21:48:01 CET 2021             => executing auto-login (may take up to 10s...)
+ curl -A 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0' -s --connect-timeout 5 --location --interface wwan2 https://telekom.portal.fon.com
+ daten=
+ + + grep -oP '(?<=<LoginURL>).*(?=</LoginURL>)'
echo 
sed -r 's/\&amp;/\&/g'
+ loginURL=
+ echo 

+ curl -A 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0' -s --location --interface wwan2 --location-trusted --header 'cache-control: no-cache' --header 'content-type: application/x-www-form-urlencoded' --data 'UserName=49171123456&FNAME=0&button=Login&OriginatingServer=http%3A%2F%2Fduckduckgo.com&Password=a00-b00-c00' 
+ antwort=
+ sleep 5s
+ echo 

+ date
+ d='Tue Nov 16 21:48:06 CET 2021'
+ echo 'Tue Nov 16 21:48:06 CET 2021 [check#3/3] verifying that internet access has really been established...'
Tue Nov 16 21:48:06 CET 2021 [check#3/3] verifying that internet access has really been established...
+ ping -q -c1 gmx.net
+ '[' 1 -eq 0 ]
+ date
+ d='Tue Nov 16 21:48:16 CET 2021'
+ echo 'Tue Nov 16 21:48:16 CET 2021 [check#3/3] failed - automated login-attempt didn'"'"'t work (2nd try ping to gmx.net)'
Tue Nov 16 21:48:16 CET 2021 [check#3/3] failed - automated login-attempt didn't work (2nd try ping to gmx.net)
+ echo 'Tue Nov 16 21:48:16 CET 2021             a) Make sure login-credentials are valid and correctly embedded at the top of the script.'
Tue Nov 16 21:48:16 CET 2021             a) Make sure login-credentials are valid and correctly embedded at the top of the script.
+ echo 'Tue Nov 16 21:48:16 CET 2021             b) Try again later or take a more verbose, debugging look at the script'"'"'s output:'
Tue Nov 16 21:48:16 CET 2021             b) Try again later or take a more verbose, debugging look at the script's output:
+ echo 'Tue Nov 16 21:48:16 CET 2021                => Remove '"'"'#'"'"' before URL-based echo-commands and/or the '"'"'/dev/null'"'"'-redirect.'
Tue Nov 16 21:48:16 CET 2021                => Remove '#' before URL-based echo-commands and/or the '/dev/null'-redirect.
+ echo 'Tue Nov 16 21:48:16 CET 2021                => for further trouble-shooting refer to ./tr_sh.txt'
Tue Nov 16 21:48:16 CET 2021                => for further trouble-shooting refer to ./tr_sh.txt
+ echo 'Tue Nov 16 21:48:16 CET 2021 ---------- end of script ----------'
Tue Nov 16 21:48:16 CET 2021 ---------- end of script ----------
+ echo 

+ set +x

in dem Skript habe ich: -meinen Usernamen/meine Handynummer eingegeben, allerdings ohne %40t-online.de bzw %t-mobile.de. Genauso wie ich den Usernamen von der 9526 von der Telekom übergeben bekommen habe (und mich so auch über das Webinterface manuell einloggen kann)

-das Passwort

-und mein local network interface auf wwan2 angepasst, das ist das Interface, an dem der Client "Telekom_FON" hängt.

Wie komme ich denn hier weiter? Ich freue mich über jeden Tipp....

ich beantworte mir die Fragen mal selbst ☺.

-nach Update auf das aktuelle curl (meine alte Distribution, die mit dem Teil geliefert wurde, liess sich nicht mehr updaten, -der Auswahl des korrekten Interfaces (immer das nehmen, welches direkt mit dem WLAN verbindet, sonst meldet curl -v "couldnt bind to 'xyz'") -und das ändern des Usernamen von 4917112345 auf 4917112345%40t-mobile.de, auch wenn die Zugangsdaten was anderes sagen

hat es dann funktioniert. Cooles Skript, wird am Wochenende in Betrieb genommen!!!!

Frohes Neues!

Vielen Dank für die Mühen bei der stetigen Aktualisierung und Anpassung des Skripts.

Das Fon Signal ist in meiner Wohnung zu schwach. Dieses möchte ich zunächst mit meinem Repeater verstärken (TL-WA850RE) bevor ich den automatisierten Login durchführe. Auf den fon Router habe ich keinen Zugriff. Nur einen Benutzer.

Wie gehe ich dabei am Besten vor?

1. open-wrt auf dem Repeater flashen 2. repeater/ repeater bridge mode aktivieren 3. Das Skript von JsBergbau installieren?

Gibt es sonst was man dabei beachten sollte?

PS: Super. Im Dezember die Funktion entdeckt jetzt soll sie auch demnächst von der Telekom abgeschaltet werden. Schade! ☹

ubuntuschorsch schrieb:

ich beantworte mir die Fragen mal selbst ☺.

-nach Update auf das aktuelle curl (meine alte Distribution, die mit dem Teil geliefert wurde, liess sich nicht mehr updaten, -der Auswahl des korrekten Interfaces (immer das nehmen, welches direkt mit dem WLAN verbindet, sonst meldet curl -v "couldnt bind to 'xyz'") -und das ändern des Usernamen von 4917112345 auf 4917112345%40t-mobile.de, auch wenn die Zugangsdaten was anderes sagen

hat es dann funktioniert. Cooles Skript, wird am Wochenende in Betrieb genommen!!!!

Hey Schorsch und auch alle anderen Verfasser der letzten Posts bzw. stille Mitleser,

solche Rückmeldungen erfreuen, vielen Dank. Das Problem mit einer veralteten curl-Version kann ich bestätigen, war bei den ersten Versuchen mit dem Skript auf openWRT bei mir auch.

An dieser Stelle gebe ich direkt noch einen großen Dank an dich zurück, Schorsch, hast mir viel Mühe/Recherche erspart, dazu muss ich erst etwas ausholen:

- bisher habe ich den kostenlosen "WLAN-to-Go"-Dienst im Rahmen eines bestehenden Festnetzanschlusses einer Vertrauensperson an Telekom-Hotspots genutzt

- zwar wurde das Backend des "WLAN-to-Go"-Dienstes tatsächlich abgeschaltet (pünktlich zum 01.03.2022 funktionierten meine bisherigen Zugangsdaten nicht mehr) jedoch läuft die technische Netzinfratstruktur der von privaten Heim-WLAN-Routern bereit gestellten SSIDs "Telekom_FON" wie bisher weiter

- als Nicht-Telekom-Kunde kann man natürlich über die Vorschalte-Seite für (im Verhältnis zu der vorher kostenlosen Nutzung) recht teure Tarife verschiedener Flatrates freischalten ; weiterhin müsste man dies (je nach gebuchtem Tarif / Zeitkontingent) nach Ablauf manuell verlängern (bei anderen Anbietern wie z.B. einem größeren TV-BK-Netzbetreiber lassen sich solche Tarife auch als monatlich kündbarer post-paid-Vertrag abschließen, was mit €20/mtl. noch vertretbar gewesen wäre, allerdings ist bei mir kein solches WLAN in Reichweite)

Daher an dieser Stelle der Tipp an weitere, ggf. Betroffene: in der aktuellen Tarif-Serie "Telekom Magenta Mobil" sind teilweise WLAN-Hotspot-Flats kostenfrei enthalten, welche sich über die noch bestehenden SSIDs nutzen lassen. Ich nutze z.B. nun den Tarif Magenta Prepaid M Mobil für €10/mtl. ; rein kalkulatorisch gesehen also nun €5/mtl. für die Mobilfunkleistungen (siehe Tarifinfos Telekom) und €5/mtl. für die unbegrenzte Hotspot-Flat, da kann man wegen Kosten bzw. Flexibilität (monatlich kündbar) echt nicht meckern.

Die Zugangsdaten erhält man per SMS (Text "OPEN" an 9526 senden) - im Skript eintragen wie von Schorsch beschrieben, dann funktioniert es tatsächlich auch mit diesen Tarifen und das Skript landet nicht in der Ablage im Archiv, wie ich zunächst befürchtet hatte 😀

Achtung, weitere Stolperfalle: Dieser SMS-Versand ist kostenpflichtig (19ct), somit muss ausreichend Prepaid-Guthaben vorhanden sein! Beim Kauf / Aktivieren der Prepaid-Karte wird standardmäßig nur soviel Guthaben aufgeladen, wie für den gewählten Tarif erforderlich ist, in meinem Fall also €10. Nach Aktivierung der Karte werden €9,95 abgebucht, somit verbleiben 5ct. Diese reichen zum Versand der kostenpflichtigen Aktivierungs-SMS nicht aus und man erhält ständig wenig aussagekräftige Fehlermeldungen wie "Versand nicht möglich". Erschwerend kommt hinzu, dass beim o.g. Tarif eine SMS-Flat ins Telekom Mobilfunknetz enthalten ist und sich somit natürlich zahlreiche SMS erfolgreich versenden ließen (Zielrufnummer war zufällig auch im Telekom Mobilfunknetz 😛 ) Also muss man erst noch mal nachladen.

Hat alles geklappt braucht man nur noch darauf achten, dass zum jeweiligen Abbuchungszeitpunkt ausreichend Guthaben vorhanden ist.

Ist dies nicht der Fall werden die Leistungen gemäß Tarif ausgesetzt:

- Freiminuten, Datenvolumen WWAN/LTE

- Hotspot-Flat WLAN

→ Abrechnung nach tatsächlichem Verbrauch (Minutenpreis Telefonie + Hotspotzugang), bis das Restguthaben aufgebraucht ist?

→ nach erneutem Aufladen erneute Anforderung der Zugangsdaten für Hotspot-Flat erforderlich?

Wie sich das im Detail verhält, hab' ich noch nicht in Erfahrung bringen können.

In diesem Sinne: viel Spaß beim weiteren Nutzen (und Sparen) von Telekom_FON-Hotspots.

Gruß, vmlinuz

maut5rt schrieb:

Frohes Neues!

Vielen Dank für die Mühen bei der stetigen Aktualisierung und Anpassung des Skripts.

Das Fon Signal ist in meiner Wohnung zu schwach. Dieses möchte ich zunächst mit meinem Repeater verstärken (TL-WA850RE) bevor ich den automatisierten Login durchführe. Auf den fon Router habe ich keinen Zugriff. Nur einen Benutzer.

Wie gehe ich dabei am Besten vor?

1. open-wrt auf dem Repeater flashen 2. repeater/ repeater bridge mode aktivieren 3. Das Skript von JsBergbau installieren?

Gibt es sonst was man dabei beachten sollte?

PS: Super. Im Dezember die Funktion entdeckt jetzt soll sie auch demnächst von der Telekom abgeschaltet werden. Schade! ☹

Hallo mau5tr,

deine Idee mit einem Repeater klingt zunächst logisch, ist bei technisch ausdifferenzierter Betrachtung jedoch eher ungeeignet: theoretisch wäre mit einem Repeater (arbeitet auf OSI Layer 1) tatsächlich eine "Verstärkung" des schwachen Signals möglich, allerdings führt dies zwangsweise zu ungünstigen Umständen bei der im Fall von Wireless Ethernet sowieso bereits bestehenden Kollisionsdomäne (Halbierung der vorhandenen Bruttodatenübertragungsrade aufgrund dauerhaft wiederholter, sprich: doppelter Aussendungen im Zeitschlitzmultiplexverfahren auf derselben Frequenz).

Das wirkt sich besonders negativ auf die Verbindung zum Telekom_FON-Accespoint aus, wenn der Signalpegel (bzw. sagen wir besser: Signalgüte, spricht S/N-Ratio, also "Verständlichkeit" der Signale für den Transceiver deines Wireless-Ethernet-Adapters) schon recht gering ist.

Nicht zu verwechseln sind diese simplen, veralteten und teilweise hersteller-proprietären Layer1-Repeater (z.B. WDS - wireless distribution system) mit aktuellen mesh-Technologien. Letztere greifen aktiv in Aufbau und Organisation der Layer1- und 2-Netzinfrastruktur ein, womit sie das Netz (einschließlich Kollisionsdomänen) selbstständig optimieren (weiterführende Infos: Standards IBBS, IEEE802.s). Allerdings müssen diese Technologien vom jeweiligen Accesspoint bzw. des jeweiligen SSID (service set identifier) unterstützt werden, was bei dem SSID Telekom_FON nicht der Fall ist, selbst wenn das vom selben Gerät unter einer anderen SSID ausgesendete Netz (meistens das private WLAN des jeweiligen Anschlussinhabers) diese Funktionen unterstützt.

Ich würde dir folgendes empfehlen:

- Telekom_FON mit einem WLAN-Adapter "einfangen", der wesentlich leistungfähiger ist als es gängige Adapter in Endgeräten sind ;

- ein Signal, was mit einem Notebook-Adapter gerade oder kaum noch nutzbar ist kann mit leistungsfähiger Hardware einen stabilen Link aufrecht erhalten

→ dazu nutzt du einen WLAN-Router, dessen WLAN-Adapter man mittels spezieller Firmware (z.B. dd-wrt oder openWRT) im sog. "Client-Modus" betreiben kann

→ kompatible Hardwarelisten (ab €20 Neupreis) und jede Menge weitere Dokumentation zum Flashen und Konfigurieren finden sich auf den Web-Portalen der Firmware-Anbieter

→ idealerweise nutzt du ein Modell, das über Antennen mit Richtwirkung verfügt ; dies bewirkt eine Bündelung der Abstrahlleistung in eine bestimmte Richtung beim Senden bzw. das Ausblenden / Abdämpfen von Störsignalen aus anderen Richtungen. Typische Werte für gehäuseinterne Antennen sind z.B. 3 - 8dBi Gewinn bei Öffnungswinkeln zwischen 60-120°. Neben den bereits gegenüber in Endgeräten verbauten, qualitativ höherwertigeren Transceivern führt somit reine, passive Physik bei korrekter Ausrichtung (einfach ausprobieren) zu einer weiteren, erheblichen Verbesserung des Links.

→ du erstellst zwei Netz-Zonen auf deinem WLAN-Router, z.B. LAN = 192.168.1.0/24 (mit DHCP-Server) = kabelgebundener Adapter / RJ48-Buchsen ; WAN = kabelloser Adapter (als DHCP-Client, Verbindung im Client-Mode mit SSID Telekom_FON) ;

→ du schließt deine Endgeräte an die RJ48-Buchsen an, sie erhalten in der Standard-Konfig per DHCP alle erforderlichen IP-Parameter aus dem o.g. LAN

→ die WAN-Schnittstelle erhält von Telekom_FON ebenfalls entsprechende Parameter (172.17.2.0/24).

Durch die letzten Punkte erfolgt neben der Trennung von Kollisionsdomänen (Entlastung Funkkanal Telekom_FON) zusätzlich noch ein Plus an Schutz über eine SPI-NAPT-Firewall ; dein eigenes LAN wird vom offenen, ungeschützten WAN des Telekom_FON abgeschottet. Achtung: die Ethernet-Adapter (z.B. eth0, wlan0) sollten nicht per network bridge verbunden werden, sondern der Datenaustausch zwischen den IP-Netzen 192.168.2.0/24 und 172.17.2.0/24 soll über Source-NAPT-Routing auf Layer 3 erfolgen.

Möchtest du nun auch WLAN-Endgeräte in deinem Netz betreiben so kannst du an einen der RJ48-Ports einen weiteren Accesspoint anschließen, der das IP-Netz 192.168.1.0/24 via Layer2-Bridging per WLAN erreichbar macht (hier ist die Bridge OK, da sie dein bereits abgeschottetes IP-Netz lediglich per mit WPA2 abgesichertem WLAN erweitern soll).

→ Tipp: falls der Router, der sich mit Telekom_FON verbindet, zwei WLAN-Adapter hat (z.B. 2.4GHz und 5GHz) so kannst du einen als Client zur Anbindung an Telekom_FON (siehe oben) und den anderen als Accesspoint für dein eigenes LAN nutzen - in diesem Fall brauchst du dann kein extra Gerät.

Du hast nun ein eigenes (W)LAN mit firewall-geschütztem Uplink zu Telekom_FON und darüber hinaus natürlich - nach erfolgtem Login - Internetzugriff. Der SSID Telekom_FON ersetzt nun aus deiner Sicht sozusagen klassische Netzzugänge wie xDSL über TAL (Doppelader), DOCSIS über BK (Koaxialkabel) etc..

Zu beachten ist, dass es sich nun um ein aus Sicht des Internets mehrfach über S-NAPT-geroutetes Netz handelt, mit dem IP-basierte Verbindungsanfragen aus dem Internet auf dein Heimnetz (z.B. Betreiben eines "own-cloud-Servers" im Heimnetz) nicht möglich sind (du hast keine Möglichkeit, Port-Forwardings im lokalen IP-Netz 172.17.2.0/24 von Telekom_FON bzw. in dessen Backbone-/Transit-Netz 80.157.128.0/22 vorzunehmen). Für 99% der privaten Nutzung des Inter-Networking sollte dies jedoch ausreichen.

Gruß, vmlinuz

Tbtechnik schrieb:

Hallo

Ich habe mal ne Frage habe mir einen tp-link WDR3600 zu gelegt da ich das mit dem openwrt und Auto Login script ideal fand für mein nächstes Projekt nur leider bekomme ich keine Verbindung zu dem Telekom fon Netz siehe Bilder ich hoffe mir kann jemand helfen

Vielen dank schonmal im Voraus

Hallo Tbtecnnik,

die meisten Wireless-Ethernet-Adapter können nur in jeweils einem der beiden Modi "Accesspoint / Infrastruktur" oder "Client" betrieben werden, beides zeitgleich geht nicht.

Für eine Verbindung zum Telekom_FON (Accesspoint / Infastruktur) muss sich der Wireless-Ethernet-Adapter, der sich damit verbinden soll, logischerweise im Client-Mode befinden. Laut deinem Screenshot ist der AP-Modus aktiv (Standard-Einstellung von OpenWRT), somit kann der Client-Modus nicht funktionieren. Deaktivieren diesen und aktiviere anschließend den Client-Modus, dann wird es klappen.

Da du einen zweiten Wireless-Ethernet-Adapter hast, kannst du diesen als AP für dein privates WLAN nutzen (siehe meine vorherigen Posts).

Gruß, vmlinuz

vmlinuz-kernel schrieb:

(...)

Dieser SMS-Versand ist kostenpflichtig (19 9ct), somit muss ausreichend Prepaid-Guthaben vorhanden sein!

(...)

Wie sich das im Detail verhält, hab' ich noch nicht in Erfahrung bringen können.

Zitat Tarifbedingungen, Quelle: Aufdruck Pappumschlag SIM-Karte:

(...) Inkludierte Hotspot-Flat gilt für die Nutzung an innerdeutschen HotSpots der Telekom Deutschland GmbH. Kann der Grundpreis von 9,95€ /4 Wochen zum Abbuchungszeitraum nicht abgebucht werden, gelten die Konditionen des Tarifs nicht mehr. So lange gilt 0,09€/min bzw. 0,09€/SMS in alle Netze. Tägliche Abbuchungsversuche und bei ausreichendem Guthabenstand anteilige Abrechnung für den Zeitraum der verbleibenden 4 Wochen. (...)

Hieraus lässt sich noch nicht genau erkennen, wie es sich mit dem HotSpot-Zugang verhält, also ob dieser nun auch für 9ct/min statt Flatrate abgechnet wird. Klärung verschafft ein Blick in die ausführliche Preisliste, Seite 3, Fußnote 6) :

(...) Weist das Guthabenkonto zum Abrechnungszeitpunkt ein geringeres Guthaben als der Grundpreis auf und kann dieser daher nicht abgebucht werden, ist die Datennutzung im Inland mit der HotSpot Flat nicht möglich.

Quelle:https://www.telekom.de/dlp/agb/pdf/49164.pdf?

Am besten immer dafür sorgen, dass genug Guthaben drauf ist.

Gruß, vmlinuz

Die letzten WLAN-SSIDs "Telekom_FON" in meiner Reichweite sind letztes Wochenende nach und nach verschwunden. Sehr schade, aber natürlich war damit zu rechnen. Hat jemand das Skript an anderen (kommerziellen, größeren) Hotspots der Telekom getestet?