Błąd „ip-config-niedostępny”, gdy modem USB próbuje się połączyć

Mam modem ZTE MF-193E, który wcześniej działał dobrze. Kiedy ponad rok temu kupiłem ten modem, zadziałał bez problemu. Teraz, gdy Ubuntu rozwija się w wersji, sprawy stają się dla mnie coraz trudniejsze.

Ten modem działał nawet kilka miesięcy temu z Ubuntu 15.04 (64-bit). Teraz w Ubuntu 15.10 (64-bit) nie może się połączyć.

Mam założyć mobilnego połączenia szerokopasmowego . Próbowałem różnych ciągów APN, ale nie było to wcześniej problemem.

(Modem działa dobrze w systemie Windows 10, więc nie jest to wcale problem sprzętowy. Ponadto interfejs GUI Modem Manager ładnie wykrywa to urządzenie. SMS-y można wysyłać i odbierać bez problemu.)

Po włożeniu modemu wykrywa się dobrze, w Unity wyświetlana jest ikona dysku CD z nazwą modemu. Kilka sekund później dostaję komunikat

Mobile Broadband Network: you are registered on the home network

w pobliżu ikony sieci.

Kiedy próbuję się połączyć, ikona sieci bezprzewodowej w aplecie menedżera sieci uruchamia te ruchy odśrodkowe, ale w końcu nie można się połączyć, a komunikat mówi mi, że jestem offline.

Linia, od której mogłabym się oddzielić, /var/log/syslogto:

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

Nie jestem jednak pewien, czy to jest właściwe.

Więcej linii z /var/log/syslogmożna znaleźć tutaj .

Aktualizacja 1 - 06 grudnia 2015 r

Jak zauważył jeden miły członek, wypróbowałem nf_conntrack_pptppodejście modułowe.

Wykonano następujące polecenia,

$ 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

Potem wypróbowałem mój modem, ta sama awaria. Brak widocznych zmian w dzienniku.

Aktualizacja 2 - 06 grudnia 2015 r

Wykonany jako root,

systemctl restart network-manager.service

Brak wyjścia na ekranie (terminal).

Odpowiedni dziennik z powyższego punktu do próby połączenia za pomocą modemu można znaleźć tutaj .

Aktualizacja 3 - 06 grudnia 2015 r

Zainstalowałem, ofonoa następnie spróbowałem ponownie modem.

Proszę zobaczyć dziennik tutaj .

Aktualizacja 4 - 06 grudnia 2015 r

Ponownie wykonany jako root,

systemctl restart network-manager.service

Odpowiedni dziennik z powyższego punktu do próby połączenia za pomocą modemu można znaleźć tutaj .

Aktualizacja 5 - 06 grudnia 2015 r

Zmieniono wszystkie „odmawiaj” na „zezwalaj” na /etc/dbus-1/system.d/nm-dispatcher.conf.

Próbowałem połączyć. Brak szczęścia.

Kilka sieci łączy się i rozłącza za pomocą połączenia Ethernet.

Następuje sudo systemctl restart network-manager.service.

Podłącz modem i podłącz.

Próbowałem połączyć się ponownie. Nie łączy się

Dziennik jest tutaj .

Aktualizacja 6 - 06 grudnia 2015 r

Wykonany

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

i

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

Nie można uruchomić z mm-test.pypowodu wielu błędów. Znaleziono plik we wskazanej lokalizacji. Dostałem to od https://github.com/openshine/ModemManager/blob/master/test/mm-test.py .

Powyższe polecenia różnią się nieco od poleceń na Wiki.

Pliki dziennika są tutaj .

Aktualizacja 7 - 07 grudnia 2015 r

Wykonane ponownie (po sugerowanej zmianie /lib/udev/rules.d/40-usb_modeswitch.rulesi ponownym uruchomieniu)

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

i

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

To /var/log/syslogjest również włączone.

Pliki dziennika są tutaj .

Aktualizacja 8 - 08 grudnia 2015 r

Zaktualizowany zestaw dzienników jest tutaj .

Aktualizacja 9 - 08 grudnia 2015 r

Test 1

1. Tym razem uruchomiłem komputer z 32-bitowego DVD Ubuntu 14.04. Gdy tylko komputer się uruchomił, zaczął rejestrować dziennik MM.

