Kesalahan 'ip-config-tidak tersedia' ketika modem USB mencoba untuk terhubung

Saya sudah mendapatkan modem ZTE MF-193E yang bekerja dengan baik sebelumnya. Ketika saya membeli modem ini lebih dari setahun yang lalu, itu bekerja dengan mudah di luar kotak. Sekarang, ketika Ubuntu mengalami kemajuan dalam versi, segala sesuatunya menjadi semakin sulit bagi saya.

Modem ini bahkan berfungsi beberapa bulan lalu dengan Ubuntu 15.04 (64-bit). Sekarang, di Ubuntu 15.10 (64-bit), ia tidak dapat terhubung.

Saya telah mengatur koneksi broadband seluler . Saya telah mencoba berbagai string untuk APN, tetapi ini belum menjadi masalah sebelumnya.

(Modem berfungsi baik di Windows 10, jadi, ini bukan masalah perangkat keras sama sekali. Juga, Modem Manager GUI mendeteksi perangkat ini dengan baik. SMS dapat dikirim dan diterima tanpa masalah.)

Ketika saya memasukkan modem, itu terdeteksi dengan baik, ikon CD ditampilkan di Unity dengan nama modem. Beberapa detik kemudian, saya mendapatkan kotak pesan

Mobile Broadband Network: you are registered on the home network

dekat ikon jaringan.

Ketika saya mencoba untuk terhubung, ikon nirkabel di applet manajer jaringan memulai gerakan sentrifugal itu, tetapi akhirnya gagal terhubung dan sebuah pesan memberi tahu saya bahwa saya sedang luring.

Baris saya bisa mengisolasi dari /var/log/syslogini,

NetworkManager[628]: <info>  (ttyUSB1): device state change: ip-config
> -> failed (reason 'ip-config-unavailable') [70 120 5]

Padahal, saya tidak yakin apakah ini yang relevan.

Lebih banyak garis dari /var/log/syslogdapat ditemukan di sini .

Pembaruan 1 - 06 Desember 2015

Seperti yang ditunjukkan oleh satu anggota yang baik, mencoba nf_conntrack_pptppendekatan modul.

Menjalankan perintah berikut,

$ lsmod | grep nf_conntrack_pptp | wc -l
0

$ sudo modprobe nf_conntrack_pptp
lsmod | grep nf_conntrack_pptp
nf_conntrack_pptp      20480  0
nf_conntrack_proto_gre    16384  1 nf_conntrack_pptp
nf_conntrack          106496  2 nf_conntrack_proto_gre,nf_conntrack_pptp

Kemudian mencoba modem saya, kegagalan yang sama. Log perubahan juga tidak terlihat.

Pembaruan 2 - 06 Desember 2015

Dieksekusi sebagai root,

systemctl restart network-manager.service

Tidak ada output di layar (terminal).

Log yang sesuai dari titik di atas ke upaya untuk terhubung menggunakan modem dapat ditemukan di sini .

Pembaruan 3 - 06 Desember 2015

Dipasang ofonodan kemudian mencoba modem lagi.

Silakan lihat log di sini .

Pembaruan 4 - 06 Desember 2015

Sekali lagi dieksekusi sebagai root,

systemctl restart network-manager.service

Log yang sesuai dari titik di atas ke upaya untuk terhubung menggunakan modem dapat ditemukan di sini .

Pembaruan 5 - 06 Desember 2015

Mengubah semua "tolak" menjadi "izinkan" di /etc/dbus-1/system.d/nm-dispatcher.conf.

Mencoba menghubungkan. Tidak berhasil

Beberapa jaringan terhubung dan terputus dengan koneksi Ethernet.

Diikuti oleh sudo systemctl restart network-manager.service.

Modem plug out dan pasang.

Mencoba menghubungkan lagi. Tidak terhubung.

Log ada di sini .

Pembaruan 6 - 06 Desember 2015

Dieksekusi

sudo killall ModemManager; sudo ModemManager --debug 2>&1 | tee /tmp/modem.log.txt

dan

export NM_PPP_DEBUG=1
sudo NetworkManager --no-daemon 2>&1 | tee /tmp/nm.log.txt

Tidak dapat berjalan mm-test.pykarena beberapa kesalahan. Apakah menemukan file di lokasi yang ditunjukkan. Dapatkan ini dari, https://github.com/openshine/ModemManager/blob/master/test/mm-test.py .

Perintah di atas agak berbeda dari yang ada di Wiki.

File log ada di sini .

Pembaruan 7 - 07 Desember 2015

Dieksekusi lagi (setelah perubahan yang disarankan /lib/udev/rules.d/40-usb_modeswitch.rulesdan reboot)

sudo killall ModemManager; sudo ModemManager --debug 2>&1 | tee /tmp/modem.log.txt

dan

