Chyba „ip-config-unavailable“ při pokusu o připojení USB modemu?

Mám modem ZTE MF-193E, který dříve fungoval dobře. Když jsem si tento modem koupil před více než rokem, fungoval bez problémů hned po vybalení z krabice.
Nyní, jak Ubuntu postupuje ve verzi, jsou věci pro mě stále obtížnější.

Tento modem dokonce fungoval před pár měsíci s Ubuntu 15.04 (64-bit). Nyní se v Ubuntu 15.10 (64bitový) nemůže připojit.

Nastavil jsem mobilní širokopásmové připojení. Zkoušel jsem různé řetězce pro APN, ale dříve to nebyl problém.

(Modem funguje dobře ve Windows 10, takže se nejedná vůbec o hardwarový problém. Také GUI Správce modemu toto zařízení pěkně detekuje. Zprávy SMS lze bez problémů odesílat a přijímat.)

Když vložím modem, je detekován v pořádku, v Unity se zobrazí ikona CD s názvem modemu. O několik sekund později
se mi zobrazí zpráva

Mobile Broadband Network: you are registered on the home network

poblíž ikony sítě.

Když se pokusím připojit, ikona bezdrátového připojení v appletu správce sítě spustí tyto odstředivé pohyby, ale nakonec se připojení nepodaří a zobrazí se zpráva, že jsem offline.

Řádek, který jsem mohl izolovat z /var/log/syslog je toto,

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

Nejsem si však jistý, zda je to relevantní.

Další řádky z
/var/log/syslog naleznete zde.

Aktualizace 1. – 6. prosince 2015

Jak poukázal jeden druh člen, vyzkoušel nf_conntrack_pptp modulový přístup.

Byly provedeny následující příkazy,

$ 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

Pak jsem zkusil můj modem, stejná chyba. Ani v logu není patrná žádná změna.

Aktualizace 2 – 6. prosince 2015

Spuštěn jako root,

systemctl restart network-manager.service

Žádný výstup na obrazovku (terminál).

Odpovídající protokol z výše uvedeného bodu pokusu o připojení pomocí modemu naleznete zde.

Aktualizace 3. – 6. prosince 2015

Nainstalováno ofono a pak zkusil modem znovu.

Podívejte se prosím na log zde.

Aktualizace 4. – 6. prosince 2015

Opět spuštěn jako root,

systemctl restart network-manager.service

Odpovídající protokol z výše uvedeného bodu pokusu o připojení pomocí modemu naleznete zde.

Aktualizace 5. – 6. prosince 2015

V /etc/dbus-1/system.d/nm-dispatcher.conf bylo vše „deny“ změněno na „allow“ .

Pokus o připojení. Žádné štěstí.

Několik sítí se připojuje a odpojuje pomocí připojení Ethernet.

Následuje sudo systemctl restart network-manager.service .

Modem odpojte a zapojte.

Pokus o připojení znovu. Nepřipojí se.

Záznam je zde.

Aktualizace 6. – 6. prosince 2015

Provedeno

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

a

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

Nelze spustit mm-test.py kvůli více chybám. Našel soubor na uvedeném místě. Mám to z https://github.com/openshine/ModemManager/blob/master/test/mm-test.py.

Výše uvedené příkazy se poněkud liší od příkazů ve Wiki.

Soubory protokolu jsou zde.

Aktualizace 7. – 7. prosince 2015

Spuštěno znovu (po navrhované změně v /lib/udev/rules.d/40-usb_modeswitch.rules a restartujte)

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

a

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

/var/log/syslog je zahrnuto také.

Soubory protokolu jsou zde.

Aktualizace 8. – 8. prosince 2015

Aktualizovaná sada protokolů je zde.

Aktualizace 9. – 8. prosince 2015

Test 1

1. Tentokrát spustil počítač z 32bitového DVD Ubuntu 14.04. Jakmile se počítač nabootoval, začal zaznamenávat protokol MM.

