USB modem bağlanmaya çalıştığında 'ip-config-kullanılamıyor' hatası

Daha önce iyi çalışan bir ZTE MF-193E modeme sahibim. Bu modemi bir yıldan fazla bir süre önce satın aldığımda, kutudan kolayca çıktı. Ubuntu versiyon olarak ilerledikçe işler benim için gittikçe zorlaşıyor.

Bu modem, Ubuntu 15.04 (64 bit) ile birkaç ay önce bile çalıştı. Şimdi, Ubuntu 15.10 (64 bit) 'de bağlanamıyor.

Bir mobil geniş bant bağlantısı kurdum . APN için çeşitli dizeleri denedim, ama bu daha önce bir sorun değildi.

(Modem Windows 10'da iyi çalışır, bu yüzden bu bir donanım sorunu değildir. Ayrıca, Modem Manager GUI bu cihazı güzel bir şekilde algılar. SMS'ler sorunsuz bir şekilde gönderilebilir ve alınabilir.)

Modemi taktığımda, düzgün algılanıyor, Unity'de modemin adıyla bir CD simgesi görüntüleniyor. Birkaç saniye sonra bir mesaj kutusu alıyorum

Mobile Broadband Network: you are registered on the home network

ağ simgesinin yanında.

Bağlanmaya çalıştığımda, ağ yöneticisi uygulamasındaki kablosuz simgesi bu santrifüj hareketlerini başlatır, ancak sonunda bağlanamaz ve bir mesaj bana çevrimdışı olduğumu söyler.

İzole edebileceğim çizgi /var/log/syslogşudur,

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

Yine de, bunun ilgili olup olmadığından emin değilim.

Buradan daha fazla satır /var/log/syslogbulunabilir .

Güncelleme 1 - 06 Aralık 2015

Bir tür üyenin işaret ettiği gibi, nf_conntrack_pptpmodül yaklaşımını denedi .

Aşağıdaki komutları yerine getirdi,

$ 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

Sonra modemimi denedim, aynı hata. Günlükte fark edilebilir bir değişiklik de yok.

Güncelleme 2 - 06 Aralık 2015

Kök olarak yürütülür,

systemctl restart network-manager.service

Ekranda çıkış yok (terminal).

Yukarıdaki noktadan modemi kullanarak bağlanma girişimine karşılık gelen günlük burada bulunabilir .

Güncelleme 3 - 06 Aralık 2015

Kuruldu ofonove sonra modemi tekrar denedi.

Günlüğünü bakınız burada .

Güncelleme 4 - 06 Aralık 2015

Yine kök olarak idam edildi,

systemctl restart network-manager.service

Yukarıdaki noktadan modemi kullanarak bağlanma girişimine karşılık gelen günlük burada bulunabilir .

Güncelleme 5 - 06 Aralık 2015

Tüm "reddet", "izin ver" olarak değiştirildi /etc/dbus-1/system.d/nm-dispatcher.conf.

Bağlanma denendi. Şanssız.

Birkaç ağ Ethernet bağlantısı ile bağlanır ve çıkarılır.

Ardından sudo systemctl restart network-manager.service.

Modem fişi ve fişi.

Tekrar bağlanmayı denedi. Bağlanmıyor.

Günlük burada .

Güncelleme 6 - 06 Aralık 2015

Gerçekleştirilen

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

ve

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

mm-test.pyBirden fazla hata nedeniyle çalıştırılamadı . Dosyayı belirtilen konumda buldunuz. Bunu https://github.com/openshine/ModemManager/blob/master/test/mm-test.py adresinden aldım .

Yukarıdaki komutlar, Wiki'deki komutlardan biraz farklıdır.

Günlük dosyaları burada .

Güncelleme 7 - 07 Aralık 2015

Yeniden yürütülür (önerilen değişiklik /lib/udev/rules.d/40-usb_modeswitch.rulesve yeniden başlatma işleminden sonra )

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

ve

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

De /var/log/syslogdahildir.

Günlük dosyaları burada .

Güncelleme 8 - 08 Aralık 2015

Günlüğe kaydedilen günlük kümesi burada .

Güncelleme 9 - 08 Aralık 2015

Test 1

1. Bu kez bilgisayarı bir Ubuntu 14.04 32 bit DVD'den başlattı. Bilgisayar açılır açılmaz, MM günlüğünü yakalamaya başladı.