sudo NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --log-level=debug --no-daemon > /tmp/nm.log.txt

The /var/log/syslogdisertakan juga.

File log ada di sini .

Pembaruan 8 - 08 Desember 2015

Kumpulan log yang diperbarui ada di sini .

Pembaruan 9 - 08 Desember 2015

Tes 1

1. Kali ini mem-boot komputer dari DVD Ubuntu 14.04 32 bit. Segera setelah komputer boot, mulai menangkap log MM.

2. Dimasukkan modem. lsusbmenunjukkan bahwa itu diakui sebagai perangkat 19d2: 1232 yang perlu diganti ke perangkat 19d2: 2003. Karena pemasangan usb-modewitch memerlukan reboot mesin (dan karenanya lepas instalasi untuk menjalankan DVD), saya menyiapkan file sakelar khusus dan mengganti modem dari baris perintah ( sudo usb_modeswitch -I -c 19d2:2003).

3. Segera setelah peralihan selesai, saya diberi tahu bahwa saya aktif Mobile Broadband Networkdan appreard Koneksi Broadband Baru di menu manajer jaringan.

4. Saya mengatur koneksi di atas dengan cara biasa (nama APN bukan masalah), dan koneksi dibuat secara otomatis.

5. Saya memutus dan mengeluarkan modem.

6. Berhenti mengambil log MM.

Log MM lengkap dan syslog untuk sesi mulai mengeluarkan modem dapat ditemukan di sini .

Tes 2

Tes yang sama dengan DVD Ubuntu 14.04 64 bit.

Log dapat ditemukan di sini .

Pembaruan 10 - 09 Desember 2015

Kali ini diuji dengan wvdialdan menemukan bahwa jika wvdialdijalankan sebagai root, kami mendapatkan koneksi yang sukses .

The wvdialconf dan log, dan sesuai syslog yang disini

Dugaan primer: situasi mungkin ada hubungannya dengan grup pengguna dari pengguna yang sesuai.

Tetapi seperti yang ditunjukkan di sini ,

Dengan semua alat ini, untuk membuat koneksi dialup, pengguna harus menjadi anggota dari grup "dip" dan "dialout", jadi letakkan semua pengguna yang seharusnya terhubung melalui dialup ke dalam grup ini.

Tapi seperti yang bisa kita temukan,

$ groups masroor
masroor : masroor adm dialout cdrom sudo dip plugdev lpadmin sambashare family wireshark

Jadi, pengguna sudah menjadi anggota grup yang ditunjukkan.

Sekarang, mungkin masalahnya bermuara pada salah satu dari poin-poin ini,

1. Kelompok tambahan apa yang dibutuhkan oleh pengguna?
2. Bagaimana kita menjalankan proses pengaturan koneksi broadband seluler sebagai root? (masalah keamanan?)

Pembaruan 11 - 09 Desember 2015

wvdialbekerja dengan USB3 dan tidak bekerja dengan USB1.

Silakan temukan syslog di sini .

Juga termasuk output dari dmesg | grep tty > /tmp/dmesg.tty.txt. Tapi lihat empat baris di dekat awal file?

Pembaruan 12 - 10 Desember 2015