2. Wstawiono modem. lsusbpokazał, że jest rozpoznawany jako urządzenie 19d2: 1232, które należy podłączyć do urządzenia 19d2: 2003. Ponieważ instalacja przełącznika trybu USB wymaga ponownego uruchomienia komputera (a co za tym idzie utraty instalacji do uruchomienia DVD), przygotowałem niestandardowy plik przełącznika i przełączyłem modem z wiersza poleceń ( sudo usb_modeswitch -I -c 19d2:2003).

3. Jak tylko przełączenie zostało zakończone, zostałem poinformowany, że jestem włączony, Mobile Broadband Networka nowe połączenie szerokopasmowe zostało uznane w menu menedżera sieci.

4. Powyższe połączenie skonfigurowałem w zwykły sposób (nazwa APN nie stanowiła problemu), a połączenie zostało nawiązane automatycznie.

5. Odłączyłem i wysunąłem modem.

6. Zatrzymano przechwytywanie dziennika MM.

Pełny dziennik MM i syslog dla sesji rozpoczynającej wysuwanie modemu można znaleźć tutaj .

Test 2

Ten sam test z 64-bitowym DVD Ubuntu 14.04.

Dzienniki można znaleźć tutaj .

Aktualizacja 10 - 09 grudnia 2015 r

Tym razem przetestowaliśmy wvdiali stwierdziliśmy, że jeśli wvdialzostanie uruchomiony jako root, otrzymamy udane połączenie.

wvdialConf i dziennika, a odpowiadająca syslog są tutaj

Podstawowa hipoteza: sytuacja może mieć coś wspólnego z grupą użytkowników odpowiedniego użytkownika.

Ale jak wskazano tutaj ,

Przy użyciu wszystkich tych narzędzi, aby ustanowić połączenie telefoniczne, użytkownik musi należeć do grup „dip” i „dialout”, więc umieść w tych grupach wszystkich użytkowników, którzy powinni łączyć się za pośrednictwem dialupu.

Ale jak możemy znaleźć,

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

Tak więc użytkownik jest już członkiem wskazanych grup.

Być może problem sprowadza się do jednego z tych punktów,

1. Jaką dodatkową grupą musi być użytkownik?
2. Jak przeprowadzamy proces konfiguracji mobilnego połączenia szerokopasmowego jako root? (Problemy z bezpieczeństwem?)

Aktualizacja 11 - 09 grudnia 2015 r

wvdialwspółpracuje z USB3 i nie działa z USB1.

Proszę znaleźć syslog tutaj .

Uwzględniono również dane wyjściowe dmesg | grep tty > /tmp/dmesg.tty.txt. Ale widzisz te cztery wiersze w pobliżu początku pliku?

Aktualizacja 12 - 10 grudnia 2015 r