2. Vložil modem. lsusb ukázalo, že bylo rozpoznáno jako
   zařízení 19d2:1232, které je třeba přepnout na zařízení 19d2:2003
   . Protože instalace usb-modeswitch vyžaduje restartování
   stroje (a tedy ztrátu instalace pro spuštění DVD), připravil jsem
   vlastní soubor přepínače a přepnul modem z příkazového řádku (sudo
usb_modeswitch -I -c 19d2:2003 ).

3. Jakmile bylo přepnutí dokončeno, bylo mi oznámeno, že jsem
   v Mobile Broadband Network a v nabídce správce sítě se objeví
   Nové širokopásmové připojení.

4. Výše uvedené připojení jsem nastavil obvyklým způsobem (název APN nebyl
   problém) a připojení bylo navázáno automaticky.

5. Odpojil jsem a vysunul modem.

6. Zaznamenání protokolu MM bylo zastaveno.

Kompletní protokol MM a syslog pro zahájení relace do vysunutí modemu naleznete zde.

Test 2

Stejný test s 64bitovým DVD Ubuntu 14.04.

Záznamy lze nalézt zde.

Aktualizace 10. – 9. prosince 2015

Tentokrát testováno pomocí wvdial a zjistili, že if wvdial je spuštěn jako root,
dostaneme úspěšné připojení.

wvdial conf a log a odpovídající syslog jsou zde

Primární domněnka:situace může mít něco společného s uživatelskou skupinou odpovídajícího uživatele.

Ale jak je uvedeno zde,

Se všemi těmito nástroji musí uživatel k navázání vytáčeného připojení
být členem skupin „dip“ a „dialout“, takže do těchto skupin zařaďte všechny uživatele, kteří se
mají připojit přes vytáčené připojení .

Ale jak můžeme zjistit,

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

Uživatel je tedy již
členem uvedených skupin.

Nyní se možná problém scvrkává na některý z těchto bodů,

1. Jakou další skupinou musí uživatel být?
2. Jak spustíme proces nastavení mobilního širokopásmového připojení jako root? (bezpečnostní problémy?)

Aktualizace 11. – 9. prosince 2015

wvdial funguje s USB3 a ne pracovat s USB1.

Syslog naleznete zde.

Součástí je také výstup dmesg | grep tty > /tmp/dmesg.tty.txt . Ale vidíte ty čtyři řádky blízko začátku souboru?

Aktualizace 12. – 10. prosince 2015