1. Mengomentari baris 4 ( SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end") dalam /lib/udev/rules.d/77-mm-zte-port-types.rules.

2. Reboot mesin saya. Soft mencabut kabel dan memasukkan modem.

3. Mencoba terhubung. Gagal.

File syslog ada di sini .

Pembaruan 13 - 10 Desember 2015

Karena putus asa, untuk melihat apakah beberapa perubahan lokal mempengaruhi koneksi, menguji mesin dengan Ubuntu 15.04 dan 15.10 DVD.

1. Boot mesin dengan Xubuntu 15.04 64 bit DVD. Koneksi itu berhasil seperti pesona.
2. Boot mesin dengan Ubuntu 15.10 64 bit DVD. Koneksi gagal seperti sebelumnya.

Apa yang terjadi antara 15,04 dan 15,10?

Sangat membuat frustrasi.

Pembaruan 14 - 10 Desember 2015

1. Membuat file baru /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesseperti yang diperintahkan dalam jawaban.

2. Reboot mesin saya (atau dieksekusi sudo udevadm control --reload, benar-benar mencoba keduanya). Dimasukkan modem.

3. Modem telah dikenali.

   $ lsusb
   Bus 001 Device 005: ID 19d2:2003 ZTE WCDMA Technologies MSM
   

4. Soft mencabut kabel dan mencoba terhubung menggunakan modem. Gagal.

5. Mengeluarkan modem.

Mesin hang sekali, apakah itu kejadian acak? Mesin saya biasanya tidak hang setahun sekali.

File syslog dan file aturan yang dibuat ada di sini .

Pembaruan 15 - 11 Desember 2015

1. Menambahkan baris berikut ke /lib/udev/rules.d/40-usb_modeswitch.rules.

   # ZTE MF193E
   ATTR{idVendor}=="19d2", ATTR{idProduct}=="1232", RUN+="usb_modeswitch '%b/%k'"
   

2. Biarkan file /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulestetap utuh.

3. Reboot mesin saya. Dimasukkan modem.

4. Modem telah dikenali.

   Bus 001 Device 005: ID 19d2:2003 ZTE WCDMA Technologies MSM
   

5. Soft mencabut kabel dan mencoba menghubungkan. Gagal.

6. Mengeluarkan modem.

7. Dihapus /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules.

8. Reboot dan coba seluruh proses lagi. Tidak berhasil lagi.

File syslog (lengkap, saya tidak mengambil risiko kehilangan bagian penting) dan file aturan yang disebutkan (40) ada di sini .

Pembaruan 16 - 11 Desember 2015

1. Hanya tersisa satu aturan 1232 /lib/udev/rules.d/40-usb_modeswitch.rules, dihapus yang lain.

2. Dieksekusi sudo udevadm control --reload.

3. Dimasukkan modem.

4. Modem telah dikenali.

   Bus 001 Device 005: ID 19d2:2003 ZTE WCDMA Technologies MSM
   

5. Soft mencabut kabel dan mencoba menghubungkan. Gagal.

6. Mengeluarkan modem.

Tapi bukankah kita menguji sistem default di atas? Apakah Anda bermaksud meninggalkan /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulestempatnya?

File syslog (selesai, saya tidak mengambil risiko kehilangan bagian penting) dan file aturan yang disebutkan (40) ada di sini

Pembaruan 17 - 11 Desember 2015

1. Mengomentari aturan 1232 di /lib/udev/rules.d/40-usb_modeswitch.rules, menambahkan satu untuk tahun 2003.

   # ZTE MFxxx
   # Added on December 11 2015
   ATTR{idVendor}=="19d2", ATTR{idProduct}=="2003", RUN+="usb_modeswitch '%b/%k'"
   

2. Dieksekusi sudo udevadm control --reload.

3. Dimasukkan modem.

4. Modem dikenali sebagai perangkat 1232 . Saya tidak ditawari untuk mencoba menghubungkan (sejauh pengetahuan saya, itu tidak akan didaftarkan ke jaringan broadband kecuali pergantian telah terjadi pada 2003)

   Bus 001 Device 008: ID 19d2:1232 ZTE WCDMA Technologies MSM
   

5. Mengeluarkan modem.

File syslog dan file aturan yang disebutkan (40) ada di sini

Pembaruan 18 - 11 Desember 2015

1. Masukkan semua file aturan dalam bentuk aslinya.

2. Menonton lsusboutput setiap satu detik menggunakan skrip shell. Output yang diambil dalam file yang dicap waktu.

3. Dimasukkan modem. (Modem pertama kali muncul dalam file lssuboutouput.Fri Dec 11 16:56:29 BDT 2015.txt). Seperti yang dapat kita temukan dari tangkapan, jelas bahwa ia beralih dari perangkat 1232 ke perangkat 2003.

4. Mencoba terhubung. Gagal.

5. Mengeluarkan modem.

File syslog, lsusboutput cap waktu dan file aturan yang disebutkan ada di sini .

Sekarang, Anda mungkin ingin mencocokkan keluaran syslog dengan stempel waktu.

Pembaruan 19 - 11 Desember 2015

Melakukan tes ini di arah yang sama sekali baru dengan harapan bahwa saya dapat mengisolasi masalah.

1. Disimpan dalam media portabel /lib/udev/rules.d/40-usb-media-players.rulesdan /lib/udev/rules.d/77-mm-zte-port-types.rules(dari mesin Ubuntu 15.10).

2. Boot mesin menggunakan Xubuntu 15.04 64 bit DVD.

3. Dieksekusi diff 77-mm-zte-port-types.rules /lib/udev/rules.d/77-mm-zte-port-types.rules > diff15.10and15.04_77-mm.txt. File pertama adalah dari yang disimpan dari 15.10.

   Pemeriksaan file diff tidak menunjukkan idProduct1232 atau 2003.

4. Dieksekusi diff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules > diff15.10and15.04_40-usb.txt. Sekali lagi, file pertama adalah dari yang disimpan dari 15.10.

   Sekali lagi, pemeriksaan file diff tidak menunjukkan idProduct1232 atau 2003.

5. Dimasukkan modem. Modem dikenali sebagai modem.

   $ lsusb
   Bus 001 Device 008: ID 19d2:2003 ZTE WCDMA Technologies MSM
   

6. Dapat terhubung dengan mudah setelah mengatur koneksi broadband seluler.

7. Mengeluarkan modem.

8. Menginstal USB_ModeSwitch terbaru.

   diff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules
   

   Sekarang mengembalikan NULL, seperti yang diharapkan.

9. Dieksekusi sudo udevadm control --reload-rules.

10. Dimasukkan modem. Modem dikenali sebagai modem.

    $ lsusb
    Bus 001 Device 008: ID 19d2:2003 ZTE WCDMA Technologies MSM
    

11. Bisa terhubung dengan mudah.

Saya bisa mencoba meningkatkan MM dan NM ke Ubuntu 15.10, hanya untuk melihat di mana ia rusak. Saya benar-benar mencoba tetapi menyerah karena masalah ketergantungan yang tak ada habisnya.

Semua file diff yang disebutkan di atas ada di sini .

Pembaruan 20 - 12 Desember 2015

Tes 1

1. Dalam /lib/udev/ruleskondisi asli.

2. Perangkat modem belum dimasukkan dalam sesi ini.

3. Pengaturan ModemManager untuk debugging dan pengaturan pengambilan udevadm.

   sudo udevadm monitor --e |& tee udevadm.update20.WITHOUT78.log
   sudo killall ModemManager; sudo ModemManager --debug 2>&1 | tee MM.update20.WITHOUT78.log
   

4. Dicolokkan ke modem dan menunggu hingga dikatakan telah terdaftar di jaringan broadband.

5. Mencoba terhubung dengan tidak berhasil.

6. Mengeluarkan modem.

7. Mengisi file log.

Tes 2

Ulangi tes di atas dengan /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesdi tempat.

Nama file log cukup jelas.

Semua file log di atas ditambah syslog dan 78 file aturan ada di sini .

Saya berharap semua file log datang dengan stempel waktu, membuat pencocokan lebih mudah.

Pembaruan 21 - 15 Desember 2015

1. Mengubah file aturan seperti yang disarankan.
2. Reboot mesin saya.
3. Dimasukkan modem dan mencoba menghubungkan. Tidak berfungsi.

File aturan dan syslogada di sini .

Pembaruan 22 - 16 Desember 2015

Seperti yang disarankan dalam satu komentar, instal berbagai kernel dari http://kernel.ubuntu.com/~kernel-ppa/mainline/ dan mencoba menghubungkan menggunakan modem setelah boot di masing-masing.

1. 4.2.8-040208-generik, kegagalan.

2. 4.1.15-040115-generik, kegagalan.

3. 4.0.9-040009-generik, kegagalan.

Jadi, mungkin, kita bisa mengesampingkan masalah kernel.

Pembaruan 23 - 16 Februari 2016

Modem sudah mulai berfungsi di Ubuntu 16.04. Versi ini masih dalam Alpha 1, tetapi berfungsi dengan baik di laptop saya.

Memuat ofonopaket memang baik, mungkin, tetapi ternyata model modem Anda, ZTE MF193E, tidak ada dalam daftar ZTE. Membandingkannya dengan modem ZTE lainnya, mis. MF190J, modem ini cenderung membutuhkan udevaturan khusus yang sama , untuk dijalankan usb_modeswitchketika dongle dimasukkan, dan untuk mencapai itu Anda dapat, sebagai root, menambahkan udevaturan baru ke file
/lib/udev/rules.d/40-usb_modeswitch.rules
dengan dua berikut baris misalnya, di suatu tempat dekat # ZTE MF190Jkomentar:

# ZTE MF193E
ATTR{idVendor}=="19d2", ATTR{idProduct}=="2003", RUN+="usb_modeswitch '%b/%k'"

ditambah garis kosong, sehingga terlihat enak dipandang.

Mungkin bijaksana untuk reboot setelah itu, hanya untuk menemukan itu semua berfungsi seperti sihir :-)