1. Skomentował wiersz 4 ( SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end") w /lib/udev/rules.d/77-mm-zte-port-types.rules.

2. Uruchomiłem ponownie maszynę. Soft odłączył kabel i włożył modem.

3. Próbowałem się połączyć. Nieudany.

Plik syslog jest tutaj .

Aktualizacja 13 - 10 grudnia 2015 r

Z czystej desperacji, aby sprawdzić, czy jakieś lokalne zmiany wpływają na połączenie, przetestowałem maszynę z DVD Ubuntu 15.04 i 15.10.

1. Uruchomiłem maszynę z 64-bitową płytą DVD Xubuntu 15.04. Połączenie zakończyło się powodzeniem jak urok.
2. Uruchomiłem maszynę z 64-bitowym DVD Ubuntu 15.10. Połączenie nie powiodło się tak jak wcześniej.

Co się stało między 15.04 a 15.10?

Bardzo frustrujące.

Aktualizacja 14 - 10 grudnia 2015 r

1. Utworzono nowy plik /lib/udev/rules.d/78-mm-zte-port-types-RALPH.ruleszgodnie z instrukcją w odpowiedzi.

2. Uruchomiłem ponownie maszynę (lub wykonałem sudo udevadm control --reload, faktycznie wypróbowałem oba). Wstawiono modem.

3. Modem został rozpoznany.

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

4. Soft odłączył kabel i próbował połączyć się za pomocą modemu. Nieudany.

5. Wyrzucił modem.

Maszyna zawiesza się raz, czy to przypadkowe zdarzenie? Moja maszyna zwykle nie zawiesza się raz w roku.

Plik syslog i utworzone pliki reguł są tutaj .

Aktualizacja 15 - 11 grudnia 2015 r

1. Dodano następujące linie do /lib/udev/rules.d/40-usb_modeswitch.rules.

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

2. Pozostawił plik /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesnienaruszony.

3. Uruchomiłem ponownie maszynę. Wstawiono modem.

4. Modem został rozpoznany.

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

5. Soft odłączył kabel i próbował się połączyć. Nieudany.

6. Wyrzucił modem.

7. Usunięte /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules.

8. Uruchomiono ponownie i ponownie przetestowałem cały proces. Ponownie nieudane.

Plik syslog (kompletny, nie zaryzykowałem utraty ważnej części) i wspomniany plik reguł (40) są tutaj .

Aktualizacja 16 - 11 grudnia 2015 r

1. Pozostawiono tylko jedną regułę 1232 /lib/udev/rules.d/40-usb_modeswitch.rules, usunięto drugą.

2. Stracony sudo udevadm control --reload.

3. Wstawiono modem.

4. Modem został rozpoznany.

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

5. Soft odłączył kabel i próbował się połączyć. Nieudany.

6. Wyrzucił modem.

Ale czy nie testowaliśmy domyślnego systemu powyżej? Czy chciałeś odejść /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesna swoje miejsce?

Plik syslog (kompletny, nie ryzykowałem pominięcia żadnej ważnej części) i wspomniany plik reguł (40) są tutaj

Aktualizacja 17 - 11 grudnia 2015 r

1. Skomentował regułę 1232 /lib/udev/rules.d/40-usb_modeswitch.rules, dodał jedną dla 2003 roku.

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

2. Stracony sudo udevadm control --reload.

3. Wstawiono modem.

4. Modem został rozpoznany jako urządzenie 1232 . Nie zaproponowano mi próby połączenia (o ile mi wiadomo, nie zostanie zarejestrowana w sieci szerokopasmowej, chyba że nastąpi przełączenie do 2003 r.)

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

5. Wyrzucił modem.

Plik syslog i wspomniany plik reguł (40) są tutaj

Aktualizacja 18 - 11 grudnia 2015 r

1. Umieść wszystkie pliki reguł w ich oryginalnej formie.

2. Obserwowałem lsusbwyjście co sekundę przy użyciu skryptu powłoki. Przechwycone dane wyjściowe w plikach ze znacznikiem czasu.

3. Wstawiono modem. (Modem pojawia się po raz pierwszy w pliku lssuboutouput.Fri Dec 11 16:56:29 BDT 2015.txt). Jak widać z przechwytywania, jasne jest, że przełącza się z urządzenia 1232 na urządzenie z 2003 roku.

4. Próbowałem się połączyć. Nieudany.

5. Wyrzucił modem.

Plik syslog, lsusbwyjścia ze znacznikiem czasu i wspomniane pliki reguł są tutaj .

Teraz możesz dopasować wyniki syslog do znaczników czasu.

Aktualizacja 19 - 11 grudnia 2015 r

Przeprowadziłem ten test w zupełnie nowym kierunku z życzeniem, żebym mógł wyizolować problemy.

1. Zapisane na przenośnym nośniku /lib/udev/rules.d/40-usb-media-players.rulesi /lib/udev/rules.d/77-mm-zte-port-types.rules(z komputera Ubuntu 15.10).

2. Uruchomiono maszynę przy użyciu 64-bitowego DVD Xubuntu 15.04.

3. Stracony diff 77-mm-zte-port-types.rules /lib/udev/rules.d/77-mm-zte-port-types.rules > diff15.10and15.04_77-mm.txt. Pierwszy plik pochodzi z pliku zapisanego od 15.10.

   Analiza pliku diff pokazuje nr idProduct1232 lub 2003.

4. Stracony diff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules > diff15.10and15.04_40-usb.txt. Ponownie pierwszy plik pochodzi z pliku zapisanego od 15.10.

   Ponownie, analiza pliku diff pokazuje nr idProduct1232 lub 2003.

5. Wstawiono modem. Modem został rozpoznany jako modem.

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

6. Można podłączyć łatwo po skonfigurowaniu mobilnego połączenia szerokopasmowego.

7. Wyrzucił modem.

8. Zainstalowano najnowszy USB_ModeSwitch.

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

   Teraz zwraca NULL, zgodnie z oczekiwaniami.

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

10. Wstawiono modem. Modem został rozpoznany jako modem.

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

11. Można łatwo połączyć.

Mógłbym spróbować uaktualnić MM i NM do Ubuntu 15.10, żeby zobaczyć, gdzie się psuje. Próbowałem, ale poddałem się z powodu niekończących się problemów z zależnością.

Wszystkie wyżej wymienione pliki diff są tutaj .

Aktualizacja 20 - 12 grudnia 2015 r

Test 1

1. W /lib/udev/rulesoryginalnym stanie.

2. Modem nie został jeszcze wstawiony w tej sesji.

3. Skonfiguruj ModemManager do debugowania i skonfiguruj przechwytywanie udevadm.

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

4. Podłączyłem modem i czekałem, aż powie, że jest zarejestrowany w sieci szerokopasmowej.

5. Próbowałem połączyć się bez powodzenia.

6. Wyrzucił modem.

7. Spakowane pliki dziennika.

Test 2

Powtórzyłem powyższy test z /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesna miejscu.

Nazwy plików dziennika są oczywiste.

Wszystkie powyższe pliki dziennika plus syslog i 78 plików reguł są tutaj .

Chciałbym, aby wszystkie pliki dziennika były opatrzone znacznikami czasu, co ułatwia dopasowanie.

Aktualizacja 21 - 15 grudnia 2015 r

1. Zmieniono plik reguł zgodnie z sugestią.
2. Uruchomiłem ponownie maszynę.
3. Włóż modem i spróbuj się połączyć. To nie działało.

Plik reguł i syslogsą tutaj .

Aktualizacja 22 - 16 grudnia 2015 r

Jak wskazano w jednym komentarzu, zainstalowałem różne jądra z http://kernel.ubuntu.com/~kernel-ppa/mainline/ i spróbowałem połączyć się za pomocą modemu po uruchomieniu każdego z nich.

1. 4.2.8-040208-ogólny, awaria.

2. 4.1.15-040115-ogólny, awaria.

3. 4.0.9-040009-ogólny, awaria.

Być może więc możemy wykluczyć problem z jądrem.

Aktualizacja 23 - 16 lutego 2016 r

Modem zaczął działać w systemie Ubuntu 16.04. Ta wersja jest nadal w Alpha 1, ale działa dobrze na moim laptopie.

Załadowanie ofonopakietu nie powiodło się, prawdopodobnie, ale najwyraźniej twój model modemu, ZTE MF193E, nie znajduje się na liście ZTE. Porównując go z innymi modemami ZTE, np. MF190J, ten modem będzie prawdopodobnie potrzebował tej samej specjalnej udevreguły, aby działać usb_modeswitchpo włożeniu klucza sprzętowego i aby uzyskać, jako root, możesz dodać nową udevregułę do pliku
/lib/udev/rules.d/40-usb_modeswitch.rules
z następującymi dwoma linie np. gdzieś w pobliżu # ZTE MF190Jkomentarza:

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

plus pusta linia, dzięki czemu wygląda przyjemnie dla oka.

Prawdopodobnie rozsądnie jest zrestartować komputer, aby przekonać się, że wszystko działa jak magia :-)