1. Komentovaný řádek 4 (SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end" ) v /lib/udev/rules.d/77-mm-zte-port-types.rules .

2. Restartoval můj stroj. Soft odpojil kabel a vložil modem.

3. Pokus o připojení. Neúspěšné.

Soubor syslog je zde.

Aktualizace 13. – 10. prosince 2015

Z čirého zoufalství, abychom zjistili, zda některé místní změny ovlivňují připojení, otestovali počítač s disky DVD Ubuntu 15.04 a 15.10.

1. Zavedl počítač pomocí Xubuntu 15.04 64bit DVD. Spojení bylo úspěšné jako kouzlo.
2. Zavedl počítač pomocí Ubuntu 15.10 64bit DVD. Připojení se nezdařilo stejně jako předtím.

Co se stalo mezi 15.04 a 15.10?

Tak frustrující.

Aktualizace 14. – 10. prosince 2015

1. Vytvořil nový soubor /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules jak je uvedeno v odpovědi.

2. Restartoval jsem počítač (nebo spustil sudo udevadm control --reload , vlastně zkusil obojí). Je vložen modem.

3. Modem byl rozpoznán.

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

4. Soft odpojil kabel a pokusil se připojit pomocí modemu. Neúspěšné.

5. Odpojili jste modem.

Stroj se jednou zasekne, je to náhodná událost? Můj stroj
obvykle jednou za rok nevisí.

Soubor syslog a vytvořené soubory pravidel jsou zde.

Aktualizace 15. – 11. prosince 2015

1. Do /lib/udev/rules.d/40-usb_modeswitch.rules byly přidány následující řádky .

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

2. Vlevo ze souboru /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules neporušené.

3. Restartoval můj stroj. Je vložen modem.

4. Modem byl rozpoznán.

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

5. Soft odpojil kabel a pokusil se připojit. Neúspěšné.

6. Odpojili jste modem.

7. Odebráno /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules .

8. Restartoval a zkusil celý proces znovu. Opět neúspěšné.

Soubor syslog (kompletní, neriskoval jsem, že zmeškám nějakou
důležitou část) a zmíněný soubor pravidel (40) jsou zde.

Aktualizace 16. – 11. prosince 2015

1. Ponecháno pouze jedno pravidlo 1232 v
   /lib/udev/rules.d/40-usb_modeswitch.rules , odstranil druhý
   jeden.

2. Spuštěno sudo udevadm control --reload .

3. Je vložen modem.

4. Modem byl rozpoznán.

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

5. Soft odpojil kabel a pokusil se připojit. Neúspěšné.

6. Odpojili jste modem.

Ale netestovali jsme výchozí systém výše? Chtěli jste opustit /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules na jeho místě?

Soubor syslog (kompletní, neriskoval jsem, že zmeškám nějakou
důležitou část) a zmíněný soubor pravidel (40) jsou zde

Aktualizace 17. – 11. prosince 2015

1. Okomentováno pravidlo 1232 v
   /lib/udev/rules.d/40-usb_modeswitch.rules , přidal jeden pro rok 2003.

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

2. Spuštěno sudo udevadm control --reload .

3. Je vložen modem.

4. Modem byl rozpoznán jako 1232 přístroj. Není mi nabídnuto, abych se pokusil o připojení (podle mých znalostí nebude zaregistrováno do širokopásmové sítě, pokud k přepnutí nedošlo v roce 2003)

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

5. Odpojili jste modem.

Související:upgrade z 15.10 na 16.04 apt není nainstalován?

Soubor syslog a zmíněný soubor pravidel (40) jsou zde

Aktualizace 18. – 11. prosince 2015

1. Vložte všechny soubory pravidel do jejich původní podoby.

2. Sledováno lsusb výstup každou sekundu pomocí skriptu shell
   . Zachycený výstup do souborů s časovým razítkem.

3. Vložil modem. (Modem se nejprve objeví v souboru
   lssuboutouput.Fri Dec 11 16:56:29 BDT 2015.txt ). Jak můžeme zjistit
   ze záběrů, je jasné, že přechází ze zařízení 1232 na
   2003.

4. Pokus o připojení. Neúspěšné.

5. Odpojili jste modem.

Soubor syslog s časovým razítkem lsusb výstupy a zmíněné soubory pravidel jsou zde.

Nyní možná budete chtít porovnat výstupy syslog s časovými značkami.

Aktualizace 19. – 11. prosince 2015

Provedli jsme tento test zcela novým směrem s přáním, abych
mohl izolovat problémy.

1. Uloženo na přenosném médiu /lib/udev/rules.d/40-usb-media-players.rules a /lib/udev/rules.d/77-mm-zte-port-types.rules (z počítače Ubuntu 15.10).

2. Zavedl počítač pomocí Xubuntu 15.04 64bit DVD.

3. Spuštěn diff 77-mm-zte-port-types.rules
/lib/udev/rules.d/77-mm-zte-port-types.rules >
diff15.10and15.04_77-mm.txt . První soubor je z toho uloženého
   z 15.10.

   Prozkoumání souboru diff neukazuje žádný idProduct 1232 nebo 2003.

4. Spuštěno diff 40-usb_modeswitch.rules
/lib/udev/rules.d/40-usb_modeswitch.rules >
diff15.10and15.04_40-usb.txt . Opět platí, že první soubor je z toho
   uloženého z 15.10.

   Zkoumání souboru diff opět neukazuje žádný idProduct 1232 nebo 2003.

5. Vložil modem. Modem byl rozpoznán jako modem.

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

6. Po nastavení mobilního širokopásmového připojení se lze snadno připojit.

7. Odpojili jste modem.

8. Nainstalován nejnovější USB_ModeSwitch.

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

   Nyní vrací hodnotu NULL, jak bylo očekáváno.

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

10. Vložil modem. Modem byl rozpoznán jako modem.

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

11. Lze se snadno připojit.

Mohl jsem zkusit upgradovat MM a NM na Ubuntu 15.10, jen abych viděl, kde se to zlomí. Vlastně jsem to zkusil, ale vzdal jsem to kvůli nekonečným problémům se závislostí.

Všechny výše uvedené soubory rozdílů jsou zde.

Aktualizace 20. – 12. prosince 2015

Test 1

1. /lib/udev/rules v původním stavu.

2. Modemové zařízení ještě nebylo v této relaci vloženo.

3. Nastavte ModemManager pro ladění a nastavení zachycení udevadm.

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

4. Zapojil modem a počkal, až se zobrazí zpráva, že je zaregistrován v širokopásmové síti.

5. Pokus o připojení neúspěšně.

6. Odpojili jste modem.

7. Zabalené soubory protokolu.

Test 2

Opakujte výše uvedený test s
/lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules na místě.

Názvy souborů protokolu jsou samozřejmé.

Všechny výše uvedené soubory protokolu plus syslog a soubory 78 pravidel jsou
zde.

Přál bych si, aby všechny soubory protokolu přicházely s časovými razítky, aby bylo přiřazování snazší.

Aktualizace 21. – 15. prosince 2015

1. Změnili soubor pravidel podle návrhu.
2. Restartoval jsem počítač.
3. Vložili modem a zkusili se připojit. Nefungovalo to.

Soubor pravidel a syslog jsou zde.

Aktualizace 22. – 16. prosince 2015

Jak bylo doporučeno v jednom komentáři, nainstalovali jste různá jádra z
http://kernel.ubuntu.com/~kernel-ppa/mainline/ a zkusili se připojit
pomocí modemu po zavedení každého z nich.

1. 4.2.8-040208-generic, selhání.

2. 4.1.15-040115-generic, selhání.

3. 4.0.9-040009-generic, selhání.

Takže možná můžeme vyloučit problém s jádrem.

Aktualizace 23. – 16. února 2016

Modem začal fungovat v Ubuntu 16.04. Tato verze je stále ve verzi Alpha 1, ale na mém notebooku funguje dobře.

Přijatá odpověď:

Načítání ofono balíček se pravděpodobně povedl, ale váš model modemu, ZTE MF193E, zřejmě není na seznamu ZTE. V porovnání s jinými modemy ZTE, např. MF190J, tento modem pravděpodobně potřebuje stejný speciální udev pravidlo pro spuštění usb_modeswitch po vložení hardwarového klíče a abyste toho dosáhli, můžete jako root přidat nový udev pravidlo do souboru
/lib/udev/rules.d/40-usb_modeswitch.rules
s následujícími dvěma řádky, např. někde poblíž # ZTE MF190J komentář:

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

plus prázdný řádek, takže to vypadá příjemně.

Pravděpodobně bude moudré restartovat poté, ale zjistíte, že to všechno funguje jako kouzlo 🙂

Nebo ne. Jak víte, je to pro mě hluboká voda, ale pokud to stále nefunguje, bude potřeba další protokol ladění ModemManager pro další divoký odhad.

EDIT:

Nyní se dívám na dva řádky v souboru modemmanager.txt:

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

a

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

Hádám, že první odkazuje na vaše širokopásmové nastavení, zatímco druhé odkazuje na vnitřní vazbu na „kontext PDP“ (ať už je to cokoli). Jak to vypadá, modem nabízí 9 alternativních kontextů, včetně jednoho s apn='WAP' , ale ModemManager se spokojí se shodou bez rozlišení malých a velkých písmen.

Rozdíl mezi malými a velkými písmeny může být příčinou následného problému:např. že ppp chce 'wap' konfigurace (spíše než 'WAP' ) a nenašel jej, nebo že vzdálený konec očekává apn='WAP' , ale dostane ‚wap‘, který se dusí.

První možnost by mohla být snadno otestována (a pravděpodobně vyloučena) změnou konfigurace tak, aby používala „wap“ místo „WAP“. Možná jste to již zkoušeli, ale tehdy bez ofono balíček, takže další test neuškodí, i když pravděpodobnější je druhá možnost.

Druhá možnost je také větší problém, vzhledem k tomu, že z modemu je k dispozici shoda „PDP kontextu“ velkými písmeny. Při vyhledávání tohoto problému se zdá, že shoda nerozlišující malá a velká písmena je správná podle (zřejmě relevantní) specifikace „3GPP TS 23.003 kapitola 9.1“ a do ModemManager byla přidána oprava, která to umožňuje v listopadu loňského roku (do jeho verze mm-1-4, mohu shromáždit). V tomto případě tedy váš modem nebyl informován a očekává, že se budou rozlišovat malá a velká písmena, zatímco ModemManager bohužel používá párování bez rozlišení velkých a malých písmen přímo, spíše než jako záložní řešení.

Jedním řešením druhého problému je samozřejmě použít jiný ModemManager :buď vyhledáním a instalací verze před tímto patchem, nebo (s dostatkem volného času) spusťte svůj vlastní ModemManager . Ale ani jedno se nedá dělat z rozmaru, takže možná budeme muset trochu procházet, abychom získali další důkazy, že to je (nyní) problém, a pokud možno najít jiné způsoby, jak jej obejít. Nebo s trochou štěstí zapadne někdo, kdo něco ví...

UPRAVIT 2

Ano, vrácení verze není snadné kvůli závislostem. A válet si vlastní není ani zdaleka radost.

Dva možné užitečné nástroje:příkaz mmcli a
(http://m2msupport.net/m2msupport/module-tester/).

Myslím, že problém je v tom, že ModemManager vybírá kontext PDP 1 s apn='wap', kde by měl vybrat kontext PDP 9 s apn='WAP'. Možná to lze vyřešit pomocí některého z těchto nástrojů. Buď aby bylo možné vynutit výběr 9 během připojení, nebo odstraněním špatných „wapových“ kontextů z modemu, což je inzerovaný nástroj pro testování modulů schopen.

Zdá se, že nástroj na testování modemu je v prohlížeči java nástroj, takže potřebujete prohlížeč nastavit tak, aby věděl, kde je vaše Java, a potřebujete, aby se o této javě vědělo. Pak prosím prozkoumejte tento přístup; Sám jsem to nepoužil, ale když jsem viděl snímky obrazovky, hádám, že to bude prezentovat kontexty PDP jako kartu „Data Calls“, kde si nejprve poznamenáte vše, co zobrazuje, a poté upravte položky „wap“ na překroutit štítky 'wap' apn tak, aby byly, řekněme, 'wap1' a 'wap2' (tak, aby se „skryly“ při hledání 'WAP'). Pak uložte a zavřete a znovu žonglujte s donglem. Chyť kládu; zdá se, že syslog je nyní dostačující pro případ, že by stále odmítal hrát.

mmcli příkaz se v tomto příběhu také zdá užitečný; do man mmcli abych si o tom přečetl, ale nic o kontextech PDP jsem tam neviděl.

UPRAVIT 3

Dobrý telefonát! otestovat z DVD. To nám řeklo, že jsem s APN na špatné cestě a že to všechno spočívá v tom, aby se objevilo ppp. Alespoň by to byl můj nový strom, na který bych mohl štěkat.

Související:Software pro zjištění spotřeby energie stolního počítače?

Nejprve bereme na vědomí, že existuje rozdíl ve verzi pro pppd (od 2.4.5 do 2.4.6), ale to pravděpodobně není problém, protože v takovém případě by se této exkurze zúčastnil každý na hardwarovém klíči.

Hmm, ppp; Potřebuji rozproudit své vzpomínky z minulého tisíciletí :-). Bohužel jsem dnes zaneprázdněn, ale až budu mít čas, dotknu se základny, abych viděl, jak daleko jste došli. Moje první zadní uličky, do kterých bych se chtěl podívat, by byly:1) je uživatel ve správné skupině? 2) jsou přihlašovací údaje správné? 3) Je mod konfigurace souboru ppp/chatu správný? Protokol ladění ppp vychází v nm.txt (jako před několika dny), ale měl by existovat i způsob, jak jej požádat o podrobnější protokolování.