Atau tidak. Seperti yang Anda tahu, ini adalah air yang dalam bagi saya, tetapi jika masih tidak berhasil, log debug ModemManager lain akan diperlukan, untuk tebakan liar lainnya.

EDIT:

Saya sekarang melihat dua baris di modemmanager.txt:

[mm-broadband-bearer.c:1254] connect(): Launching 3GPP connection attempt with APN 'WAP'

dan

[mm-broadband-bearer.c:994] parse_pdp_list(): Found PDP context with CID 1 and PDP type ipv4 for APN 'wap'

Saya kira yang pertama mengacu pada pengaturan broadband Anda, sedangkan yang kedua mengacu pada pengikatan internal ke "konteks PDP" (apa pun itu). Dengan tampilan itu, modem menawarkan 9 konteks alternatif, termasuk satu dengan apn='WAP', tetapi ModemManagerpuas dengan case match yang tidak sensitif.

Perbedaan kasus mungkin menjadi penyebab masalah berikut: misalnya, bahwa ppp menginginkan 'wap'konfigurasi (bukan 'WAP') dan tidak menemukannya, atau yang diharapkan oleh ujung jarak jauh apn='WAP', tetapi mendapat 'wap' yang tersendat.

Opsi pertama dapat dengan mudah diuji (dan disingkirkan, mungkin) dengan mengubah konfigurasi Anda untuk menggunakan 'wap' alih-alih 'WAP'. Anda mungkin pernah mencoba ini sebelumnya, tetapi pada saat itu tanpa ofonopaket, jadi tes lain tidak akan sakit, meskipun opsi kedua lebih mungkin.

