NO CARRIER com Huawei ME906s

3

Com o meu Huawei ME906s no Linux (testado com debian sid, debian experimental, Fedora 24 e Ubuntu 16.04, mas o resultado é o mesmo no Windows 10), recebo ERROR ou NO CARRIER messages (dependendo de qual dispositivo Estou a usar). Em contraste com esta questão , o comportamento é consistente e também ocorre quando eu corro wvdial longo após o boot. Eu removi o PIN do SIM e verifiquei que a rede móvel funciona com um smartphone Android.

Usando o Linux 4.7.0-rc4, vejo cinco dispositivos que posso associar ao cartão:

  • /dev/ttyUSB0 - Fala AT, saída mostrada abaixo
  • /dev/ttyUSB1 - Nenhuma saída (para GPS?)
  • /dev/ttyUSB2 - fala AT, mas responde ERROR em vez de NO CARRIER para discar
  • /dev/ttyUSB3 - mesmo comportamento que / dev / ttyUSB0
  • /dev/ttyUSB4 - Nenhuma saída (para GPS?)

Aqui está a saída que recebo com um wvdial.conf especialmente criado :

--> 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.

As últimas 5 linhas são repetidas mais de 10 vezes.

Outras ferramentas, como o sakis3g e o ModemManager / NetworkManager, também travam ao tentar se conectar.

Estou vendo também um link de rede associado ao modem, mas isso também não é acessível:

$ 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

Eu acredito que rfkill não esteja ativo:

$ 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

(falando com /dev/ttyUSB0 )

AT^RFSWITCH?
^RFSWITCH: 1,1

OK
Como sugerido, tentei usar AT^NDISDUP , sem sucesso (embora no próximo ATZ I veja linhas adicionais):

$ minicom -D /dev/ttyUSB0
ATZ
OK
^PDPSTATUS: 2
^NDISSTAT: 0,0,,"IPV4"
AT^NDISDUP=1,1,"internet.t-mobile"
OK

AT^DHCP?
ERROR

No entanto, ip link ainda mostra NO-CARRIER e dhclient -v enp0s20f0u5c2 também. Com ethtool eu vejo:

$ 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

O dmesg parece ser bom para mim:

[   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

Similarmente, o lsusb output parece bastante normal.

Como faço para conectar minha Huawei ME906s?

    
por phihag 20.05.2016 / 17:00

3 respostas

2

Você verificou o AT ^ RFSWITCH? status? Deve retornar AT ^ RFSWITCH: 1,1. Se houver zeros, o modem estará no modo "avião".

O modem huawei tem duas configurações de rf (também conhecidas como rflock ou rfkill): um hardware e um software. O Software rf-kill pode ser desativado emitindo AT ^ RFSWITCH = 1.

A configuração de hardware deve ser desativada na sua placa-mãe / plataforma, já que ela realmente baixa um pino no conector M.2 / mPCIe. Em laptops, isso geralmente é controlado por uma tecla de função ACPI. No meu X260, isso é exposto no Linux como / sys / class / rfkill / rfkill3 / state

    
por 26.05.2016 / 01:07
2

Você pode tentar um método de conexão mais recente:

AT^NDISDUP=1,1,"internet.t-mobile"

Em seguida, use um cliente DHCP na sua interface enp0s20f0u5c2 que você vê.

Se você está conectado, então AT^DHCP? também deve fornecer uma resposta com seu IP em notação hexadecimal.

    
por 06.06.2016 / 12:21
1

Eu tive o mesmo problema com meu modem ME906s-158. Tentei usá-lo via MBIM - sem sorte. O modem tinha um firmware desatualizado - por isso atualizei-o para o mais recente, consegui-lo em techship.com . Após a atualização, o ME906 funcionou como esperado no modo cdc_ether. Antes de ativar a conexão na interface de rede do modem, parecia:

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

Eu preciso ativar a conexão pelo comando AT AT^NDISDUP=1,1 . E a interface tem IP via 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
    
por 14.03.2018 / 18:41