UPRAVIT 4

Ujistěte se, že /etc/ppp/pap-secrets a /etc/ppp/chap-secrets mít skupinu dip (pomocí chgrp podle potřeby) a režim 740 (nebo -rw-r----- ) (pomocí chmod podle potřeby). Můj ne.

UPRAVIT 5

Co třeba tento strom:Porovnání funkčního wvdial syslog s nefunkčním syslogem, zdá se, že z nějakého důvodu wvdial používá ttyUSB3 zatímco nepracuje ModemManager nadále používá ttyUSB1 . Nejsem si jistý, jestli je to vůbec významné, ale zjevně ale ttyUSB1 a ttyUSB3 oba reagují jako modemy schopné AT.

Takže jako test možná můžete upravit /etc/wvdial.conf tak to pod [Dialer Defaults] obsahuje řádek:

Modem = /dev/ttyUSB1

pro jeden test a ttyUSB3 pro další; oba běží jako root; jen abych zjistil, jestli tam není jiné chování. Zvláště pokud používáte ttyUSB1 je problém, zatímco použití ttyUSB3 není, pak by bylo dobré podívat se na to, jak přimět ModemManager, aby používal také ttyUSB3. Pro jakýkoli jiný výsledek testu bych řekl, že se vrátíme k pronásledování fretek v zemi ppp.