Opsi kedua juga lebih merupakan masalah, mengingat ada kecocokan "konteks PDP" huruf besar yang tersedia dari modem. Googling masalah ini, tampaknya kecocokan case case benar dengan spesifikasi (tampaknya relevan) "3GPP TS 23.003 bab 9.1", dan patch untuk melakukan ini ditambahkan ModemManagerpada November tahun lalu (ke dalam versinya mm-1-4, Saya bisa mengumpulkan). Jadi dalam kasus ini, modem Anda belum diberi tahu, dan mengharapkan pencocokan case sensitif, sementara ModemManagersayangnya menggunakan pencocokan case-sensitive langsung daripada sebagai fallback.

Salah satu solusi untuk masalah kedua tentu saja menggunakan yang berbeda ModemManager: baik dengan mencari dan menginstal versi sebelum tambalan ini, atau (dengan waktu luang yang cukup), roll sendiri ModemManager. Tetapi tidak ada yang dilakukan dengan hati-hati, jadi mungkin kita perlu menelusuri sedikit untuk mendapatkan lebih banyak bukti bahwa ini adalah (sekarang) masalahnya, dan jika mungkin menemukan cara lain untuk mengatasinya. Atau dengan sedikit keberuntungan, seseorang yang tahu sesuatu mampir ...

EDIT 2

Ya, kembalikan versi tidak mudah karena ketergantungan. Dan menggulung sendiri juga jauh dari sukacita.

Dua kemungkinan alat yang berguna: command mmcliand ( http://m2msupport.net/m2msupport/module-tester/ ).

Masalahnya, saya pikir, adalah bahwa ModemManager memilih konteks PDP 1 dengan apn = 'wap' di mana ia harus memilih konteks PDP 9 dengan apn = 'WAP'. Mungkin ini bisa diatasi dengan menggunakan salah satu alat itu. Entah untuk dapat memaksa pilihan 9 selama koneksi, atau dengan menghapus konteks 'wap' yang buruk dari modem, yang diiklankan mampu dilakukan oleh alat penguji modul.

Alat modem-tester tampaknya merupakan alat java di browser, jadi Anda perlu mengatur browser Anda untuk mengetahui di mana java Anda berada, dan Anda membutuhkan java untuk diketahui. Maka silakan jelajahi pendekatan itu; Saya belum menggunakannya sendiri, tetapi melihat screenshot, saya kira itu akan menyajikan konteks PDP sebagai tab 'Panggilan Data', di mana Anda pertama-tama mencatat semua yang ditampilkan, dan kemudian mengedit entri 'wap' untuk ubah label 'wap' apn menjadi, katakanlah, 'wap1' dan 'wap2' (sehingga dapat "menyembunyikan" label-label itu ketika mencari 'WAP'). Kemudian simpan dan tutup, dan sulurkan dongle itu lagi. Ambil log; tampaknya syslog sudah cukup sekarang, kalau-kalau masih menolak untuk bermain.

The mmcliPerintah juga tampaknya berguna dalam cerita ini; lakukan man mmcliuntuk membaca tentang itu, tapi saya tidak melihat apa pun tentang konteks PDP di sana.

EDIT 3

Panggilan bagus! untuk menguji dari DVD. Itu memberi tahu kami bahwa saya berada di jalur yang salah dengan APN, dan semuanya terletak pada mendapatkan ppp untuk muncul. Setidaknya, itu akan menjadi pohon baru saya untuk menggonggong.

Pertama-tama kita perhatikan bahwa ada perbedaan versi untuk pppd (dari 2.4.5 ke 2.4.6), tapi itu mungkin bukan masalah, karena semua orang di dongle pasti akan bertamasya.

Hmm, ppp; Saya perlu membangkitkan kenangan milenium terakhir saya :-). Sayangnya saya sibuk hari ini, tetapi saya akan menyentuh pangkalan ketika berikutnya saya punya waktu, untuk melihat seberapa jauh Anda telah datang. Gang belakang pertama saya yang akan ditelusuri adalah: 1) apakah pengguna di grup yang tepat? 2) apakah kredensial benar? 3) apakah file ppp / chat konfigurasi mod benar? Log debug ppp keluar dalam nm.txt (seperti beberapa hari yang lalu), tetapi harus juga ada cara untuk meminta log lebih detail.

EDIT 4