2. Modemi taktı. lsusb19d2: 2003 cihazına dönüştürülmesi gereken bir 19d2: 1232 cihazı olarak tanındığını gösterdi. Usb-mod anahtarının kurulumu makinenin yeniden başlatılmasını gerektirdiğinden (ve dolayısıyla DVD çalışması için kurulumu kaybettiğinden), özel bir anahtar dosyası hazırladım ve modemi komut satırından ( sudo usb_modeswitch -I -c 19d2:2003) değiştirdim.

3. Anahtarlama gerçekleştirildi En kısa sürede ben üzerinde bilgi verildi Mobile Broadband Networkve ağ yöneticisi menüsünden Yeni Genişbant Bağlantı appreard.

4. Yukarıdaki bağlantıyı her zamanki gibi ayarladım (APN adı bir sorun değildi) ve bağlantı otomatik olarak kuruldu.

5. Modemin bağlantısını kestim ve çıkardım.

6. MM günlüğünü yakalamayı durdurdu.

Modemin çıkarılması için oturum başlatma işleminin tam MM günlüğü ve syslog'u burada bulunabilir .

Test 2

Bir Ubuntu 14.04 64 bit DVD ile aynı test.

Günlükleri burada bulabilirsiniz .

Güncelleme 10 - 09 Aralık 2015

Bu kez test edildi wvdialve wvdialkök olarak çalıştırıldığında başarılı bir bağlantı elde ettiğimizi tespit etti .

wvdialConf ve günlük ve syslog'u tekabül vardır burada

Birincil varsayım: durumun karşılık gelen kullanıcının kullanıcı grubuyla ilgisi olabilir.

Ancak burada belirtildiği gibi ,

Tüm bu araçlarla, çevirmeli bağlantı kurmak için kullanıcının "dip" ve "dialout" gruplarına üye olması gerekir, bu nedenle çevirmeli bağlantı yoluyla bağlanması gereken tüm kullanıcıları bu gruplara koyun.

Ama bulabildiğimiz gibi,

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

Yani, kullanıcı zaten belirtilen grupların bir üyesidir.

Şimdi, belki de sorun bu noktalardan birine dayanıyor,

1. Kullanıcının hangi ek grup olması gerekir?
2. Mobil geniş bant bağlantı kurulum işlemini root olarak nasıl çalıştırıyoruz? (güvenlik sorunları?)

Güncelleme 11 - 09 Aralık 2015

wvdialUSB3 ile çalışır ve yapar değil USB1 ile çalışmalarını.

Lütfen sistem günlüğünü burada bulabilirsiniz .

Ayrıca çıktı dahildir dmesg | grep tty > /tmp/dmesg.tty.txt. Ancak dosyanın başlangıcındaki bu dört satırı görüyor musunuz?

Güncelleme 12 - 10 Aralık 2015