UPRAVIT 6

Myslím, že dmesg log lze ignorovat; bylo to tak ve všech protokolech.
Nový syslog zobrazuje pouze test ttyUSB3, ale možná můžeme předpokládat, že život se zlepší, pokud NetworkManager může být obtížné použít ttyUSB3 a ignorovat ttyUSB1 (pro tento modem).

Také jsem našel (https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/819784) zvláště příspěvek č. 10 znepokojující 🙁

Zjevně použitelné udev pravidlo v /lib/udev/rules.d/77-mm-zte-port-types.rules neplatí, ale údajně by bylo, kam jít. A pouze s velmi primitivním náhledem do udev před verzí 101 magie, každopádně bych zvážil zpochybnění jeho 4. řádku, který říká:

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

Myslím, že tento řádek potřebuje počáteční # aby se to okomentovalo. Podrobně, můj soubor je takový, že vyžaduje volající stav SUBSYSTEM==”tty” a SUBSYSTEMS=”usb”, aby bylo možné použít dobré kousky, včetně pravidel produktu “2003”, a alespoň pro testování, mělo by být bezpečné přeskočit filtrování „tty“. A nic lepšího teď nemám.

UPRAVIT 7

Poté, co jsem strávil nějaký kvalitní čas s mým oblíbeným vyhledávačem, jsem přesvědčen o trochu více, že hlavním problémem je zde volba ttyUSB. Pravidlo udev, na které jsem poukázal, je v pořádku a měli byste tuto úpravu vrátit zpět.