Pastikan /etc/ppp/pap-secretsdan /etc/ppp/chap-secretsmemiliki grup dip(menggunakan chgrpsesuai kebutuhan) dan mode 740(atau -rw-r-----) (menggunakan chmodsesuai kebutuhan). Milik saya tidak.

EDIT 5

Bagaimana dengan pohon ini, kemudian: Membandingkan wvdialsyslog yang berfungsi dengan syslog yang tidak berfungsi, tampaknya karena alasan tertentu wvdialdigunakan ttyUSB3sementara yang tidak bekerja ModemManagerterus menggunakan ttyUSB1. Saya tidak yakin apakah itu sama sekali signifikan, tetapi ternyata tetapi ttyUSB1dan ttyUSB3keduanya merespons sebagai modem yang mampu.

Jadi, sebagai ujian, mungkin Anda dapat mengeditnya /etc/wvdial.confsehingga di bawahnya [Dialer Defaults]termasuk baris:

Modem = /dev/ttyUSB1

untuk satu tes, dan ttyUSB3untuk yang lain; keduanya berjalan sebagai root; hanya untuk melihat apakah ada perilaku yang berbeda. Terutama, jika menggunakan ttyUSB1adalah masalah sedangkan menggunakan ttyUSB3 tidak, maka akan baik untuk melihat bagaimana membuat ModemManager menggunakan ttyUSB3 juga. Untuk hasil tes lainnya, saya akan mengatakan kita akan kembali mengejar ferret di tanah ppp.

EDIT 6

Log dmesg bisa diabaikan saya pikir; sudah seperti itu di semua log. Syslog baru hanya menunjukkan tes ttyUSB3, tetapi mungkin kita dapat berasumsi bahwa hidup menjadi lebih baik jika NetworkManagerdapat menggunakan ttyUSB3 dan mengabaikan ttyUSB1 (untuk modem ini).

Saya juga menemukan ( https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/819784 ) dengan postingan khusus # 10 membingungkan :-(

Aturan yang tampaknya berlaku udevdalam /lib/udev/rules.d/77-mm-zte-port-types.rulestidak berlaku, tetapi seharusnya menjadi tujuan. Dan, dengan hanya wawasan pra-101 yang sangat sederhana tentang udevsihir, bagaimanapun saya akan mempertimbangkan mempertanyakan baris ke-4, yang mengatakan:

SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end"

Saya pikir kalimat itu perlu inisial #agar bisa dikomentari. Secara terperinci, bacaan saya tentang file tersebut adalah bahwa ia memerlukan status panggilan SUBSYSTEM == "tty" dan SUBSYSTEMS = "usb" untuk menggunakan bit yang baik, termasuk aturan produk "2003", dan setidaknya untuk pengujian, seharusnya aman untuk melewati pemfilteran "tty". Dan saya tidak punya yang lebih baik sekarang.

EDIT 7

Setelah menghabiskan waktu berkualitas dengan mesin pencari favorit saya, saya lebih percaya bahwa pilihan ttyUSB adalah masalah mendasar di sini. Aturan udev yang saya tunjuk tidak apa-apa, dan Anda harus mengembalikan suntingan itu.

Namun, saya mulai percaya bahwa aturan konfigurasi menjelang akhir file itu, karena id produk "2003" menyesatkan. Dari log, menurut saya, id produk "2003" sebenarnya adalah sisi perangkat memori dongle, sedangkan sisi modem memiliki id produk "1232". Anda dapat menguji ini dengan mereplikasi dua aturan "2003" untuk id produk "1232", dalam file/lib/udev/rules.d/77-mm-zte-port-types.rules

ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="1232", ENV{.MM_USBIFNUM}=="03", ENV{ID_MM_ZTE_PORT_TYPE_MODEM}="1"
ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="1232", ENV{.MM_USBIFNUM}=="01", ENV{ID_MM_ZTE_PORT_TYPE_AUX}="1"

atau lebih baik, tambahkan file baru di sebelahnya, misalnya dinamai 78-ralph.rules, tetapi kemudian Anda juga perlu menambahkan perlindungan SUBSYSTEM dan SUBSYSTEMS di sekitarnya.

Kemudian, tarik dongle, jalankan udevadm control --reload(atau reboot), dan masukkan dongle. Dan kemudian syslogmenangkap lagi , kecuali sekarang berhasil.

Masalah yang efektif, bagaimanapun, adalah bahwa ModemManager membuang plugin libmm-plugin-zte.sosaat pre-probing, dan akhirnya menggunakan pengendali modem generik. Jika saya benar tentang id produk, maka ini mungkin alasannya; bahwa pre-probing mencari ID_MM_ZTE_PORT_TYPE_MODEMatribusi, dan ini kurang untuk id produk "1232" (sebelum tambalan), dengan efek bahwa plugin zte akan dibuang.