Albo nie. Jak wiecie, jest to dla mnie głęboka woda, ale jeśli nadal nie działa, potrzebny byłby inny dziennik debugowania ModemManager, na kolejne zgadywanie.

EDYTOWAĆ:

Teraz patrzę na dwie linie w modemmanager.txt:

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

i

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

Domyślam się, że pierwszy odnosi się do konfiguracji szerokopasmowego Internetu, a drugi do wewnętrznego powiązania z „kontekstem PDP” (cokolwiek to jest). Wygląda na to, że modem oferuje 9 alternatywnych kontekstów, w tym jeden z apn='WAP', ale ModemManagerustala dopasowanie bez rozróżniania wielkości liter.

Różnica wielkości liter może być przyczyną kolejnego problemu: np. Ppp chce 'wap'konfiguracji (a nie 'WAP') i jej nie znajduje lub że zdalny koniec oczekuje apn='WAP', ale dostaje „wap”, na którym się dusi.

Pierwszą opcję można łatwo przetestować (i prawdopodobnie wykluczyć), zmieniając konfigurację na „wap” zamiast „WAP”. Być może próbowałeś tego wcześniej, ale w tym czasie bez ofonopakietu, więc kolejny test nie zaszkodzi, chociaż druga opcja jest bardziej prawdopodobna.