Začal jsem však věřit, že konfigurační pravidla ke konci tohoto souboru pro ID produktu „2003“ jsou zavádějící. Z protokolů se mi zdá, že ID produktu „2003“ je ve skutečnosti strana paměťového zařízení hardwarového klíče, zatímco strana modemu má ID produktu „1232“. Můžete to vyzkoušet replikací dvou pravidel „2003“ pro ID produktu „1232“ v souboru /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"

nebo lépe, přidejte vedle něj nový soubor, např. s názvem 78-ralph.rules , ale pak musíte také přidat ochranu SUBSYSTEM a SUBSYSTEMS.

Poté vytáhněte klíč a spusťte udevadm control --reload (nebo restartujte) a vložte dongle. A pak další syslog zachytit, pokud to teď náhodou nefunguje.

Efektivní problém je však v tom, že ModemManager zahodí plugin libmm-plugin-zte.so při předběžném sondování a končí pomocí generického obslužného programu modemu. Pokud mám pravdu s ID produktu, pak by to mohl být důvod; že předběžné sondování hledá ID_MM_ZTE_PORT_TYPE_MODEM atribuce, a to chybí u ID produktu „1232“ (před patchem), což má za následek, že plugin zte bude zahozen.

UPRAVIT 8

syslog log je trochu krátký; chybí začátek, kde ModemManager selže při instalaci pluginu zte. Je však jasné, že se každopádně používá plugin Generic modem. Nyní se může stát, že usb_modeswitch pravidlo, které jsem ti dal dříve, je také špatné; rozhodne se přepnout na na „2003“, když jsem si myslel, že přešlo z z „2003“. Ale man usb_modeswitch (na které jsem se měl podívat dříve) tak trochu naznačuje, že se to posouvá do ID produktu, nikoli od to. V každém případě protokol ukazuje, že k tomu dojde. Proto prosím změňte toto pravidlo tak, aby místo něj použilo „1232“ a zkuste to znovu.