EDIT 8

The sysloglog adalah singkat sedikit; kehilangan permulaan di mana ModemManager gagal menginstal plugin zte. Namun, jelas bahwa plugin modem Generik digunakan. Sekarang, mungkin usb_modeswitchaturan yang saya berikan sebelumnya juga salah; ia memutuskan untuk beralih ke "2003" ketika saya pikir itu beralih dari "2003". Tapi, man usb_modeswitch(yang seharusnya saya lihat sebelumnya) semacam menyarankan bahwa itu bergeser ke id produk daripada dari itu. Bagaimanapun, log menunjukkan hal itu terjadi. Jadi, silakan ubah aturan itu untuk menggunakan "1232", dan coba lagi.

Jika tidak ada yang lain, setidaknya saya harus belajar sedikit tentang udev.

EDIT 9

Baik. Masalahnya masih (atau juga) bahwa ModemManager menjatuhkan plugin ZTE di pre probing. Log debugging ModemManager untuk 15.10 (log menetapkan "debuglog * *)) semua menceritakan kisah bahwa plugin ZTE dibuang karena tes vendor-id / produk-id.

Pergi ke sumbernya, Luke! Saya mengambil kesempatan ini untuk melihat kode sumber ModemManager secara singkat, dan ini menunjukkan bahwa plugin sebagai tabel vid / pid yang tidak termasuk 19d2 / 2003 ... meskipun, saya belum menemukan sumber tabel itu, jadi saya tidak bisa dapat memverifikasi.

Atau mungkin ada masalah waktu di sini. Misalnya, bahwa ModemManager menjalankan pre-probing saat perangkat 19d2 / 1232. Pikiran itu selaras dengan pengamatan bahwa memiliki 78-mm-zte-port-types-RALPH. Aturan udev membuat ModemManager sedikit lebih bahagia dengan perangkat. Namun, mengapa tidak tetap senang dan menggunakan plugin itu saat perangkat dialihkan ke 19d2 / 2003?

Mungkin diperlukan lebih banyak log :-) Dengan ModemManager didebug, dan juga tangkapan perintah udevadm monitor --e |& tee udevadm.log(di terminal lain) saat Anda mencolokkan perangkat. Saya mendapat perintah itu dari ( https://wiki.ubuntu.com/DebuggingUdev )

Lakukan ini dua kali: sekali tanpa 78-mm-zte-port-types-RALPH.rulesdan sekali dengan aturan ... kedua kali dari reboot baru. Yaitu

1. pengaturan /lib/udev/rules.ddengan atau tanpa *-RALPH.rulesfile
2. tarik perangkat
3. reboot
4. setup ModemManager untuk debugging dan setup capture udevadm
5. tancapkan perangkat dan tunggu sebentar
6. kemas file log
7. ulangi dari 1 dengan tes berikutnya

Pencatatan itu harus memberi tahu di mana plugin ZTE dijatuhkan, dan seperti yang saya mengerti, itu juga akan memberi tahu tentang penanganan peristiwa udev.

EDIT 10

(Saya hampir berada di ujung tambatan saya di sini, tetapi saya memiliki satu atau dua napas lagi :-)

Pertama, semua udevdekorasi tampaknya berakhir sebagaimana mestinya, dengan hanya beberapa tanda tanya di beberapa atribut. Secara khusus, 78-*-RALPH.rulesharus dibuang; itu tidak berguna.

Saya pikir saya bisa membacakan sesuatu dari ini, tetapi saya tidak yakin bagaimana cara memperbaikinya. Pada dasarnya, seperti yang saya lihat, ketika dongle terpasang, ada banyak peristiwa udev. Berfokus pada orang-orang tentang ttyUSB1, ada acara "awal":

KERNEL[3867.310990] add      /devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.1 (usb)

yang menyebabkan usb_serialdriver dimuat, dan /dev/ttyUSB1muncul. Yang secara khusus menyebabkan peristiwa lain:

KERNEL[3867.435102] add      /devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.1/ttyUSB1/tty/ttyUSB1 (tty)

Saya pikir itu juga pemicu ModemManager. Anda harus pergi untuk syslogmelihat bukti ini, karena tidak ada korelasi yang ketat antara log. Acara ini dicap waktu 3867.435102, dan syslogmenyajikan ModemManagerbaris log terdekat berikutnya tepat setelah baris log kernel dicap 3867.437412.

Menurut saya, ModemManagerseharusnya tidak dipicu, tetapi hanya setelah acara ttyUSB1 berikutnya:

UDEV  [3867.580427] add      /devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.1/ttyUSB1/tty/ttyUSB1 (tty)

yang telah melampirkan atribut ZTE.

Dalam log MM, kita akan berada di baris yang dicap 1449934745.363291, yang ternyata adalah cap waktu "real time" daripada cap "waktu kernel".

ModemManager kemudian dilakukan dengan pre-probing di1449934745.450398 , yaitu, 87ms nanti, yang dalam istilah waktu kernel akan dekat 3867.524519dan 55ms sebelum laporan acara UDEV "baik" di atas.

Perhatikan bahwa dalam syslog, ModemManagerapakah mengajukan keluhan ituttyUSB1 tidak memiliki atribut yang ditetapkan, dan mungkin keluhan itu terkait dengan "penandaan" yang terjadi di 80-mm-candidate.rules. Dengan komentar di file itu, penandaan itu tampaknya merupakan upaya untuk mengatasi masalah ini dengan tepat, tetapi jika demikian, sepertinya tidak berfungsi dalam kasus ini.

Mungkin satu kemungkinan untuk menyelesaikan ini adalah dengan mengubah aturan "tty" 80-mm-candidate.rulesmenjadi:

ENV{.ID_PORT}=="?*", SUBSYSTEM=="tty", ENV{ID_MM_CANDIDATE}="1"

Dalam pikiran saya, itu akan memastikan bahwa ID_MM_CANDIDATEpengaturan tertunda hingga atribut ZTE ditetapkan. The .ID_PORTPengaturan adalah efek dari60-serial.rules aturan (disebut 60-persistent-serial.rulessebelumnya), dan kondisi ditambahkan ke aturan penandaan hanya bahwa ia memiliki nilai.

Kondisi ini bukan atribut ZTE, hanya untuk menjaga aturan lebih umum. Satu langkah yang lebih spesifik adalah sebagai ENV{.MM_USBIFNUM}="?*"gantinya meminta , karena tugas di sini terjadi oleh77-mm-zte-port-types.rules .

Secara umum saya tidak begitu yakin tentang udevaturan pemesanan, dan saya juga sama sekali tidak yakin bahwa ini benar-benar berhenti ModemManagerdari bertindak terlalu cepat. Namun jika tidak, maka 80-mm-candidate.rulesakan memiliki sedikit atau tidak ada fungsi, dan mungkin kemudian semuanya akan turun ke "perbaikan" untukModemManager dari 15,04.

EDIT 21

mendesah. Mungkin tidak relevan, tetapi Anda mungkin ingin memeriksa7-zte-mutil_port_device.rules file ; apakah itu sisa dari eksperimen lain? Bagaimanapun, tidak relevan di sini.

Masih ada hampir satu detik antara 515.558184dan di 516.381549mana ModemManagerdengan penuh semangat dan keliru meraih /dev/ttyUSB1, dan sementara mengeluh tentang hal itu tidak diatur, masih melewati pra-penyelidikan dan membuang plugin ZTE. Dengan kata lain, tambalan aturan tidak dibuatModemManager menunggu.

Saya kira Anda juga diuji menggunakan ENV{.MM_USBIFNUM}="?*"bukanENV{.ID_PORT}=="?*" .

Sebenarnya, untuk mengonfirmasi apakah pengaturan ENV{ID_MM_CANDIDATE}=1penting atau tidak , Anda harus pindah sementara 80-mm-candidate.rules, lalu melihat (masuk syslog) apakah kemudian ModemManagerdiabaikan /dev/ttyUSB1atau tidak. Saya curiga "tidak".

Dan kemudian, yah, mungkin Anda bisa menggunakan versi yang berfungsi, seperti 14,04, dan jika perlu, mungkin jalankan 15,10 di kotak virtual, kecuali tentu saja semuanya sudah ada di kotak virtual.

Saya pikir saya perlu mengklaim kekalahan pada saat ini.

Modem sudah mulai berfungsi di Ubuntu 16.04. Versi ini masih dalam tahap pengembangan, tetapi berfungsi dengan baik di laptop saya.

Saya berharap dapat memberikan rincian teknis lebih lanjut tentang bagaimana itu mulai berfungsi.

Setelah melirik ini nampaknya ini bukan pertama kalinya naga ini ditangani dengan benar. Itu adalah bug sebelumnya di 12.10 dan 13.04 mungkin bug tidak pernah diperbaiki atau patch baru memecahkan sesuatu yang berfungsi dengan benar sebelumnya.

Mudah-mudahan, Jika saya membaca spesifikasi teknis Anda dengan benar, saya perlu mengarahkan Anda ke arah ini (MF190J):

Modem 3G (ZTE MF190J) masih membutuhkan penyesuaian manual.

Sudahkah Anda mencoba ini:

 rfkill list up

lalu buat skrip ini dan jalankan:

 #/bin/sh

     Case [!$] in
        /bin/sh
        networkname="true"
        networkname="the ip adr type in here"
        nmcli nm networkname --force-yes
        resolve.conf the ip adr type in here
     endl

dan ini mungkin bekerja dengan baik seperti ini.