Druga opcja jest również większym problemem, biorąc pod uwagę, że z modemu dostępna jest wielka „kontekst PDP”. Patrząc na ten problem, wydaje się, że dopasowanie bez rozróżniania wielkości liter jest poprawne w (najwyraźniej istotnej) specyfikacji „3GPP TS 23.003 rozdział 9.1”, a łatka do tego dodana została ModemManagerw listopadzie ubiegłego roku (do wersji mm-1-4, Mogę zebrać). Tak więc w tym przypadku modem nie został o tym poinformowany i oczekuje dopasowania ModemManagerz rozróżnianiem wielkości liter , a niestety korzysta z dopasowania bez rozróżniania wielkości liter, a nie jako rezerwowego.

Jednym rozwiązaniem drugiego problemu jest oczywiście użycie innego ModemManager: albo znajdując i instalując wersję przed tą łatką, albo (przy wystarczającej ilości wolnego czasu), rzuć własną ModemManager. Ale nie jest to coś kapryśnego, więc może musimy trochę się rozejrzeć, aby uzyskać więcej dowodów na to, że jest to (teraz) problem, i jeśli to możliwe, znaleźć inne sposoby obejścia tego. Lub przy odrobinie szczęścia ktoś, kto coś wie, wpada ...

EDYCJA 2

Tak, wycofywanie wersji nie jest łatwe z powodu zależności. A kręcenie własnym jest również dalekie od radości.

Dwa możliwe przydatne narzędzia: polecenie mmclii ( http://m2msupport.net/m2msupport/module-tester/ ).

Myślę, że problem polega na tym, że ModemManager wybiera kontekst PDP 1 z apn = „wap”, gdzie powinien wybrać kontekst PDP 9 z apn = „WAP”. Być może można to rozwiązać za pomocą jednego z tych narzędzi. Albo być w stanie wymusić wybór 9 podczas połączenia, lub usuwając złe modemy „wap” z modemu, do czego reklamowane jest narzędzie do testowania modułów.

Narzędzie do testowania modemów wydaje się być narzędziem java w przeglądarce, więc musisz mieć skonfigurowaną przeglądarkę, aby wiedzieć, gdzie jest twoja java, i potrzebujesz, aby o niej wiedzieć. Następnie zapoznaj się z tym podejściem; Nie korzystałem z niego sam, ale widząc zrzuty ekranu, domyślam się, że przedstawi konteksty PDP jako zakładkę „Połączenia danych”, gdzie najpierw zanotujesz wszystko, co pokazuje, a następnie edytujesz wpisy „wap”, aby zniekształć etykiety APN „wap”, np. „wap1” i „wap2” (aby „ukryć” je, szukając „WAP”). Następnie zapisz i zamknij i ponownie żongluj kluczem sprzętowym. Weź dziennik; wydaje się, że syslog jest teraz wystarczający na wypadek, gdyby nadal odmawiał gry.

mmcliPolecenia wydaje się również przydatna w tej historii; róbcie man mmclio tym, ale nie widziałem tam nic o kontekstach PDP.

EDYCJA 3

Dobra decyzja! przetestować z DVD. To powiedziało nam, że jestem na złym tropie z APN i że wszystko polega na tym, aby ppp się pojawił. Przynajmniej będzie to moje nowe drzewo, na którym można szczekać.

Po pierwsze, zauważamy, że istnieje różnica wersji dla pppd (od 2.4.5 do 2.4.6), ale prawdopodobnie nie jest to problem, ponieważ wtedy wszyscy na kluczu sprzętowym byliby na tej wycieczce.

Hmm, ppp; Muszę wzbudzić wspomnienia z ostatniego tysiąclecia :-). Niestety jestem dzisiaj zajęty, ale dotknę bazy, kiedy będę miał czas, aby zobaczyć, jak daleko zaszedłeś. Moje pierwsze zaułki to: 1) czy użytkownik jest w odpowiedniej grupie? 2) czy dane logowania są prawidłowe? 3) Czy plik konfiguracji ppp / czatu ma rację? Dziennik debugowania ppp jest dostępny w nm.txt (jak kilka dni temu), ale powinien być również sposób na poproszenie go o bardziej szczegółowe rejestrowanie.

EDYCJA 4

