Bei meinem Huawei ME906s unter Linux (getestet mit Debian Sid, Debian Experimental, Fedora 24 und Ubuntu 16.04, aber das Ergebnis ist dasselbe unter Windows 10), bekomme ich entweder eine ERRORoder NO CARRIERmehrere Meldungen (abhängig vom verwendeten Gerät). Im Gegensatz zu dieser Frage ist das Verhalten konsistent und tritt auch auf, wenn ich wvdial lange nach dem Start ausgeführt habe. Ich habe die SIM-PIN entfernt und festgestellt, dass das Mobilfunknetz mit einem Android-Smartphone funktioniert.
Mit Linux 4.7.0-rc4 sehe ich 5 Geräte, die ich der Karte zuordnen kann:
/dev/ttyUSB0 - Spricht AT, Ausgabe unten
/dev/ttyUSB1 - Keine Ausgabe (für GPS?)
/dev/ttyUSB2 - Spricht AT, antwortet jedoch auf FEHLER anstelle von NO CARRIER zum Wählen
/dev/ttyUSB3 - Gleiches Verhalten wie / dev / ttyUSB0
--> WvDial: Internet dialer version 1.61 --> Initializing modem. --> Sending: ATZ ATZ OK --> Sending: AT+CFUN=1 AT+CFUN=1 OK --> Sending: ATQ0 V1 E1 S0=0 ATQ0 V1 E1 S0=0 OK --> Sending: AT+CGDCONT=1,"IP","internet.t-mobile" AT+CGDCONT=1,"IP","internet.t-mobile" OK --> Sending: ATI ATI Manufacturer: Huawei Technologies Co., Ltd. Model: ME906s-158 Revision: 11.617.00.00.00 IMEI: 8<snip by @phihag>0 +GCAP: +CGSM,+DS,+ES OK --> Sending: AT+CPIN? AT+CPIN? +CPIN: READY OK --> Sending: AT+CFUN? AT+CFUN? +CFUN: 1 OK --> Sending: AT+CSQ AT+CSQ +CSQ: 99,99 OK --> Sending: AT+CREG? AT+CREG? +CREG: 0,2 OK --> Modem initialized. --> Sending: ATD*99# --> Waiting for carrier. ATD*99# NO CARRIER --> No Carrier! Trying again.
Die letzten 5 Zeilen werden dann 10-mal wiederholt.
Andere Tools wie sakis3g und ModemManager / NetworkManager hängen auch beim Verbindungsaufbau.
Ich sehe auch eine Netzwerkverbindung, die mit dem Modem verbunden ist, die aber auch nicht erreichbar ist:
$ ip link ... 6: enp0s20f0u5c2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000 link/ether 02:1e:10:1f:00:00 brd ff:ff:ff:ff:ff:ff
Ich glaube rfkillnicht aktiv zu sein:
$ rfkill list 0: tpacpi_bluetooth_sw: Bluetooth Soft blocked: no Hard blocked: no 1: tpacpi_wwan_sw: Wireless WAN Soft blocked: no Hard blocked: no 3: phy0: Wireless LAN Soft blocked: no Hard blocked: no 10: hci0: Bluetooth Soft blocked: no Hard blocked: no
(im Gespräch mit /dev/ttyUSB0)
AT^RFSWITCH? ^RFSWITCH: 1,1 OK
Wie vorgeschlagen, versuchte ich es AT^NDISDUPstattdessen mit (ohne Erfolg) (obwohl ATZich auf der nächsten Zeile zusätzliche Zeilen sehe):
$ minicom -D /dev/ttyUSB0 ATZ OK ^PDPSTATUS: 2 ^NDISSTAT: 0,0,,"IPV4" AT^NDISDUP=1,1,"internet.t-mobile" OK AT^DHCP? ERROR
ip linkZeigt jedoch immer noch NO-CARRIER und auch dhclient -v enp0s20f0u5c2mal aus. Mit ethtoolsehe ich:
$ ethtool -i enp0s20f0u5c2 driver: cdc_ether version: 22-Aug-2005 firmware-version: CDC Ethernet Device expansion-rom-version: bus-info: usb-0000:00:14.0-5 supports-statistics: no supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no
dmesg sieht gut aus für mich:
[ 11.674523] cdc_ether 1-5:2.0 usb0: register 'cdc_ether' at usb-0000:00:14.0-5, CDC Ethernet Device, 02:1e:10:1f:00:00 [ 11.674630] usbcore: registered new interface driver cdc_ether [ 11.675451] option 1-5:2.2: GSM modem (1-port) converter detected [ 11.675746] usb 1-5: GSM modem (1-port) converter now attached to ttyUSB0 [ 11.675767] option 1-5:2.3: GSM modem (1-port) converter detected [ 11.676499] usb 1-5: GSM modem (1-port) converter now attached to ttyUSB1 [ 11.676528] option 1-5:2.4: GSM modem (1-port) converter detected [ 11.676569] usb 1-5: GSM modem (1-port) converter now attached to ttyUSB2 [ 11.676586] option 1-5:2.5: GSM modem (1-port) converter detected [ 11.676620] usb 1-5: GSM modem (1-port) converter now attached to ttyUSB3 [ 11.676637] option 1-5:2.6: GSM modem (1-port) converter detected [ 11.676672] usb 1-5: GSM modem (1-port) converter now attached to ttyUSB4
Ähnlich sieht die lsusbAusgabe ziemlich normal aus.
Wie bekomme ich mein Huawei ME906s zum Verbinden?
Haben Sie versucht, das Sakis3g-Tool zu verwenden? Es funktionierte Wunder für mein Huawei Modem. Http://www.sakis3g.com/
Harvey vor 8 Jahren
0
Ich habe die Frage aktualisiert: Ja, ich habe sakis3g und ModemManager & NetworkManager ausprobiert, ohne Erfolg. Ich glaube, beide sind viel höher als meine Herangehensweise.
phihag vor 8 Jahren
0
3 Antworten auf die Frage
2
Harald Welte
Haben Sie den AT ^ RFSWITCH überprüft? Status? Es sollte AT ^ RFSWITCH: 1,1 zurückgeben. Wenn es Nullen gibt, befindet sich das Modem im rfkill-Modus "Flugzeug".
Das huawei-Modem verfügt über zwei Einstellungen für den RF-Schalter (auch als RFLOCK oder RFKILL bezeichnet): eine Hardware und eine Software. Die Software rf-kill kann deaktiviert werden, indem AT ^ RFSWITCH = 1 ausgegeben wird.
Die Hardware-Einstellung muss von Ihrem Mainboard / Ihrer Plattform aus deaktiviert werden, da sie tatsächlich einen Pin am M.2 / mPCIe-Anschluss zieht. Bei Laptops wird dies häufig durch eine ACPI-Funktionstaste gesteuert. Auf meinem X260 ist dies unter Linux als / sys / class / rfkill / rfkill3 / state verfügbar
Danke für die Antwort! Leider ist der Ausgang "^ RFSWITCH: 1,1" (ohne "AT", aber ich denke, das ist richtig) auf meinem Modem. Außerdem zeigt "rfkill" überall "no" und "cat / sys / class / rfkill / * / state" gibt eine Reihe von "1" aus.
phihag vor 8 Jahren
0
2
user3549596
Möglicherweise möchten Sie eine neuere Verbindungsmethode ausprobieren:
AT^NDISDUP=1,1,"internet.t-mobile"
Verwenden Sie dann einen DHCP-Client an Ihrer enp0s20f0u5c2Schnittstelle, den Sie sehen.
Wenn Sie verbunden sind, AT^DHCP?sollte auch eine Antwort mit Ihrer IP-Adresse in hexadezimaler Schreibweise erfolgen.
Dies hat zwei Upvotes, ich würde mich interessieren, wenn diese Methode wie beabsichtigt funktioniert.
user3549596 vor 8 Jahren
0
Ich entschuldige mich für die Verspätung. Ich habe einige Zeit gebraucht, um die SIM-Karte in einem Telefon zu testen, um herauszufinden, dass der Vertrag abgelaufen ist, und eine neue zu erwerben. Ich habe stattdessen die Frage mit dem Ergebnis der Verwendung von NDISDUP aktualisiert - leider sehe ich keinen signifikanten Unterschied.
phihag vor 8 Jahren
0
Kein Problem, ich hätte nur NDISDUP und danach keinen Befehl verwendet, es scheint, als hätten Sie ATD * 99 # verwendet, nachdem Sie NDISDUP eingegeben hatten.
user3549596 vor 8 Jahren
0
Ich habe das `ATD` entfernt (ich verwende keine Verbindung manuell mit minicom anstelle von wvdial), aber ich sehe immer noch dasselbe Verhalten - das Gerät 'enp0s20f0u5c2' ist als NO-CARRIER gekennzeichnet und ich kann keine Verbindung herstellen. Überraschenderweise wird "AT ^ DHCP?" Mit "ERROR" beantwortet. Soll das jemals passieren?
phihag vor 8 Jahren
0
Ich bin mir bei letzterem nicht sicher. Welchen Treiber verwendet Ihre Schnittstelle? "ethtool -i enp0s20f0u5c2" könnte "cdc_mbim" sein, und wenn ja, "mbimcli" könnte ein nächster Ansatz sein. DHCP ist nicht obligatorisch, wenn ich mich beim Übergeben von IPs an die Schnittstelle, insbesondere bei MBIM, richtig erinnere. Es wurde jedoch in früheren Ethernet-Geräten wie NCM verwendet. Mein Modem ist ein E3372, der NCM verwendet, und ich vermutete Ähnlichkeiten zwischen den Modellen.
user3549596 vor 8 Jahren
0
Ich habe diese Ausgabe auch der Frage am Ende hinzugefügt. "cdc_ether" scheint der WWAN zugeordnet zu sein.
phihag vor 8 Jahren
0
Danke, das war für mich jedoch unerwartet. Welche Kernel-Version verwendest du?
user3549596 vor 8 Jahren
0
Ich habe es mit verschiedenen neuen Kerneln ausprobiert, derzeit auf 4.6.0-1, die meiner Meinung nach recht aktuell sind.
phihag vor 8 Jahren
0
Verwenden Sie das Gerät mit einem Laptop? Ich würde davon ausgehen, aber der `ip link`-Status von` DOWN` wundert mich. Kann es sein, dass ein Hardwareschalter nicht richtig funktioniert? Vielleicht können Sie `dmesg` parsen, um herauszufinden, was das Modem beim Booten macht oder eine` lsusb'-Ausgabe. Der Grund für den Kernel war diese Festschreibung: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/usb?id=c5b5343cfbccffc5b65033fa4f407d7b7d98371d
user3549596 vor 8 Jahren
0
Ja, das ist ein Lenovo T460p. Ich habe das Verhalten mit dem jüngsten 4.7.0-rc4-Kernel reproduziert, der diesen Bugfix enthält. Die [lsusb-Ausgabe] (https://gist.github.com/phihag/7c045976849bccbc2ebf5fcd3d4e2e4c#file-lsusb-output) und dmesg (hinzugefügt am Ende der Frage) sehen beide normal aus. Möglicherweise ist dies ein einfacher Hardwarefehler, wenn die Antenne nicht angeschlossen ist.
phihag vor 8 Jahren
0
Könnte sein, aber ich würde davon ausgehen, dass selbst wenn keine Antenne angeschlossen ist, immer noch ein sehr schwaches Signal empfangen würde. Hier scheint der `ERROR` sofort zu erscheinen. Um ehrlich zu sein, habe ich keine Ideen. Sie könnten versuchen, sich an die ModemManager / libqmi / libmbim-Entwickler zu wenden. Bjorn ist normalerweise sehr freundlich und hilfsbereit. Ich denke, diese (https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel) Mailingliste wäre eine Platz zum Starten, und verlinken Sie diesen Thread, wenn Sie eine E-Mail schreiben.
user3549596 vor 8 Jahren
1
1
Kirill Bushminkin
Ich hatte das gleiche Problem mit meinem ME906s-158-Modem. Versuchte es über MBIM zu nutzen - kein Glück. Das Modem hatte eine veraltete Firmware - daher habe ich es auf die neueste Version von techship.com aktualisiert . Nach dem Update funktionierte ME906 wie erwartet im cdc_ether-Modus. Vor dem Aktivieren der Verbindung auf dem Modem sah die Netzwerkschnittstelle folgendermaßen aus:
26: enp0s29u1u2u5c2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether 02:1e:10:1f:00:00 brd ff:ff:ff:ff:ff:ff
Ich muss die Verbindung per AT-Befehl aktivieren AT^NDISDUP=1,1. Und Schnittstelle bekam IP über DHCP:
26: enp0s29u1u2u5c2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 02:1e:10:1f:00:00 brd ff:ff:ff:ff:ff:ff inet 10.173.107.197/30 brd 10.173.107.199 scope global dynamic enp0s29u1u2u5c2 valid_lft 518398sec preferred_lft 518398sec inet6 fe80::ef85:b8f8:761e:b922/64 scope link valid_lft forever preferred_lft forever