1. Satırındaki 4 ( SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end") satırını yorumladı /lib/udev/rules.d/77-mm-zte-port-types.rules.

2. Makinemi yeniden başlattım. Yumuşak kabloyu çıkarıp modemi taktı.

3. Bağlanmaya çalıştı. Başarısız.

Sistem günlüğü dosyası burada .

Güncelleme 13 - 10 Aralık 2015

Çaresizlikten, bazı yerel değişikliklerin bağlantıyı etkileyip etkilemediğini görmek için makineyi Ubuntu 15.04 ve 15.10 DVD'lerle test etti.

1. Makineyi Xubuntu 15.04 64 bit DVD ile başlattı. Bağlantı bir cazibe gibi başarılı oldu.
2. Ubuntu 15.10 64 bit DVD ile makineyi başlattım. Bağlantı eskisi gibi başarısız oldu.

15.04 ve 15.10 arasında ne oldu?

Çok sinir bozucu.

Güncelleme 14 - 10 Aralık 2015

1. Yanıtta belirtildiği /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesgibi yeni bir dosya oluşturuldu .

2. Makinemi yeniden başlattım (veya idam edildi sudo udevadm control --reload, aslında her ikisini de denedi). Modemi taktı.

3. Modem tanındı.

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

4. Yumuşak kabloyu çıkardı ve modemi kullanarak bağlanmaya çalıştı. Başarısız.

5. Modemi çıkarttı.

Makine bir kez takılıyor, bu rastgele bir olay mı? Makinem genellikle yılda bir kez takılmaz.

Sistem günlüğü dosyası ve oluşturulan kural dosyaları burada .

Güncelleme 15 - 11 Aralık 2015

1. İçin aşağıdaki satırlar eklendi /lib/udev/rules.d/40-usb_modeswitch.rules.

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

2. Dosyayı olduğu gibi /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesbıraktı.

3. Makinemi yeniden başlattım. Modemi taktı.

4. Modem tanındı.

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

5. Yumuşak kabloyu çıkardı ve bağlanmaya çalıştı. Başarısız.

6. Modemi çıkarttı.

7. Kaldırıldı /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules.

8. Tüm işlemi yeniden başlattı ve denedi. Yine başarısız oldu.

Syslog dosyası (tam, önemli bir parçayı eksik risk almadım) ve belirtilen kural dosyası (40) burada .

Güncelleme 16 - 11 Aralık 2015

1. Yalnızca bir 1232 kuralı bıraktı /lib/udev/rules.d/40-usb_modeswitch.rules, diğeri kaldırıldı.

2. Yürütüldü sudo udevadm control --reload.

3. Modemi taktı.

4. Modem tanındı.

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

5. Yumuşak kabloyu çıkardı ve bağlanmaya çalıştı. Başarısız.

6. Modemi çıkarttı.

Ancak yukarıdaki varsayılan sistemi test etmedik mi? /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesYerinde mi bırakmak istedin ?

Syslog dosyası (tamamlandı, önemli bir parçayı eksik risk almadım) ve belirtilen kural dosyası (40) burada

Güncelleme 17 - 11 Aralık 2015

1. 1232 kuralını yorumladı /lib/udev/rules.d/40-usb_modeswitch.rules, 2003 için bir kural ekledi.

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

2. Yürütüldü sudo udevadm control --reload.

3. Modemi taktı.

4. Modem 1232 cihazı olarak tanındı . Bağlantı kurmayı denemiyorum (bilgime göre, geçiş 2003'e geçmedikçe geniş bant ağına kaydedilmeyecek)

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

5. Modemi çıkarttı.

Sistem günlüğü dosyası ve belirtilen kural dosyası (40) burada

Güncelleme 18 - 11 Aralık 2015

1. Tüm kural dosyalarını orijinal hallerine yerleştirin.

2. lsusbBir kabuk komut dosyası kullanarak çıktıyı her saniyede izledi . Zaman damgalı dosyalarda yakalanan çıktı.

3. Modemi taktı. (Modem önce dosyada görünür lssuboutouput.Fri Dec 11 16:56:29 BDT 2015.txt). Yakalamalardan bulabildiğimiz gibi, 1232 cihazdan 2003 cihazına geçtiği açıktır.

4. Bağlanmaya çalıştı. Başarısız.

5. Modemi çıkarttı.

Sistem günlüğü dosyası, zaman damgalı lsusbçıktılar ve belirtilen kural dosyaları burada .

Şimdi, sistem günlüğü çıktılarını zaman damgalarıyla eşleştirmek isteyebilirsiniz.

Güncelleme 19 - 11 Aralık 2015

Sorunları izole edebilmek dileğiyle bu testi tamamıyla yeni bir yönde gerçekleştirdim.

1. Taşınabilir bir ortama kaydedilir /lib/udev/rules.d/40-usb-media-players.rulesve /lib/udev/rules.d/77-mm-zte-port-types.rules(Ubuntu 15.10 makinesinden).

2. Xubuntu 15.04 64 bit DVD kullanarak makineyi başlattı.

3. Yürütüldü diff 77-mm-zte-port-types.rules /lib/udev/rules.d/77-mm-zte-port-types.rules > diff15.10and15.04_77-mm.txt. İlk dosya 15.10'dan kaydedilen dosyaya aittir.

   Diff dosyasının incelenmesi idProduct1232 veya 2003'ü göstermez.

4. Yürütüldü diff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules > diff15.10and15.04_40-usb.txt. Yine, ilk dosya 15.10'dan kaydedilen dosyadan.

   Yine, diff dosyasının incelenmesi idProduct1232 veya 2003'ü göstermez.

5. Modemi taktı. Modem modem olarak tanındı.

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

6. Bir mobil geniş bant bağlantısı kurduktan sonra kolayca bağlanabilir.

7. Modemi çıkarttı.

8. En son USB_ModeSwitch'i yükledi.

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

   Şimdi beklendiği gibi NULL döndürüyor.

9. Yürütüldü sudo udevadm control --reload-rules.

10. Modemi taktı. Modem modem olarak tanındı.

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

11. Kolayca bağlanabilir.

MM ve NM'yi sadece nerede bozulduğunu görmek için Ubuntu 15.10'a yükseltmeyi deneyebilirdim. Aslında denedim ama sonsuz bağımlılık sorunları nedeniyle vazgeçtim.

Yukarıda belirtilen fark dosyaları burada .

Güncelleme 20 - 12 Aralık 2015

Test 1

1. /lib/udev/rulesOrijinal durumda.

2. Modem cihazı henüz bu oturuma yerleştirilmedi.

3. Hata ayıklama için ModemManager'ı kurun ve udevadm yakalamayı ayarlayın.

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

4. Modemi takıp geniş bant ağa kayıtlı olduğunu söyleyene kadar bekledi.

5. Başarısız bir şekilde bağlanmaya çalıştı.

6. Modemi çıkarttı.

7. Günlük dosyaları paketlendi.

Test 2

Yukarıdaki testi /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesyerinde tekrarlayın .

Günlük dosyası adları kendiliğinden açıklayıcıdır.

Yukarıdaki tüm günlük dosyaları artı syslog ve 78 kural dosyaları burada .

Keşke tüm günlük dosyaları zaman damgaları ile geldi, eşleştirme kolaylaştırır.

Güncelleme 21 - 15 Aralık 2015

1. Kural dosyasını önerildiği gibi değiştirdi.
2. Makinemi yeniden başlattım.
3. Modemi taktı ve bağlanmaya çalıştı. İşe yaramadı.

Kural dosyası ve syslogvardır burada .

Güncelleme 22 - 16 Aralık 2015

Bir yorumda önerildiği gibi, http://kernel.ubuntu.com/~kernel-ppa/mainline/ adresinden çeşitli çekirdekler yükledi ve her birinde önyükleme yaptıktan sonra modemi kullanarak bağlanmayı denedi.

1. 4.2.8-040208-jenerik, hata.

2. 4.1.15-040115-jenerik, hata.

3. 4.0.9-040009-jenerik, hata.

Yani, belki, çekirdek sorununu ekarte edebiliriz.

Güncelleme 23 - 16 Şubat 2016

Modem Ubuntu 16.04'te çalışmaya başladı. Bu sürüm hala Alpha 1'de, ancak dizüstü bilgisayarımda iyi çalışıyor.

ofonoPaketin yüklenmesi muhtemelen iyi oldu, ancak görünüşe göre modem modeliniz ZTE MF193E, ZTE listesinde değil. MF190J gibi diğer ZTE modemleriyle karşılaştırıldığında, bu modemin dongle takıldığında udevçalışması için aynı özel kurala ihtiyacı vardır ve usb_modeswitchbunun için root olarak udevdosyaya
/lib/udev/rules.d/40-usb_modeswitch.rules
aşağıdaki iki ile yeni bir kural ekleyebilirsiniz. satırlar, örneğin, # ZTE MF190Jyorumun yakınındaki bir yerde :

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

artı boş bir çizgi, bu yüzden göze hoş görünüyor.

Bundan sonra yeniden başlatmak muhtemelen akıllıca olur, sadece sihir gibi çalışır :-)

Ya da değil. Bildiğiniz gibi, bu benim için derin su, ama yine de işe yaramazsa, başka bir vahşi tahmin için başka bir ModemManager hata ayıklama günlüğüne ihtiyaç duyulacaktı.

DÜZENLE:

Şimdi modemmanager.txt dosyasındaki iki satıra bakıyorum:

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

ve

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

Sanırım ilk "geniş bant kurulum", ikincisi "PDP bağlamı" (ne olursa olsun) iç bağlama ifade ederken. Görünüşe göre, modem 9 alternatif bağlam sunuyor, bunlardan biri de dahil olmak üzere apn='WAP', ancak ModemManagerbüyük / küçük harf duyarsız bir eşleşme için yerleşiyor.

Büyük / küçük harf farkı, sonraki sorunun nedeni olabilir: örneğin, ppp 'wap'(daha ziyade 'WAP') bir yapılandırma ister ve bulamaz veya uzak uç bekler apn='WAP', ancak boğulduğu 'wap' alır.

İlk seçenek, yapılandırmanızı 'WAP' yerine 'wap' kullanacak şekilde değiştirerek kolayca test edilebilir (ve muhtemelen dışlanabilir). Bunu daha önce denemiş olabilirsiniz, ancak o sırada ofonopaket olmadan , ikinci seçenek daha olası olsa da, başka bir test zarar görmez.

Modemden temin edilebilen büyük harfli "PDP bağlamı" eşleşmesi olduğu için ikinci seçenek de bir sorundur. Bu sorunu inceleyerek, büyük / küçük harfe duyarlı olmayan eşleşmenin "görünüşte alakalı)" 3GPP TS 23.003 bölüm 9.1 "spesifikasyonu ile doğru olduğu ve ModemManagergeçen yıl Kasım ayında (mm-1-4 sürümüne, Ben toplayabilirim). Bu durumda, modeminize söylenmedi ve büyük / küçük harfe duyarlı eşleştirme beklerken, ModemManagermaalesef büyük / küçük harf duyarlı değil, büyük / küçük harfe duyarlı değil.

İkinci soruna yönelik çözümlerden biri elbette farklı bir yöntem kullanmaktır ModemManager: ya bu yamadan önce bir sürüm bulup kurarak ya da (yeterli boş zamanla) kendinizinkini yapın ModemManager. Ama hiçbiri bir kapriste yapılacak bir şey değil, bu yüzden belki de (şimdi) sorunun olduğuna dair daha fazla kanıt elde etmek için biraz göz atmalıyız ve mümkünse etrafta çalışmak için başka yollar bulmalıyız. Ya da biraz şansla, bir şeyler bilen biri ...

DÜZENLEME 2

Evet, bağımlılıklar nedeniyle sürüm geri alma işlemi kolay değildir. Kendinizinkini yuvarlamak da bir sevinçten uzak.

İki olası yararlı araç: komut mmclive ( http://m2msupport.net/m2msupport/module-tester/ ).

Bence sorun ModemManager'ın PDP bağlamı 1'i apn = 'wap' ile seçmesidir, burada PDP bağlamı 9'u apn = 'WAP' ile seçmelidir. Belki de bu araçlardan biri kullanılarak ele alınabilir. Ya bağlantı sırasında 9 seçimini zorlayabilmek için ya da modül-test cihazı aracının yapabileceği ilan edilen modemden 'wap' bağlamlarını silerek.

Modem test cihazı aracı tarayıcıda bir java aracı gibi görünüyor, bu yüzden java'nızın nerede olduğunu bilmek için tarayıcınızın ayarlanmış olması ve bilinmesi için bu java'ya ihtiyacınız var. O zaman lütfen bu yaklaşımı keşfedin; Kendim kullanmadım, ancak ekran görüntülerini gördüğümde, PDP bağlamlarını 'Veri Çağrıları' sekmesi olarak sunacağını tahmin ediyorum, burada her şeyi ilk kez not aldınız ve ardından 'wap' girişlerini 'wap1' ve 'wap2' olmak için 'wap' apn etiketlerini deforme edin ('WAP' ararken onları "gizlemek" için). Sonra kaydedin ve kapatın ve dongle'ı tekrar oynatın. Bir günlük tut; hala oynamayı reddetmesi durumunda syslog yeterli görünüyor.

mmcliKomut ayrıca bu hikayede kullanışlı görünüyor; do man mmclibu konuda okumak için, ama orada PDP içeriklerinin hakkında bir şey görmedik.

DÜZENLEME 3

İyi karar! DVD denemek için. Bu bize APN ile yanlış yolda olduğumu ve her şeyin ppp'nin ortaya çıkmasında yatıyor olduğunu söyledi. En azından havlayacağım yeni ağaç bu olurdu.

Öncelikle, pppd için bir sürüm farkı olduğunu (2.4.5'ten 2.4.6'ya) not ediyoruz, ancak muhtemelen bir sorun değil, çünkü bir dongle üzerindeki herkes bu geziye çıkacaktı.

Hmm, ppp; Son binyıl hatıralarımı karıştırmam gerek :-). Ne yazık ki bugün meşgulüm, ama bir sonraki zamanım olduğunda üsse dokunacağım, ne kadar uzağa geldiğini görmek için. Bakacağım ilk arka sokaklarım: 1) doğru gruptaki kullanıcı mı? 2) kimlik bilgileri doğru mu? 3) ppp / chat konfigürasyonları dosya modu doğru mu? Ppp hata ayıklama günlüğü nm.txt içinde (birkaç gün önce olduğu gibi) çıkıyor, ancak daha ayrıntılı günlük kaydı istemenin de bir yolu olmalı.