Upewnij się /etc/ppp/pap-secretsi /etc/ppp/chap-secretsmiej grupę dip(używając chgrpw razie potrzeby) i tryb 740(lub -rw-r-----) (używając chmodw razie potrzeby). Mój nie.

EDYCJA 5

A co z tym drzewem: Porównując działający wvdialsyslog z niedziałającym syslog, wydaje się, że z jakiegoś powodu wvdialużywany, ttyUSB3podczas gdy niedziałający ModemManagernadal korzysta ttyUSB1. Nie jestem pewien, czy jest to w ogóle istotne, ale widocznie ale ttyUSB1i ttyUSB3oba reagują jak AT zdolnych modemów.

Tak więc, w ramach testu, może możesz edytować, /etc/wvdial.confaby [Dialer Defaults]zawierał wiersz:

Modem = /dev/ttyUSB1

dla jednego testu i ttyUSB3dla drugiego; oba działają jako root; żeby zobaczyć, czy jest inne zachowanie. Zwłaszcza jeśli używanie ttyUSB1jest problemem, podczas gdy używanie ttyUSB3 nie jest, dobrze byłoby zastanowić się, jak zmusić ModemManager do używania ttyUSB3. W przypadku każdego innego wyniku testu powiedziałbym, że wrócimy do ścigania fretek w ziemi ppp.

EDYCJA 6

Myślę, że dziennik dmesg można zignorować; tak było we wszystkich logach. Nowy syslog pokazuje tylko test ttyUSB3, ale być może możemy założyć, że życie staje się lepsze, jeśli NetworkManagermożna spróbować użyć ttyUSB3 i zignorować ttyUSB1 (dla tego modemu).

