 |
Surfstick Huawei E352s-5von Prof. Jürgen Plate |
|
Surfstick Huawei E352s-5von Prof. Jürgen Plate |
Der Huawei E 352s-5 ist in Deutschland bekannt als "Telekom Web´n´walk Stick Fusion III".
Nach Telekom-Unterlagen funkt der Stick mit HSPA+ und HSPA in UMTS-Netzen auf den Frequenzen 850 MHz, 1700 MHz, 1900 MHz und 2100 MHz. Hier erlaubt er maximal 21,6 Megabit/s beim Herunterladen (Download) und 5,76 Megabit/s beim Senden (Upload). sowie mit EDGE und GPRS auf den GSM-Frequenzen 850 MHz, 900 MHz, 1800 MHz und 1900 MHz. Mit EDGE erreicht er im Down- und Upload bis zu 248 kbit/s, mit GPRS bis zu 86 kbit/s.
Der Stick identifiziert sich einerseits als Speicher und andererseits als Modem (per Software-Konfiguration umschaltbar). Als Speicher versorgt er den Erwerber gleich mit der nötigen Software für Windows, Mac OS und Linux. Der Stick kann zusätzlich mit einer Micro-SD-Karte bis 32 GByte erweitert werden.
Der Stick arbeitet unter den Microsoft-Betriebssystemen Windows 7, Vista und XP, jeweils mit dem aktuellen Update des Servicepacks. Apple-Rechner brauchen als Betriebssystem MAC OS X 10.6.x (Snow Leopard), 10.5.x (Leopard) oder 10.4.9 (Tiger). Unter Linux wird die Kernelversion ab 2.6.18 benötigt.
Als Verbindungsprogramm dient die Telekom-Variante des firmeneigenen Telekom Internet Manager eingesetzt, eine Variante des Huawei Mobile Partner Verbindungsmanagers. Dieser funktioniert nach dem Prinzip Plug & Play - jedoch nicht bei Linux.
Der Stick unterstützt auch den Versand und Empfang von SMS (sofern vertraglich freigegeben). Er hat eine dreifarbige LED-Anzeige, die über den Verbindungsstatus informiert (Blinken = "bereit", Dauerleuchten = "verbunden", die Farbe gibt an, über welchen Dienst die Datenübertragung erfolgt). Leider ist die LED beim schwarzen Surfstick kaum zu erkennen. Ein externer Antennenanschluss (CRC-9-Stecker) bringt mit angeschlossener Antenne einen deutlichen Gewinn an Empfangsqualität.
Wird der Stick von der deutschen Telekom angeliefert, gibt es im Lieferpaket noch ein 17 Zentimeter langes USB-Verlängerungskabel, eine Schnellstart- und eine Bedienungsanleitung.
| Huawei | E352s-5 |
| USB-ID | 12D1:1506 |
| Netze | GSM, UMTS |
| Frequenzen GSM | 850, 900, 1800, 1900 |
| Frequenzen UMTS | 850, 1700, 1900, 2100 |
| Frequenzen LTE | - |
| Datenübertragung via | GPRS, EDGE, HSDPA, HSUPA, HSPA+ |
| Download, Upload | 21,6 Mbit/s, 5,76 Mbit/s |
| mit MicroSD erweiterbar | 32 GB |
| ext. Antennenanschluss | ja |
| Betriebssysteme | Windows: 7, Vista, XP Apple: Mac OS X ab 10.4 Linux ab Kernel 2.6 |
| automatische Installation | Windows/MAC: ja Linux: nein |
| Maße | 68 x 26 x 12,3 mm |
| Besonderheiten | - |
| Handelsname | Telekom web'n'walk Stick Fusion III |
| Gewicht | 30 g |
| EGPRS-Klasse | 12 |
| HSDPA-Kategorie | Kategorie 12 mit 21,6 Mbit/s |
| HSUPA-Kategorie | Kategorie 6 mit 5,76 Mbit/s |
| LTE-Kategorie | - |
| Antennenbuchsen-Typ | CRS5001 |
| Treiber-Download | www.huawei.com |
| Lieferumfang | USB-Verlängerungskabel, Kurzanleitung |
| Chipsatz | Qualcomm MSM7225 |
Für Linuxer ist ein Tar-Ball beigelegt, der möglichst im Heimatverzeichnis von Root entpackt werden sollte (und nicht wie vorgeschlagen auf dem Desktop). Schon daran sieht man, dass seitens Huawei davon ausgegangen wird, dass eine grafische Benutzeroberfläche läuft. Auch das Installscript impliziert eine GUI, ohne sich davon zu überzeugen, ob das vielleicht nicht stimmt.
Geradezu grotesk ist die beiliegende PDF-Anleitung für den Linux-Besitzer. Der Aufruf von install ist gerade noch richtig beschrieben. Man muss hier nämlich den Pfad zu dem gerade frisch entpackten Verzeichnis angeben, denn das Script ist nicht in der Lage, selbst nachzusehen. Auch andere Voraussetzungen werden keinesfalls vorher geprüft, sondern der vielleicht nicht so erfahrene Anwender mit dann auftauchenden Fehlermeldungen alleine gelassen. Ähnlich salopp werden auch ggf. vorhandene Dateien ohne Rückfrage gelöscht.
Aber zurück zur Anleitung: Die folgende Beschreibung für die Einrichtung der Kommunikation mit der Karte zum Aufbau einer PPP-Verbindung führt den Anfänger vollends in die Irre. Sie ist nämlich höchstens für die Einrichtung eines Modems der 80er Jahre des vergangenen Jahrhunderts geeignet. Interessanterweise muss diese Information auch bis zu T-Mobile gedrungen sein. Inzwischen wird Linux auf der Webseite zum Stick nämlich nicht mehr erwähnt.
Der Surfstick benötigt für die Verbindung zum Internet mindestens die Pakete ppp für das Point-to-Point-Protocol und usb-modeswitch, um den Stick in den Modem-Modus umzuschalten. Oft sind diese Tools aer schon per Default installiert. Falls nicht, wird folgendes Kommando eingegeben:
apt-get install usb-modeswitch ppp
Bei der vorgesehenen Anwendung sollte ein kleiner Server zeitlich gesteuert Daten per Funk ins Internet übertragen. Der Server ist etwa so groß wie eine Zigarrenkiste und hat natürlich keine GUI (nicht mal Tastatur oder Monitor). Er steht in den bayerischen Bergen fern jeglicher Zivilisation und wird per Solarpanel mit Strom versorgt. Für diesen Server hat sich folgende Konfiguration als funktionsfähig erwiesen:
Die mitgelieferte Datei mit udev-Regeln hatte einen monströsen Umfang. Sie wurde durch eine in der Zeitschrift c't empfohlene Version ersetzt, die nur wenige Zeilen enthält (für die Darstellung wurden die Zeilen umbrochen):
# This file maintains special treatment for some UMTS-Sticks
# See udev(7) for syntax.
#
# 4G XS Stick TV
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="1c9e", ATTRS{idProduct}=="9a00",
→ RUN+="/sbin/modprobe usbserial vendor=0x1c9e product=0x9a00"
ACTION=="remove", ATTRS{idVendor}=="1c9e", ATTRS{idProduct}=="9a00", RUN+="/sbin/modprobe -r usbserial"
# Huawei E173
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1c0b",
→ RUN+="/usr/sbin/usb_modeswitch -v 12d1 -p 1c0b
→ -M '55534243123456780000000000000011062000000100000000000000000000'"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1c05",
→ RUN+="/sbin/modprobe usbserial vendor=0x12d1 product=0x1c05"
ACTION=="remove", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1c05", RUN+="/sbin/modprobe -r usbserial"
# Huawei E352s-5
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="14fe",
→ RUN+="/usr/sbin/usb_modeswitch -v 12d1 -p 14fe
→ -M '55534243123456780000000000000011062000000100000000000000000000'"
# Huawei E352s-5 und E367
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1506",
→ RUN+="/sbin/modprobe usbserial vendor=0x12d1 product=0x1506"
ACTION=="remove", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1506", RUN+="/sbin/modprobe -r usbserial"
# Huawei E398
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1505",
→ RUN+="usb_modeswitch -v 12d1 -p 1505 -V 12d1 -P 1506
→ -M "'55534243123456780000000000000011062000000100000000000000000000'"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="14c3",
→ RUN+="usb_modeswitch -v 12d1 -p 14c3 -V 12d1 -P 14c
Die Datei wurde als /etc/udev/rules.d/20-Huawei-Datacard.rules gespeichert.
Der Stick identifiziert sich als /dev/ttyUSB_utps_modem, bei manchen Linux-Versionen auch als /dev/ttyUSB0 bzw. /dev/ttyUSBx (x = 1 .. n). Wer Verwirrrungen vermeiden will, kann für den Stick ein Softlink anlegen, z.B. /dev/surfstick.
# This optionfile was generated by pppconfig 2.3.18. # # hide-password noauth novj noccp connect "/usr/sbin/chat -v -f /etc/chatscripts/tmobile" debug /dev/ttyUSB_utps_modem 115200 defaultroute noipdefault usepeerdns
# This chatfile was generated by pppconfig 2.3.18. # Please do not delete any of the comments. Pppconfig needs them. # # ispauth PAP # abortstring ABORT BUSY ABORT 'NO CARRIER' ABORT VOICE ABORT 'NO DIALTONE' ABORT 'NO DIAL TONE' ABORT 'NO ANSWER' ABORT DELAYED # modeminit '' ATZ TIMEOUT 120 'OK' 'AT+CPIN=????' 'OK' 'AT+CGDCONT=1,"IP","internet.t-mobile"' # ispnumber 'OK' 'ATDT*99#' # ispconnect CONNECT \d\cManchmal dauert es etwas, bis der Stick auf die PIN reagiert, weshalb der Timeout auf 120 Sekunden gesetzt wurde.
Das war eigentlich schon alles. Wenn man nun das Kommando pon tmobile eingibt, sollte
die Verbindung zum Internet aufgebaut werden. Die Protokollierung des Verbindungsaufbaus
kann man sich mit dem Kommando plog ansehen, das im Prinzip wie tail funktioniert
und auch dessen Parmeter kennt. Ein typisches Log siht folgendermaßen aus:
Jul 5 16:40:02 zerberus pppd[1209]: pppd 2.4.5 started by root, uid 0
Jul 5 16:40:04 zerberus chat[1212]: abort on (BUSY)
Jul 5 16:40:04 zerberus chat[1212]: abort on (NO CARRIER)
Jul 5 16:40:04 zerberus chat[1212]: abort on (VOICE)
Jul 5 16:40:04 zerberus chat[1212]: abort on (NO DIALTONE)
Jul 5 16:40:04 zerberus chat[1212]: abort on (NO DIAL TONE)
Jul 5 16:40:04 zerberus chat[1212]: abort on (NO ANSWER)
Jul 5 16:40:04 zerberus chat[1212]: abort on (DELAYED)
Jul 5 16:40:04 zerberus chat[1212]: send (ATZ^M)
Jul 5 16:40:04 zerberus chat[1212]: timeout set to 30 seconds
Jul 5 16:40:04 zerberus chat[1212]: expect (OK)
Jul 5 16:40:04 zerberus chat[1212]: ATZ^M^M
Jul 5 16:40:04 zerberus chat[1212]: OK
Jul 5 16:40:04 zerberus chat[1212]: -- got it
Jul 5 16:40:04 zerberus chat[1212]: send (AT+CPIN=1234^M)
Jul 5 16:40:04 zerberus chat[1212]: send (^M)
Jul 5 16:40:04 zerberus chat[1212]: expect (OK)
Jul 5 16:40:05 zerberus chat[1212]: AT+CPIN=1234^M^M^M
Jul 5 16:40:05 zerberus chat[1212]: OK
Jul 5 16:40:05 zerberus chat[1212]: -- got it
Jul 5 16:40:05 zerberus chat[1212]: send (AT+CGDCONT=1,"IP","internet.t-mobile"^M)
Jul 5 16:40:05 zerberus chat[1212]: expect (OK)
Jul 5 16:40:05 zerberus chat[1212]: ^M
Jul 5 16:40:05 zerberus chat[1212]: AT+CGDCONT=1,"IP","internet.t-mobile"^M^M
Jul 5 16:40:05 zerberus chat[1212]: OK
Jul 5 16:40:05 zerberus chat[1212]: -- got it
Jul 5 16:40:05 zerberus chat[1212]: send (ATDT*99#^M)
Jul 5 16:40:05 zerberus chat[1212]: expect (CONNECT)
Jul 5 16:40:05 zerberus chat[1212]: ^M
Jul 5 16:40:06 zerberus chat[1212]: ATDT*99#^M^M
Jul 5 16:40:06 zerberus chat[1212]: CONNECT
Jul 5 16:40:06 zerberus chat[1212]: -- got it
Jul 5 16:40:06 zerberus chat[1212]: send (\d)
Jul 5 16:40:07 zerberus pppd[1209]: Script /usr/sbin/chat -v -f /etc/chatscripts/tmobile finished (pid 1211), status = 0x0
Jul 5 16:40:07 zerberus pppd[1209]: Serial connection established.
Jul 5 16:40:07 zerberus pppd[1209]: using channel 1
Jul 5 16:40:07 zerberus pppd[1209]: Using interface ppp0
Jul 5 16:40:07 zerberus pppd[1209]: Connect: ppp0 <--> /dev/ttyUSB_utps_modem
Jul 5 16:40:08 zerberus pppd[1209]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x797728b> <pcomp> <accomp>]
Jul 5 16:40:08 zerberus pppd[1209]: rcvd [LCP ConfReq id=0x1 <accomp> <pcomp> <asyncmap 0x0> <mru 1500> <magic 0x543> <auth chap MD5>]
Jul 5 16:40:08 zerberus pppd[1209]: sent [LCP ConfNak id=0x1 <auth pap>]
Jul 5 16:40:08 zerberus pppd[1209]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x797728b> <pcomp> <accomp>]
Jul 5 16:40:08 zerberus pppd[1209]: rcvd [LCP ConfReq id=0x2 <accomp> <pcomp> <asyncmap 0x0> <mru 1500> <magic 0x543> <auth pap>]
Jul 5 16:40:08 zerberus pppd[1209]: sent [LCP ConfAck id=0x2 <accomp> <pcomp> <asyncmap 0x0> <mru 1500> <magic 0x543> <auth pap>]
Jul 5 16:40:08 zerberus pppd[1209]: sent [LCP EchoReq id=0x0 magic=0x797728b]
Jul 5 16:40:08 zerberus pppd[1209]: sent [PAP AuthReq id=0x1 user="zerberus" password=<hidden>]
Jul 5 16:40:08 zerberus pppd[1209]: rcvd [LCP EchoRep id=0x0 magic=0x543]
Jul 5 16:40:08 zerberus pppd[1209]: rcvd [PAP AuthAck id=0x1 "Greetings!!"]
Jul 5 16:40:08 zerberus pppd[1209]: Remote message: Greetings!!
Jul 5 16:40:08 zerberus pppd[1209]: PAP authentication succeeded
Jul 5 16:40:08 zerberus pppd[1209]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Jul 5 16:40:08 zerberus pppd[1209]: rcvd [IPCP ConfReq id=0x1]
Jul 5 16:40:08 zerberus pppd[1209]: sent [IPCP ConfNak id=0x1 <addr 0.0.0.0>]
Jul 5 16:40:08 zerberus pppd[1209]: rcvd [IPCP ConfNak id=0x1 <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Jul 5 16:40:08 zerberus pppd[1209]: sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Jul 5 16:40:08 zerberus pppd[1209]: rcvd [IPCP ConfReq id=0x2]
Jul 5 16:40:08 zerberus pppd[1209]: sent [IPCP ConfAck id=0x2]
Jul 5 16:40:09 zerberus pppd[1209]: rcvd [IPCP ConfNak id=0x2 <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Jul 5 16:40:09 zerberus pppd[1209]: sent [IPCP ConfReq id=0x3 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Jul 5 16:40:10 zerberus pppd[1209]: rcvd [IPCP ConfNak id=0x3 <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Jul 5 16:40:10 zerberus pppd[1209]: sent [IPCP ConfReq id=0x4 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Jul 5 16:40:10 zerberus pppd[1209]: rcvd [IPCP ConfNak id=0x4 <addr 10.174.130.115> <ms-dns1 10.74.210.210> <ms-dns2 10.74.210.211>]
Jul 5 16:40:10 zerberus pppd[1209]: sent [IPCP ConfReq id=0x5 <addr 10.174.130.115> <ms-dns1 10.74.210.210> <ms-dns2 10.74.210.211>]
Jul 5 16:40:10 zerberus pppd[1209]: rcvd [IPCP ConfAck id=0x5 <addr 10.174.130.115> <ms-dns1 10.74.210.210> <ms-dns2 10.74.210.211>]
Jul 5 16:40:10 zerberus pppd[1209]: Could not determine remote IP address: defaulting to 10.64.64.64
Jul 5 16:40:10 zerberus pppd[1209]: Cannot determine ethernet address for proxy ARP
Jul 5 16:40:10 zerberus pppd[1209]: local IP address 10.174.130.115
Jul 5 16:40:10 zerberus pppd[1209]: remote IP address 10.64.64.64
Jul 5 16:40:10 zerberus pppd[1209]: primary DNS address 10.74.210.210
Jul 5 16:40:10 zerberus pppd[1209]: secondary DNS address 10.74.210.211
Jul 5 16:40:10 zerberus pppd[1209]: Script /etc/ppp/ip-up started (pid 1260)
Jul 5 16:40:11 zerberus pppd[1209]: Script /etc/ppp/ip-up finished (pid 1260), status = 0x0
Danach kann man mittels ifconfig sehen, dass nun auch ein Netzwerkinterface namens "ppp0" existiert. Auch die Nameserver von T-Mobile sind eingetragen. Beim Arbeiten mit der Internetverbindung fällt nur auf, dass alles etwas langsamer und zäher verläuft - je nach Netzgüte. Übrigens verbinden sich alle Surfsticks immer mit der Remote-Adresse 10.64.64.64. Die lokale IP-Adresse ist sehr zufällig, mal sind es 10.x.y.z-Adressen, mal andere IP-Adressen.
Des weiteren ist mir aufgefallen, dass nach einem Beenden der Kommunikation der Stick in einen "seltsamen" Zustand verbleibt: die LED blinkt blau und ein neuerlicher Verbindungsaufbau war nicht möglich, bzw. erst nach Abziehen und Wiederanstecken des Stiftes. Das lag an der Zeile
'OK' 'AT+CPIN=????'im Chat-Script. Die PIN darf nur einmal gesetzt werden, beim zweiten Mal gibt es einen Fehler. Man kann das Problem beheben, indem nach dem Senden der PIN im Chat-Script auf den Fehler entsprechrend reagiert wird. Im einfachten Fall mancht man nach dem Setzen der PIN noch eine Statusabfrage, die auf jeden Fall ein "OK" liefert.
Aus diesem Grund wird der Stick per Startscript /etc/init.d/StartPPP beim Booten des Systems automatisch hochgefahren. Da manchmal das Script schon gestartet wird, obwohl die USB-Treiber für den Stick noch nicht aktiviert sind, wartet das Script, bis das entsprechende Device im Verzeichnis auftaucht. Mit dieser Massnahme fährt das System stabil hoch.
#! /bin/sh
### BEGIN INIT INFO
# Provides: skeleton
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Example initscript
# Description: This file should be used to construct scripts to be
# placed in /etc/init.d.
### END INIT INFO
# Do NOT "set -e"
# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="PPP und Reverse SSH-Tunnel starten/stoppen"
NAME=StartPPP
DAEMON=/root/bin/$NAME
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0
# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh
# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions
#
# Function that starts the daemon/service
#
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
#
# PPP-Verbindung ueber Surfstick aufbauen
# warten, bis Stick eingehaengt ist - aber nicht ewig
sleep 30
CNT=100
until [ -c /dev/ttyUSB_utps_modem -o "$CNT" -eq 0 ]
do
CNT=`expr $CNT - 1`
/bin/sleep 2
done
# testen, ob Verbindung schon besteht
/sbin/ifconfig | /bin/grep -q "ppp0" && return 1
# Verbindungsaufbau starten
/usr/bin/pon tmobile
# warten, bis Verbindung steht
# Ende nach CNT*2 Sekunden oder wenn PPP-Verbindung steht
CNT=100
while [ "$CNT" -gt 0 ]
do
CNT=`expr $CNT - 1`
/bin/sleep 2
/sbin/ifconfig | /bin/grep -q "ppp0" && CNT=0
done
# Erfolg?
/sbin/ifconfig | /bin/grep -q "ppp0" || return 2
echo "Hochgefahren: $(date)" >> /root/bin/stick.log
return 0
}
#
# Function that stops the daemon/service
#
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
#
# PPP-Verbindung ueber Surfstick schliessen
if /sbin/ifconfig | /bin/grep -q "ppp0"
then
/usr/bin/poff tmobile
RETVAL="$?"
test "$RETVAL" -gt 0 && return 2
return 0
else
return 1
fi
}
case "$1" in
start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
do_start
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
do_stop
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
status)
/sbin/ifconfig
exit 0
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|status}" >&2
exit 3
;;
esac
Bei den aktuellen Linux_Versionen, unter anderem beim Raspbian-System für das Raspberry-Pi-Board wird vieles einfacher. Deshalb ist die oben gezeigt Methode aber nicht unbedingt schlecht - mit ihr kann man so ziemlich alles anstellen. Das Leben mit dem Stick wird aber durch das Tool wvdial erleichert. Es nimmt und die die diversen Konfigurationen oben ab und benötigt nur eine einzige Konfigurationsdatei. Neben den oben erwähnten Paketen usb-modeswitch und ppp brauchen wir noch wvdial:
apt-get install wvdial
Für die udev-Regeln gibt es nun ein anderes Verfahren: Statt alles in eine unübersichtlich große Datei zu packen, werden die Regeln für das Programm usb-modeswitch getrennt abgelegt und die udev-Regel besteht nur noch aus einer Zeile. Bei neueren Versionen von Debian/Raspbian sind dieser und andere Surfsticks bereits im System verzeichnet. Man kann dann die Schritte 1. und 2. überspringen.
Um die Parameter-Datei anzulegen, wird im Verzeichnis /etc/usb_modeswitch.d die Datei "Huawei" mit folgendem Inhalt erzeugt. Zum Eingeben der Daten und Abspeichern der Datei verwenden Sie einfach Ihren Lieblings-Editor, z. B. vi oder nano:
# Huawei E352s-5 DefaultVendor="0x12d1" DefaultProduct="0x14fe" TargetVendor= "0x12d1" TargetProductList="0002" MessageContent="55534243123456780000000000000011062000000100000000000000000000"
In der Datei /etc/usb_modeswitch.conf werden die Einträge folgendermaßen angepasst:
DisableSwitching=0 EnableLogging=1 SetStorageDelay=5"EnableLogging=1" sollte nur für die Dauer des Testens gesetzt sein. Danach unbedingt wieder "EnableLogging=0" setzen, um die SD-Karte zu schonen!
Damit das Umschalten automatisch nach dem Booten funktioniert, wird die Datei "40-usb_modeswitch.rules" im Verzeichnis /lib/udev/rules.d/ mit dem Editor bearbeitet. Dazu eine eventuell vorhandene Zeile mit Vendor-Id 0x12d1 und Product-Id 0x14fe auskommentieren und die unten aufgeführte neue Zeile hinzufügen. Aus Gründen der Formatierung wurde unten die Zeile in zwei Ausgabezeilen aufgeteilt (die Trennstelle ist durch das Zeichen ↵ am Zeilenende markiert). Bei der Eingabe muss das aber als eine einzige Zeile eingegeben werden.
# Generic entry for all Huawei devices
ATTRS{idVendor}=="12d1", ATTR{bInterfaceNumber}=="00", ↵
ATTR{bInterfaceClass}=="08", RUN+="usb_modeswitch '%b/%k'"
Wie gesagt, bei den aktuellen Versionen von Linux ist das alles schon vorhanden und
Sie müssen nichts weiter tun.
Kontrollieren kann man alles, indem man das Kommando dmesg | less aufruft.
Dort findet man nach dem Einstecken des Surfsticks eine lange Reihe von Meldungen:
[ 260.289374] usb 1-1.4: new high-speed USB device number 4 using dwc_otg
[ 260.626807] usb 1-1.4: New USB device found, idVendor=12d1, idProduct=14fe
[ 260.626830] usb 1-1.4: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[ 260.626843] usb 1-1.4: Product: HUAWEI Mobile
[ 260.626855] usb 1-1.4: Manufacturer: HUAWEI
[ 260.629147] usb-storage 1-1.4:1.0: USB Mass Storage device detected
[ 260.633309] scsi host0: usb-storage 1-1.4:1.0
[ 260.634133] usb-storage 1-1.4:1.1: USB Mass Storage device detected
[ 260.634381] scsi host1: usb-storage 1-1.4:1.1
[ 261.334929] usb 1-1.4: USB disconnect, device number 4
[ 268.999370] usb 1-1.4: new high-speed USB device number 5 using dwc_otg
[ 269.263553] usb 1-1.4: New USB device found, idVendor=12d1, idProduct=1506
[ 269.263563] usb 1-1.4: New USB device strings: Mfr=3, Product=2, SerialNumber=0
[ 269.263570] usb 1-1.4: Product: HUAWEI Mobile
[ 269.263576] usb 1-1.4: Manufacturer: HUAWEI
[ 269.266200] usb-storage 1-1.4:1.4: USB Mass Storage device detected
[ 269.266689] scsi host2: usb-storage 1-1.4:1.4
[ 269.267083] usb-storage 1-1.4:1.5: USB Mass Storage device detected
[ 269.267328] scsi host3: usb-storage 1-1.4:1.5
[ 269.296843] usbcore: registered new interface driver cdc_ncm
[ 269.300810] usbcore: registered new interface driver usbserial
[ 269.300860] usbcore: registered new interface driver usbserial_generic
[ 269.300903] usbserial: USB Serial support registered for generic
[ 269.301384] usbcore: registered new interface driver cdc_wdm
[ 269.312945] usbcore: registered new interface driver option
[ 269.313017] usbserial: USB Serial support registered for GSM modem (1-port)
[ 269.471183] huawei_cdc_ncm 1-1.4:1.1: MAC-Address: 58:2c:80:13:92:63
[ 269.471196] huawei_cdc_ncm 1-1.4:1.1: setting rx_max = 16384
[ 269.471409] huawei_cdc_ncm 1-1.4:1.1: setting tx_max = 16384
[ 269.471678] huawei_cdc_ncm 1-1.4:1.1: cdc-wdm0: USB WDM device
[ 269.472337] huawei_cdc_ncm 1-1.4:1.1 wwan0: register 'huawei_cdc_ncm' at ↵
usb-3f980000.usb-1.4, Huawei CDC NCM device, 58:2c:80:13:92:63
[ 269.472445] usbcore: registered new interface driver huawei_cdc_ncm
[ 269.472448] option 1-1.4:1.0: GSM modem (1-port) converter detected
[ 269.472639] usb 1-1.4: GSM modem (1-port) converter now attached to ttyUSB0
[ 269.472765] option 1-1.4:1.2: GSM modem (1-port) converter detected
[ 269.474192] usb 1-1.4: GSM modem (1-port) converter now attached to ttyUSB1
[ 269.474304] option 1-1.4:1.3: GSM modem (1-port) converter detected
[ 269.474493] usb 1-1.4: GSM modem (1-port) converter now attached to ttyUSB2
[ 274.270645] scsi 3:0:0:0: Direct-Access HUAWEI SD Storage 2.31 PQ: 0 ANSI: 2
[ 274.271635] scsi 2:0:0:0: CD-ROM HUAWEI Mass Storage 2.31 PQ: 0 ANSI: 2
[ 274.273976] sd 3:0:0:0: [sda] Attached SCSI removable disk
[ 274.293410] sd 3:0:0:0: Attached scsi generic sg0 type 0
[ 274.293623] scsi 2:0:0:0: Attached scsi generic sg1 type 5
[ 274.297196] sr 2:0:0:0: [sr0] scsi-1 drive
[ 274.297220] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 274.298220] sr 2:0:0:0: Attached scsi CD-ROM sr0
Nun folgt die Erstkonfiguration von wvdial. Das Programm wvdial (ausgesprochen 'weave-dial') ist ein Dienstprogramm, das bei der Herstellung von Modem-basierten Verbindungen zum Internet hilft und das in vielen Linux-Distributionen verfügbar ist. wvdial ist ein Einwahlprogramm für eine Verbindung über das Point-to-Point-Protokoll. Es wählt sich über den Surfstick beim Provider ein und startet den Dienst pppd, um eine Verbindung zum Internet herzustellt. Er erspart uns also das Erstellen des Chatscripts und den Aufruf von pon und poff. Die erste Basiskonfiguration von wvdial wird mit dem folgenden Kommando durchgeführt:
wvdialconfDer Output sollte den Huawei-Stick als /dev/ttyUSBx erkennnen.
Nun wird die Datei /etc/wvdial.conf erstellt. Die Datei verwendet statt der realen Schnittstellenbezeichnung ein Symlink namens "/dev/surfstick" auf die eigentliche Schnittstelle. So muss man die Datei nicht jedesmal anpassen, wenn sich die Nummer der Schnittstelle ändert, sondern es genügt, das Symlink zu ändern. Für die Datei /etc/wvdial.conf ist ein entsprechendes Device-Symlink beispielsweise mit dem Kommando
ln -s /dev/ttyUSB0 /dev/surfstickeinzutragen. Im Script weiter unten wird das Device des Surfsticks automatisch ermittelt und das Symlink erzeugt. Man kann dies mit den folgenden Kommandos auch in anderen Scripten erledigen:
MODEM=$(dmesg | grep ttyUSB | grep 'GSM modem' | head -1 | sed -e 's/.* //') if echo "$MODEM" | grep -q ttyUSB ; then test -L /dev/surfstick && rm /dev/surfstick ln -s /dev/$MODEM /dev/surfstick fiDie Datei /etc/wvdial.conf hat folgenden Inhalt (Provider der SIM-Karte ist T-Mobile, es wird keine PIN verwendet, beim Script surfstick unten kann dann beim Aufruf von wvdial "t-online" als Parameter angegeben werden. Grundsätzlich lassen sich verschiedene Provider über unterschiedliche Dialer-Einträge in der Datei verankern:
[Dialer Defaults] Init1 = ATZ Modem Type = Analog Modem Baud = 9600 New PPPD = yes Modem = /dev/surfstick ISDN = 0 [Dialer t-mobile] Auto DNS = on Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 Init3 = AT+CGDCONT=1,"IP","internet.t-mobile","0.0.0.0" Stupid Mode = on Auto Reconnect = on Idle Seconds = 0 Phone = *99# Modem = /dev/surfstick Username = t-mobile Password = t-mobile Baud = 9600Bei anderen Surfstick-Modellen muss unter Umständen die Befehlsfolge bei "Init2" angepasst werden. So benötigen manche Stick zusätzlich den Befehl "+FCLASS=0".
Jetzt ist es fast geschafft. Für das Point-to-Point-Protokoll ist noch die Netzwerk-Konfiguration zu ergänzen. Dazu öffen Sie mit einen Editor die Datei /etc/network/interfaces und erweitern sie um die Konfiguration für PPP. Dazu tragen Sie die drei Zeilen ab "auto ppp0" ein - falls Sie das nicht schon bei der Basiskonfiguration gemacht haben. Die Default-Route ist automatisch ppp0:
# interfaces(5) file used by ifup(8) and ifdown(8) # Please note that this file is written to be used with dhcpcd # For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf' # Include files from /etc/network/interfaces.d: source-directory /etc/network/interfaces.d auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp auto ppp0 iface ppp0 inet wvdial #auto wlan0 #allow-hotplug wlan0 #iface wlan0 inet dhcp #wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf #iface default inet dhcp
Nun kann die Einwahl mit folgendem Befehl getestet werden, sofern der Symlink surfstick eingerichtet ist:
wvdial t-mobileDer Output sieht dann etwa so aus:
wvdial t-mobile --> WvDial: Internet dialer version 1.61 --> Initializing modem. --> Sending: ATZ ATZ OK --> Sending: ATH0 Q0 V1 E1 S0=0 &C1 &D2 ATH0 Q0 V1 E1 S0=0 &C1 &D2 OK --> Sending: AT+CGDCONT=1,"IP","internet.t-mobile","0.0.0.0" AT+CGDCONT=1,"IP","internet.t-mobile","0.0.0.0" OK --> Modem initialized. --> Sending: ATDT*99# --> Waiting for carrier. ATDT*99# CONNECT --> Carrier detected. Starting PPP immediately. --> Starting pppd at Mon Dec 25 11:11:57 2017 --> Pid of pppd: 1839 --> Using interface ppp0 --> pppd: ... --> pppd: ... --> pppd: ... --> pppd: ... --> pppd: ... --> pppd: ... --> local IP address 10.199.143.58 --> pppd: ... --> remote IP address 10.64.64.64 --> pppd: ... --> primary DNS address 10.74.210.210 --> pppd: ... --> secondary DNS address 10.74.210.211 --> pppd: ...Sobald wir den Prozess abbrechen, wird auch die Verbindung wieder beendet. wvdial muss also im Hintergrund laufen. Da bei Raspbian und anderen Linuxen der ntpd per Default läuft, stellt sich die interne Uhr, sobald die Verbindung zum Internet hergestellt ist.
Da der Raspberry Pi ohne grafische Oberfläche und ohne Monitor nebst Tastatur/Maus läuft, oder man die Internetverbindung immer per Script startet, wird der Modemmanger nicht gebraucht und er funkt eventuell sogar dazwischen. Deshalb das folgende Kommando ausführen:
systemctl disable ModemManager.serviceMit dem Kommando systemctl enable ModemManager.service könnte er später wieder eingeschaltet werden, sofern sich dies für andere Anwendungen als notwendig erweisen sollte.
Soll der Surfstick durch eine PIP gesichert werden, gibt es das oben schon erwähnte Problem. Beim ersten Aufruf akzeptiert der Surfstick die PIN. Wenn man aber dann die Verbindung beendet und wieder aufbaut, darf die PIN nicht nochmals gesendet werden. Da die PIN ja schon akzeptiert ist, würde der Surfstick den weiteren Versuch der PIN-Eingabe als Fehler melden und der Verbindungsaufbau bricht ab. Deshalb muss die PIN-Eingabe beim Booten des RasPi erfolgen, aber nicht beim Aktivieren des Surfsticks. Dazu wird zuerst die Datei /etc/wvdial.conf um einen neuen "Dialer"-Eintrag ergänzt, wobei statt "xxxx" die PIN eingesetzt wird:
[Dialer PIN] Init3 = AT+CPIN=xxxx Username = nix Password = nixDann wird nach dem Einstecken des Surfsticks oder auch beim Booten einmalig das Kommando wvdial pin aufgerufen. Die Ausgabe sihet dann etwas so aus:
--> WvDial: Internet dialer version 1.61 --> Initializing modem. --> Sending: ATZ ATZ OK --> Sending: ATH0 Q0 V1 E1 S0=0 &C1 &D2 ATH0 Q0 V1 E1 S0=0 &C1 &D2 OK --> Sending: AT+CPIN=9244 AT+CPIN=9244 OK --> Modem initialized. --> Configuration does not specify a valid phone number.Die Fehlermeldungen "Configuration does not specify a valid phone number" darf man getrost ignorieren. Die rührt daher, dass eben eine Telefonnummer beim Dialer-Eintrag "PIN" nicht angegeben (und auch nicht nötig) ist.
Mit den oben aufgeführten Schritten ist der Surfstick fertig eingerichtet. Um die Verbindung ins Internet bequem starten und stoppen zu können, richtet man sich am besten ein Shellscript ein. Im Prinzip leistet das Kommando wvdial schon das Gewünschte. Das folgende Script erledigt beim Start der Verbindung zusätzlich noch einige weitere Tätigkeiten:
Das Script surfstick wird entweder mit dem Parameter "start" für den Aufbau der Verbindung oder mit dem Parameter "stop" für das Beenden der Verbindung aufgerufen. Als Sonderaufruf dient der Parameter "pin" zum Freischalten des Sticks mit seiner PIN. Beispielsweise zum Starten:
sudo ./surfstick startIn dem Script wird zuerst geprüft, welches Device /dev/ttyUSBxxx vom Surfstick belegt ist. Entsprechend wird dann die passende Schnittstelle als Symlink auf /dev/surfstick erzeugt. Auch werden beim Start-Aufruf noch laufende wvdial-Prozesse vorher gelöscht. Prinzipiell könnte es auch als Startscript beim Hochfahren des Systems eingesetzt werden, was aber bedeuten würde, dass der Raspberry Pi ständig online ist. Bei den kurzen, sporadischen Datenübertragungen erscheint es aber sinvoller, die Internet-Verbindung nur bei Bedarf aufzubauen:
#!/bin/bash # Internetverbindung etablieren mit MediaTek-Surfstick (eplus) # Wird beim Booten in /etc/rc.local aufgerufen. # Aufruf manuell: sudo /home/pi/bin/surfstick # User-ID und Parameter checken if [ "$LOGNAME" != "root" ] ; then echo "$0: You must be root to do it" exit 1 fi # Kommandozeilenparameter da? if [ $# -ne 1 ] ; then echo "Usage: $0 <start|stop|pin>" exit 1 fi # auf korrekten Parameter checken if [ "$1" != "start" -a "$1" != "stop" -a "$1" != "pin" ] ; then echo "$0: Parameter must be 'start', 'stop' or 'pin'" exit 1 fi # ---------- Verbindung abbauen ---------- if [ "$1" = "stop" ] ; then killall -q -s TERM wvdial killall -q -s TERM pppd echo "Internetverbindung beendet" exit 0 fi # ---------- Verbindung aufbauen ---------- # Adresse der USB-Schnittstellen festlegen MODEM=$(dmesg | grep ttyUSB | grep 'GSM modem' | head -1 | sed -e 's/.* //') if echo "$MODEM" | grep -q ttyUSB ; then test -L /dev/surfstick && rm /dev/surfstick ln -s /dev/$MODEM /dev/surfstick else echo "Surfstick nicht angeschlossen" exit 1 fi # Wenn "pin" gefordert ist, PIN setzen if [ "$1" = "pin" ] ; then wvdial PIN exit 0 fi # eventuell noch laufenden wvdial beenden sudo killall wvdial # Internet-Einwahl wvdial t-mobile & if [ $? -eq 0 ]; then echo "Internetverbindung aufgebaut" sleep 5 exit 0 else echo "Internetverbindung fehlgeschlagen" exit 1 fi
Einen SSH-Reverestunnel benötigt man z. B. wenn man auf einen Rechner zugreifen will, der hinter einem Firewallsystem steht und zwar sebst ins Internet kommt, jedoch eine sogenannte private IP-Adresse besitzt. Da man den Rechner von ausserhalb nicht erreichen kann, muss dieser von innen einen SSH-Tunnel durch die Firewall zu einem externen Rechner aufbauen. Bis dahin wäre das ein "normaler" SSH-Tunnel. Dieser wird aber so eingerichtet, dass er auch Verbindungen von externen Rechner nach innen zuläßt.
Dazu muss der folgende Befehl am internen Rechner ausgeführt werden:
/usr/bin/ssh -N -f -R 2222:localhost:22 user@externer.rechner2222 ist der Port über den die Verbindung vom externen Rechner aus geöffnet werden muss, 22 ist der Port, der dann vom internen System verwendet wird (in diesem Fall SSH). Nachdem der Tunnel steht, kann man sich vom externen System aus mit dem Befehl ssh localhost -p 2222 zum internen Rechner verbinden. Zu bedenken ist, dass man quasi ein Loch in die Firmenfirewall bohrt. In unserm Fall bietet der Reversetunnel die Möglichkeit, sich per SSH auf dem System einzuloggen, das über den Surfstick am Internet hängt, obwohl es eine private Adresse besitzt. Solange der Tunnel steht, ist das System natürlich auch angreifbar.
Insofern ist es günstig, durch crontab gesteuert den Tunnel nur für eine bestimmte Zeit aufzumachen. In dieser Zeit kann dann das Surfsticksystem aus der Ferne administriert werden. In diesem Fall muss der Login automatisiert werden, denn sonst hinge der cron-Job mit einer Passwortabfrage. Deshalb erfolgt der Login des internen Systems auf dem externen Rechner per ssh-key und Zertifikat. Wie man das einrichtet, steht im folgenden Abschnitt.
Für den Auf- und Abbau des Tunnels dienen die beiden folgenden kurzen Shellscripts, zuerst das Script für den Aufbau des Tunnels:
#!/bin/sh
# Baut einen reverse-SSH-Tunnel zu Netzmafia auf
# Mit 'ssh user@localhost -p 2222' kann man sich
# auf dem Rechner einloggen
#
PIDFILE=/var/run/sshtunnel.pid # Datei mit der Prozessnumme des ssh-Tunnels
# Prozess-Id ermitteln
PID=`/bin/ps ax | /bin/grep "22 zerberus" | /bin/grep -v "grep" | awk '{ print $1; }'`
if [ "$PID" != "" ]
then
/bin/kill -HUP $PID # ggf. alten ssh-Tunnel schliessen
/bin/rm -f $PIDFILE
fi
# Tunnel starten (im Hintergrund)
/usr/bin/ssh -N -f -R 2222:localhost:22 zerberus@www.netzmafia.de &
RETVAL="$?"
test "$RETVAL" -gt 0 && exit 2 # Tunnelaufbau ging schief
# Prozess-Id ermitteln und speichern
PID=`/bin/ps ax | /bin/grep "22 zerberus" | /bin/grep -v "grep" | awk '{ print $1; }'`
echo $PID > $PIDFILE
exit 0
Das Script zum Abbau des Tunnels verwendet die gespeicherte Prozessnummer:
#!/bin/sh # Schliesst einen Reverse-SSH-Tunnel zu Netzmafia # PIDFILE="/var/run/sshtunnel.pid" # PID-File ssh-Tunnel # Wenn die Datei existiert, laeuft vermutlich ein Tunnel if [ -f $PIDFILE ] then # Prozess beenden /bin/kill -s 1 `cat $PIDFILE` RETVAL="$?" # im Fehlerfall nochmal brutal versuchen test "$RETVAL" -gt 0 && kill -s 9 `cat $PIDFILE` # delete pidfile /bin/rm -f $PIDFILE fi exit 0
Dafür muss auf dem internen Rechner ein Zertifikat erstellt und auf den externen Computer übertragen werden, was mit Hilfe der beiden Kommandos ssh-keygen und ssh-copy-id erledigt werden kann. Zuerst wird ein Schlüssel-Paar (Public- und Private-Key) erstellt und dann der öffentliche Schüssel zum Webserver übertragen.
Der Private-Key ist dann dem normalen Passwort gleichgestellt. Im Gegensatz zum Passwort existiert er aber als Datei, die vor fremdem Zugriff zu schützen ist. Deswegen besteht die Möglichkeit, den Private Key mit einer Passphrase zu schützen. Die Passphrase muss in unserem Fall leer bleiben, da sonst bei Verbindungsaufnahme diese Passphrase abgefragt würde und so kein automatischer Dateitransfer möglich wäre.
Das folgende Shellscript erzeugt die Schlüssel und übertägt sie dann (den Account "user@www.netzmafia.de" gibt es natürlich nicht, er dient nur als Beispiel):
#!/bin/bash # Generiert Public/Private-Keys und kopiert sie zur Netzmafia # damit ein Login bzw. Aufbau eines SSH-Tunnels dorthin ohne # Passwort-Eingabe moeglich ist # # zuerst werden die Keys generiert ssh-keygen -t rsa ssh-keygen -t dsa # nun befinden sich im Verzeichnis ~/.ssh vier Dateien: # id_rsa id_dsa id_rsa.pub id_dsa.pub # # nun werden die public kesy zur Netzmafia kopiert und dort # an die Datei ~/.ssh/authorized_keys angehaengt ssh-copy-id -i ~/.ssh/id_rsa.pub user@www.netzmafia.de ssh-copy-id -i ~/.ssh/id_dsa.pub user@www.netzmafia.de # ab jetzt kann sich der User vom internen System als # "user@www.netzmafia.de" ohne Passworteingabe auf # Netzmafia einloggen