DÜZENLEME 4

Grubu ( gerektiği gibi kullanarak ) ve modu (veya ) ( gerektiği gibi kullanarak) sağlayın /etc/ppp/pap-secretsve bulundurun . Benimki olmadı./etc/ppp/chap-secretsdipchgrp740-rw-r-----chmod

EDIT 5

Peki bu ağaç hakkında: Çalışan wvdialsistem günlüğünü çalışmayan sistem günlüğü ile karşılaştırdığımızda, bazı nedenlerden dolayı wvdialçalışmamaya ttyUSB3devam ederken ModemManagerkullanılır ttyUSB1. Hiç önemli olup olmadığından emin değilim, ama görünüşe göre ttyUSB1ve ttyUSB3her ikisi de AT özellikli modemler olarak yanıt veriyor .

Bu nedenle, bir test olarak, /etc/wvdial.confaltında [Dialer Defaults]aşağıdaki satırı içerecek şekilde düzenleyebilirsiniz :

Modem = /dev/ttyUSB1

bir test için ve bir ttyUSB3diğeri için; her ikisi de kök olarak çalışır; sadece farklı bir davranış olup olmadığını görmek için. Özellikle, ttyUSB1ttyUSB3 kullanmanın kullanılmaması bir sorunsa, ModemManager'ın ttyUSB3'ü nasıl kullanacağını araştırmak iyi olur. Diğer test sonuçları için, ppp ülkesindeki gelincikleri kovalamaya geri döneceğimizi söyleyebilirim.