Znalazłem też ( https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/819784 ) ze szczególnie niepokojącym postem nr 10 :-(

Pozornie obowiązująca udevreguła /lib/udev/rules.d/77-mm-zte-port-types.rulesnie ma zastosowania, ale podobno byłaby gdzie iść. I mając tylko bardzo szczątkowy, przed 101 aspektem wgląd w udevmagię, w każdym razie rozważałbym zakwestionowanie czwartej linii, która mówi:

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

Myślę, że ten wiersz wymaga inicjałów #, aby zostać skomentowanym. Szczegółowo, mój odczyt pliku polega na tym, że wymaga on stanu wywołania SUBSYSTEM == „tty” i SUBSYSTEMS = „usb” w celu użycia dobrych bitów, w tym reguł produktu „2003”, a przynajmniej do testowania, należy bezpiecznie pominąć filtrowanie „tty”. I nie mam teraz nic lepszego.

EDYCJA 7

Po spędzeniu trochę czasu z moją ulubioną wyszukiwarką, uważam nieco bardziej, że wybór ttyUSB jest tutaj głównym problemem. Zasada udev, na którą wskazałem, jest w porządku i powinieneś cofnąć tę edycję.

Zacząłem jednak wierzyć, że reguły konfiguracji pod koniec tego pliku, dla identyfikatora produktu „2003”, są mylące. Z dzienników wynika, że ​​identyfikator produktu „2003” jest tak naprawdę stroną klucza pamięci klucza sprzętowego, podczas gdy strona modemu ma identyfikator produktu „1232”. Możesz to przetestować, replikując w pliku dwie reguły „2003” dla identyfikatora produktu „1232”/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"

lub lepiej, dodaj obok niego nowy plik, np. o nazwie 78-ralph.rules, ale musisz także dodać ochronę SUBSYSTEM i SUBSYSTEMS wokół niego.

Następnie wyciągnij klucz, uruchom udevadm control --reload(lub uruchom ponownie) i włóż klucz. A potem kolejne syslogprzechwytywanie, chyba że teraz się stanie.

Jednak skutecznym problemem jest to, że ModemManager odrzuca wtyczkę libmm-plugin-zte.sopodczas wstępnego sondowania i kończy się na zwykłym module obsługi modemu. Jeśli mam rację co do identyfikatora produktu, może to być powód; wstępne sondowanie szuka ID_MM_ZTE_PORT_TYPE_MODEMatrybucji, a brakuje jej identyfikatora produktu „1232” (przed łatką), co powoduje odrzucenie wtyczki Zte.

EDYCJA 8

syslogDziennika jest nieco krótki; brakuje początku, w którym ModemManager nie instaluje wtyczki Zte. Jednak jasne jest, że i tak używana jest standardowa wtyczka modemu. Możliwe, że usb_modeswitchzasada, którą wam wcześnie podałem, jest również niewłaściwa; decyduje się przejść na „2003”, kiedy pomyślałem, że zmieniło się z „2003”. Ale man usb_modeswitch(na co powinienem był spojrzeć wcześniej) sugeruje, że zmienia się raczej na identyfikator produktu niż z niego. W każdym razie dziennik pokazuje, że tak się stanie. Dlatego zmień tę regułę na „1232” i spróbuj jeszcze raz.

Jeśli nic więcej, przynajmniej muszę się trochę dowiedzieć o udev.

EDYCJA 9

Dobry. Problemem jest (lub też) to, że ModemManager upuszcza wtyczkę ZTE podczas wstępnego sondowania. Dzienniki debugowania ModemManager dla 15.10 (zestawy dzienników „dzienniki debugowania *”) opowiadają historię, że wtyczka ZTE została odrzucona z powodu testu id dostawcy / id.

Idź do źródła, Luke! Skorzystałem z okazji, aby krótko zobaczyć kod źródłowy ModemManager i wskazuje on, że wtyczka jako tabela vid / pid, która nie zawiera 19d2 / 2003 ... chociaż nie znalazłem tego źródła tabeli, więc nie mogłem weryfikować.

A może jest tutaj problem z synchronizacją. Na przykład, że ModemManager uruchamia wstępne sondowanie, gdy urządzenie ma rozmiar 19d2 / 1232. Myśl ta jest zgodna z obserwacją, że posiadanie reguł udev 78 mm-zte-port-types-RALPH.rules sprawia, że ​​ModemManager jest nieco bardziej zadowolony z urządzenia. Ale dlaczego nie jest szczęśliwy i nie korzysta z tej wtyczki, gdy urządzenie jest przełączone na 19d2 / 2003?

Być może potrzeba więcej dzienników :-) Po debugowaniu ModemManager, a także przechwytywanie polecenia udevadm monitor --e |& tee udevadm.log(w innym terminalu) po podłączeniu urządzenia. Mam to polecenie z ( https://wiki.ubuntu.com/DebuggingUdev )

Zrób to dwa razy: raz bez 78-mm-zte-port-types-RALPH.rulesi raz z regułami ... za każdym razem od nowego restartu. To znaczy

1. instalacja /lib/udev/rules.dz *-RALPH.rulesplikiem lub bez pliku
2. wyciągnij urządzenie
3. restart
4. setup ModemManager do debugowania i konfiguracji przechwytywania udevadm
5. podłącz urządzenie i poczekaj minutę
6. pakuj pliki dziennika
7. powtórz od 1 z następnym testem

To rejestrowanie powinno powiedzieć, gdzie upuszczana jest wtyczka ZTE, i jak rozumiem, powie także o obsłudze zdarzeń udev.

EDYCJA 10

(Jestem prawie na końcu mojego uwięzi, ale mam jeszcze jeden lub dwa oddechy :-)

Po pierwsze, wszystkie udevdekoracje wydają się kończyć tak, jak powinny, z kilkoma znakami zapytania w kilku atrybutach. W szczególności 78-*-RALPH.rulesnależy je wyrzucić; to nie jest przydatne.

Myślę, że mogę coś z tego odczytać, ale nie jestem pewien, jak to naprawić. Zasadniczo, jak widzę, po podłączeniu klucza sprzętowego następuje lawina udev. Koncentrując się na tych dotyczących ttyUSB1, istnieje „wczesne” wydarzenie:

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

co powoduje usb_serialzaładowanie i /dev/ttyUSB1wyświetlenie sterownika . To w szczególności powoduje inne zdarzenie:

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

Myślę, że to również uruchamia ModemManager. Musisz udać się, syslogaby zobaczyć dowody na to, ponieważ nie ma ścisłej korelacji między dziennikami. Zdarzenie jest oznaczone datą 3867.435102i syslogprzedstawia najbliższą kolejną ModemManagerlinię dziennika tuż po stemplowaniu linii dziennika jądra 3867.437412.

Zgodnie z moim ModemManagertokiem myślenia nie powinno się jeszcze uruchamiać, ale dopiero po kolejnym zdarzeniu ttyUSB1:

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

który dołączył atrybuty ZTE.

W dzienniku MM bylibyśmy na linii oznaczonej stemplem 1449934745.363291, która najwyraźniej jest znacznikiem czasu „w czasie rzeczywistym”, a nie znacznikiem „czasu jądra”.

ModemManagernastępnie wykonuje się wstępne sondowanie w 1449934745.450398, tj. 87 ms później, co w ujęciu czasowym jądra byłoby bliskie 3867.524519i 55 ms przed tym „dobrym” raportem zdarzenia UDEV powyżej.

Zauważ, że w syslog, ModemManagerskłada skargi, które ttyUSB1nie mają ustawionych atrybutów, i być może ta skarga jest związana z „oznaczaniem”, które ma miejsce 80-mm-candidate.rules. W komentarzu w tym pliku oznaczenie to wydaje się być próbą rozwiązania dokładnie tego problemu, ale jeśli tak, to w tym przypadku nie działa.

Być może jedną z możliwości rozwiązania tego jest zmiana reguły „tty” 80-mm-candidate.rulesna:

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

Moim zdaniem zapewniłoby to ID_MM_CANDIDATEopóźnienie ustawienia do momentu ustawienia atrybutów ZTE. .ID_PORTUstawienie jest efektem 60-serial.rulesrządów (zwanego 60-persistent-serial.ruleswcześniej), i dodaje warunek reguły znakowania jest po prostu, że ma wartość.

Warunek nie jest dokładnie atrybutem ZTE, ale tylko po to, aby reguła była bardziej ogólna. Bardziej konkretnym krokiem byłoby raczej wymagać ENV{.MM_USBIFNUM}="?*"zamiast tego, ponieważ to zadanie następuje tutaj 77-mm-zte-port-types.rules.

Zasadniczo nie jestem zbyt pewny co do udevporządku reguł i nie jestem wcale pewien, czy to naprawdę przestaje ModemManagerdziałać zbyt szybko. Jeśli jednak tak się nie stanie, wówczas 80-mm-candidate.rulesnie będzie miał prawie żadnej funkcji, a może wszystko sprowadzi się do „ulepszeń” do ModemManager15.04.

EDYCJA 21

westchnienie. Prawdopodobnie nieistotne, ale możesz chcieć sprawdzić swój 7-zte-mutil_port_device.rulesplik; czy to pozostałość po innych eksperymentach? W każdym razie nie dotyczy to tutaj.

Wciąż prawie drugi pomiędzy 515.558184i 516.381549gdzie ModemManagerchętnie i błędnie zgarnięcia /dev/ttyUSB1, a jednocześnie narzeka, że nie jest skonfigurowana, nadal przechodzi wstępnie sondowania i odrzutów wtyczki ZTE. Innymi słowy, łatka reguły nie ModemManagerczeka.

Podejrzewam, że testowałeś również za pomocą ENV{.MM_USBIFNUM}="?*"zamiast ENV{.ID_PORT}=="?*".

W rzeczywistości, aby potwierdzić, czy ustawienie ENV{ID_MM_CANDIDATE}=1ma jakiekolwiek znaczenie, należy tymczasowo odejść 80-mm-candidate.rules, a następnie zobaczyć (w syslog), jeśli to ModemManagerzignoruje, /dev/ttyUSB1czy nie. Podejrzewam „nie”.

A potem, no cóż, może możesz użyć działającej wersji, takiej jak 14.04, a jeśli potrzebujesz, być może uruchom 15.10 w wirtualnej skrzynce, chyba że wszystko jest już w wirtualnej skrzynce.

Myślę, że w tym momencie muszę przyznać się do porażki.

Modem zaczął działać w systemie Ubuntu 16.04. Ta wersja jest wciąż w fazie rozwoju, ale działa dobrze na moim laptopie.

Chciałbym podać więcej szczegółów technicznych na temat tego, jak zaczął on działać.

Po rzucie oka na to wygląda na to, że nie jest to pierwszy przypadek, kiedy ten smok został odpowiednio potraktowany. To był błąd wcześniej w 12.10 i 13.04, być może błąd nigdy nie został naprawiony lub nowa łata zepsuła coś, co wcześniej działało poprawnie.

Mam nadzieję, że jeśli poprawnie czytam dane techniczne, będę musiał wskazać Ci ten kierunek (MF190J):

Modem 3G (ZTE MF190J) nadal wymaga ręcznego dostosowania.

Czy próbowałeś tego:

 rfkill list up

a następnie utwórz ten skrypt i uruchom go:

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

i może w ten sposób działać dobrze.