Když už nic jiného, ​​musím se alespoň trochu naučit o udev.

UPRAVIT 9

Dobrý. Problém je stále (nebo také), že ModemManager vynechá plugin ZTE při předběžném testování. Všechny protokoly ladění ModemManager pro 15.10 (logové sady „debuglogs*“) vyprávějí příběh o tom, že plugin ZTE byl vyřazen kvůli testu id-vendor-id/product-id.

Jdi ke zdroji, Luku! Využil jsem této příležitosti a krátce jsem si prohlédl zdrojový kód ModemManager, který ukazuje, že plugin jako tabulka vid/pid, která nezahrnuje 19d2/2003 … ačkoli jsem nenašel zdroj této tabulky, takže jsem nemohl ověřit.

Nebo je zde možná problém s načasováním. Například, že ModemManager spouští předběžné sondování, když je zařízení 19d2/1232. Tato myšlenka je v souladu s pozorováním, že pravidla udev 78-mm-zte-port-types-RALPH.rules činí ModemManager se zařízením o něco šťastnější. Ale proč potom nezůstane spokojený a nepoužije tento plugin, když se zařízení přepne na 19d2/2003?

Možná je potřeba více protokolů 🙂 S odladěným ModemManagerem a také zachycením příkazu udevadm monitor --e |& tee udevadm.log (v jiném terminálu), když zařízení zapojíte. Tento příkaz jsem získal z (https://wiki.ubuntu.com/DebuggingUdev)

Proveďte to dvakrát:jednou bez 78-mm-zte-port-types-RALPH.rules a jednou s pravidly... pokaždé z nového restartu. T.j.

1. nastavit /lib/udev/rules.d s nebo bez *-RALPH.rules soubor
2. vytáhněte zařízení
3. restartovat
4. nastavit ModemManager pro ladění a nastavení zachycení udevadm
5. zapojte zařízení a chvíli počkejte
6. zabalte soubory protokolu
7. opakujte od 1 s dalším testem

Toto protokolování by mělo zjistit, kde je plugin ZTE vynechán, a jak jsem pochopil, bude také informovat o zpracování událostí udev.

UPRAVIT 10

(Už jsem skoro na konci sil, ale zbývá mi ještě jeden nebo dva nádechy:-)

Za prvé, všechny udev Zdá se, že dekorace skončí tak, jak mají, jen s několika otazníky v několika atributech. Zejména 78-*-RALPH.rules by měl být vyhozen; není to užitečné.

Myslím, že z toho dokážu něco vyčíst, ale nejsem si jistý, jak by to mělo být opraveno. V zásadě, jak to vidím já, když je připojen hardwarový klíč, dochází k záplavě událostí udev. Pokud se zaměříme na ty, které se týkají ttyUSB1, existuje „časná“ událost:

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

což způsobí usb_serial ovladač, který se má načíst, a /dev/ttyUSB1 objevit se. To zejména způsobí další událost:

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

Myslím, že to také spouští ModemManager . Musíte přejít na syslog vidět důkaz toho, protože mezi protokoly neexistuje žádná přísná korelace. Událost je označena časovým razítkem 3867.435102 a syslog představuje nejbližší následující ModemManager řádek protokolu hned za řádkem protokolu jádra s razítkem 3867.437412 .

Podle mého názoru ModemManager by se nemělo spouštět ještě, ale až po následné události ttyUSB1:

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

který má připojené atributy ZTE.

V protokolu MM bychom byli na řádku s razítkem 1449934745.363291 , což je zjevně časové razítko „v reálném čase“ spíše než „časové razítko jádra“.

ModemManager poté se provede předběžná sonda na 1449934745.450398 , tj. o 87 ms později, což by z hlediska času jádra bylo blízko 3867.524519 a 55 ms před výše uvedenou „dobrou“ zprávou o události UDEV.

Všimněte si, že v syslog , ModemManager podává stížnosti, že ttyUSB1 nemá nastavené atributy a možná tato stížnost souvisí s „označením“, které se děje v 80-mm-candidate.rules . Podle komentáře v tomto souboru se toto označení zdá být pokusem vypořádat se přesně s tímto problémem, ale pokud ano, zdá se, že v tomto případě nefunguje.

Související:Souborový systém pouze pro čtení po upgradu na 15.04 pomocí?

Jednou z možností, jak to vyřešit, by bylo změnit pravidlo „tty“ v 80-mm-candidate.rules být:

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

Podle mého názoru by to zajistilo, že ID_MM_CANDIDATE nastavení se zpozdí, dokud nebudou nastaveny atributy ZTE. .ID_PORT nastavení je efektem 60-serial.rules pravidlo (nazývané 60-persistent-serial.rules dříve) a přidanou podmínkou k pravidlu označování je prostě to, že má hodnotu.

Podmínka není přesně atributem ZTE, pouze proto, aby pravidlo zůstalo obecnější. Ještě konkrétnějším krokem by bylo spíše vyžadovat ENV{.MM_USBIFNUM}="?*" místo toho, protože toto přiřazení zde probíhá pomocí 77-mm-zte-port-types.rules .

Obecně si nejsem u udev moc jistý řazení pravidel a také si nejsem vůbec jistý, zda to skutečně zastaví ModemManager z příliš rychlého jednání. Pokud však ne, pak 80-mm-candidate.rules by nemělo žádnou nebo jen malou funkci a možná by pak všechno sešlo na „vylepšení“ ModemManager od 15.04.

EDITACE 21

povzdech. Pravděpodobně irelevantní, ale možná budete chtít zkontrolovat 7-zte-mutil_port_device.rules soubor; je to pozůstatek z jiných experimentů? Každopádně to zde není relevantní.

Mezi 515.558184 je stále téměř sekunda a 516.381549 kde ModemManager eagerly and erroneously grabs /dev/ttyUSB1 , and whilst complaining about it not being set up, still goes through pre-probing and discards the ZTE plugin. In other words, the rule patch doesn’t make ModemManager wait.

I suppose you also tested using ENV{.MM_USBIFNUM}="?*" instead of ENV{.ID_PORT}=="?*" .

Actually, to confirm whether or not setting ENV{ID_MM_CANDIDATE}=1 is of any importance, you should temporarily move away 80-mm-candidate.rules , then see (in syslog ) if then ModemManager ignores /dev/ttyUSB1 nebo ne. I suspect “not”.

And then, well, maybe you can use a working version, such as 14.04, and if you need, perhaps run 15.10 in a virtualbox, unless of course it’s already all is in a virtualbox.

I think I need to claim defeat at this point.