DÜZENLEME 6

Dmesg günlüğü göz ardı edilebilir sanırım; tüm günlüklerde böyle oldu. Yeni syslog sadece ttyUSB3 testini gösterir, ancak belki de NetworkManagerttyUSB3'ü kullanmayı ve ttyUSB1'i (bu modem için) görmezden gelebilirsek hayatın daha iyi olduğunu varsayabiliriz .

Ben de ( https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/819784 ) buldum özellikle 10 numaralı sonrası rahatsız edici :-(

Görünüşte uygulanabilir olan udevkural /lib/udev/rules.d/77-mm-zte-port-types.rulesgeçerli değildir, ancak sözde nereye gidileceği söz konusudur. Ve, sadece udevsihirle ilgili 101 öncesi bir öngörü ile, her nasılsa, 4. çizgisini sorgulamayı düşünürdüm, ki bu:

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

Bence bu #yorum için bir baş harfe ihtiyaç var . Ayrıntılı olarak, dosyayı okumam, "2003" ürün kuralları da dahil olmak üzere iyi bitleri kullanmak ve en azından test etmek için SUBSYSTEM == "tty" ve SUBSYSTEMS = "usb" çağırma durumunu gerektirmesidir. "tty" filtresini atlamak güvenli olmalıdır. Ve şimdi daha iyi bir şeyim yok.

DÜZENLE 7

Favori arama motorumla kaliteli zaman geçirdikten sonra, ttyUSB seçiminin burada kök bir sorun olduğuna biraz daha inanıyorum. İşaret ettiğim udev kuralı tamam ve bu düzenlemeyi geri almalısınız.

Ancak, "2003" ürün kimliği için bu dosyanın sonuna doğru yapılandırma kurallarının yanıltıcı olduğuna inanmaya başladım. Günlüklerden bana öyle geliyor ki, bu ürün kimliği "2003" aslında donanım kilidinin bellek aygıtı tarafıdır, oysa modem tarafında "1232" ürün kimliği vardır. "1232" ürün kimliği için iki "2003" kuralını dosyada çoğaltarak bunu sınayabilirsiniz./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"

veya daha iyisi, örneğin adında yeni bir dosya ekleyin 78-ralph.rules, ancak bunun yanında SUBSYSTEM ve SUBSYSTEMS korumasını da eklemeniz gerekir.

Ardından, donanım kilidini çekin, çalıştırın udevadm control --reload(veya yeniden başlatın) ve donanım kilidini takın. Ve sonra syslogşimdi işe yaramazsa, başka bir yakalama.

Bununla birlikte, etkin sorun ModemManager'ın libmm-plugin-zte.soön problamada eklentiyi atması ve genel bir modem işleyicisi kullanarak bitmesi. Ürün kimliği konusunda haklıysam bunun nedeni olabilir; ön-problama bir ID_MM_ZTE_PORT_TYPE_MODEMilişkilendirme arar ve bu, "1232" (yamadan önce) ürün kimliği için eksiktir, zte eklentisinin atıldığı etki.

DÜZENLE 8

syslogGünlük biraz kısa olduğu; ModemManager'ın zte eklentisini yükleyemediği başlangıcı eksik. Ancak, Generic modem eklentisinin her şekilde kullanıldığı açıktır. Şimdi usb_modeswitchsize erken verdiğim kural yanlış da olabilir; Bu geçişi karar için bunu açık düşündüğünde "2003" dan "2003". Ama, man usb_modeswitch(daha önce baktım olmalıdır) çeşit o kaydırır düşündürmektedir için bir ürün kimliği yerine gelen o. Her durumda, günlük bunun olduğunu gösterir. Bu nedenle, lütfen bunun yerine "1232" kullanmak için bu kuralı değiştirin ve tekrar deneyin.

Başka bir şey yoksa, en azından udev hakkında biraz öğrenmem gerekiyor.

DÜZENLE 9

İyi. Sorun hala (veya ayrıca) ModemManager'ın ön problamada ZTE eklentisini düşürmesidir. ModemManager hata ayıklama günlükleri 15.10 (günlük kümeleri "hata ayıklamaları *"), ZTE eklentisinin satıcı kimliği / ürün kimliği testi nedeniyle atıldığını anlatır.

Kaynağa git, Luke! ModemManager kaynak kodunu kısaca görmek için bu fırsatı aldım ve 19d2 / 2003 içermeyen bir vid / pid tablosu olarak eklentinin ... olsa da, bu tablo kaynağını bulamadım, bu yüzden yapamadım Doğrulama.

Ya da belki burada bir zamanlama sorunu var. Örneğin, cihaz 19d2 / 1232 iken ModemManager'ın ön problama çalıştırması. Bu düşünce, 78 mm-zte-port-type-RALPH.rules udev kurallarına sahip olmanın ModemManager'ı cihazla biraz daha mutlu ettiği gözlemiyle uyumludur. Ancak, cihaz 19d2 / 2003'e geçtiğinde neden bu eklentiden memnun kalmıyor?

Belki daha fazla günlük gerekir :-) ModemManager hata ayıklanmış ve ayrıca udevadm monitor --e |& tee udevadm.logcihazı taktığınızda komutun (başka bir terminalde) yakalanması ile . Bu komutu ( https://wiki.ubuntu.com/DebuggingUdev ) adresinden aldım

Bunu iki kez yapın: 78-mm-zte-port-types-RALPH.ruleskurallar olmadan bir kez ve bir kez ... iki kez yeni bir yeniden başlatmadan. yani

1. Kurulum /lib/udev/rules.dolan veya olmayan *-RALPH.rulesdosyasında
2. cihazı çıkar
3. reboot
4. hata ayıklama ve kurulum udevadm yakalama için ModemManager kurulumu
5. cihazı takın ve bir dakika bekleyin
6. günlük dosyalarını topla
7. sonraki testle 1'den tekrarla

Bu günlük kaydı ZTE eklentisinin nereye bırakıldığını söylemeli ve anladığım kadarıyla udev olay işlemeyi de anlatacak.

EDIT 10

(Neredeyse burada bağlantımın sonuna geldim, ama bir veya iki nefesim daha kaldı :-)

İlk olarak, tüm udevsüslemeler gerektiği gibi bitiyor gibi görünüyor, birkaç özellikte sadece birkaç soru işareti. Özellikle 78-*-RALPH.rulesatılmalı; yararlı değil.

Sanırım bundan bir şey okuyabilirim, ama tam olarak nasıl düzeltilmesi gerektiğinden emin değilim. Temel olarak, gördüğüm gibi, dongle takıldığında udev olaylarının bir telaşı var. TtyUSB1 ile ilgili olanlara odaklanan bir "erken" olay vardır:

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

bu da usb_serialsürücünün yüklenmesine ve /dev/ttyUSB1görünmesine neden olur . Bu özellikle başka bir olaya neden olur:

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

Bunun da tetiklediğini düşünüyorum ModemManager. Bunun syslogkanıtlarını görmek için gitmelisiniz , çünkü günlükler arasında sıkı bir korelasyon yoktur. Olay zaman damgalı 3867.435102ve çekirdek günlük satırının damgalanmasından hemen sonra syslogen yakın sonraki ModemManagergünlük satırını gösterir 3867.437412.

Benim düşünceme göre, ModemManagerhenüz tetiklenmemeli, ancak sonraki ttyUSB1 olayından sonra:

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

ZTE özelliklerini ekledi.

MM günlüğünde, 1449934745.363291"çekirdek zaman" damgası yerine "gerçek zamanlı" zaman damgası olan damgalı satırda olurduk .

ModemManagerdaha 1449934745.450398sonra, çekirdek zaman açısından 3867.524519yukarıdaki "iyi" UDEV olay raporuna yakın ve 55 ms önce olacak şekilde, yani 87 ms sonra ön araştırma ile yapılır .

Not o syslog, ModemManagerşikayetlerini dile yapar ttyUSB1şikayet "işaretleme" oluyor ilgilidir belki bu onun niteliklerini ayarlamak var ve yok 80-mm-candidate.rules. Bu dosyadaki yorumla, bu işaretleme tam olarak bu sorunla başa çıkmak için bir girişim gibi görünüyor, ancak öyleyse, bu durumda işe yaramaz gibi görünüyor.

Belki bunu çözmenin bir yolu, "tty" kuralını şu şekilde değiştirmek 80-mm-candidate.rulesolabilir:

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

Zihnimde, bu ID_MM_CANDIDATE, ZTE özellikleri ayarlanana kadar ayarın ertelenmesini sağlayacaktır. .ID_PORTAyar bir etkidir 60-serial.rules(denilen kural 60-persistent-serial.rulesöncesi) ve işaretleme kurala eklenen koşulu bir değere sahip olduğunu basitçe.

Koşul, tam olarak bir ZTE özniteliği değil, yalnızca kuralı daha genel tutmak için. Bunun yerine bir adım daha spesifik olmak ENV{.MM_USBIFNUM}="?*"yerine, bu atama gerçekleştiğinden daha çok gerekli olacaktır 77-mm-zte-port-types.rules.

Genel olarak udevkural sıralamasından pek emin değilim ve bunun ModemManagerçok hızlı bir şekilde hareket etmeyi bıraktığından da emin değilim . Ancak, bu olmazsa, 80-mm-candidate.rulesçok az işleve sahip ya da hiç işlevi olmayacaktı ve belki de o zaman hepsi ModemManager15.04'ten "iyileştirmelere" inecektir .

DÜZENLEME 21

iç çekmek. Muhtemelen alakasız, ancak 7-zte-mutil_port_device.rulesdosyanızı kontrol etmek isteyebilirsiniz ; bu diğer deneylerden bir kalıntı mı? Her neyse, burada alakalı değil.

Arasında neredeyse ikinci bir hala var 515.558184ve 516.381549nerede ModemManagerhevesle ve yanlışlıkla kapmak /dev/ttyUSB1ve kurmak hala ön sondalama ve atar ZTE eklenti geçer olmamak şikayet ederken. Başka bir deyişle, kural yaması ModemManagerbekleme yapmaz .

Sanırım ENV{.MM_USBIFNUM}="?*"bunun yerine kullanarak test ettiniz ENV{.ID_PORT}=="?*".

Aslında, ayarın ENV{ID_MM_CANDIDATE}=1herhangi bir önemi olup olmadığını doğrulamak için , geçici olarak uzaklaşmalı 80-mm-candidate.rules, syslogsonra ModemManageryoksayarsa ( görmezden gelmeli ) bakın /dev/ttyUSB1. Ben "değil" şüpheli.

Ve sonra, belki de 14.04 gibi çalışan bir sürümü kullanabilirsiniz ve eğer ihtiyacınız varsa, sanal kutuda belki de 15.10'u çalıştırın, tabii ki hepsi zaten bir sanal kutuda değilse.

Sanırım bu noktada yenilgi talep etmeliyim.

Modem Ubuntu 16.04'te çalışmaya başladı. Bu sürüm hala geliştirme aşamasında, ancak dizüstü bilgisayarımda iyi çalışıyor.

Keşke nasıl çalışmaya başladığı hakkında daha fazla teknik ayrıntı verebilseydim.

Buna bir göz attıktan sonra, bu ejderha ilk kez düzgün bir şekilde ele alınmamış gibi görünüyor. 12.10 ve 13.04'te daha önce bir hataydı, belki de hata asla düzeltilmedi veya yeni bir yama daha önce doğru çalışan bir şeyi kırdı.

Umarım, teknik spesifikasyonlarınızı doğru bir şekilde okuyorsam, sizi bu yöne (MF190J) yönlendirmeliyim:

3G modem (ZTE MF190J) yine de manuel ayar gerektirir.

Bunu denedin mi:

 rfkill list up

ve sonra bu komut dosyasını hazırlayın ve çalıştırın:

 #/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

ve bu şekilde işe yarayabilir.