web-dev-qa-db-ja.com

USBモデムが接続を試行する際の「ip-config-unavailable」エラー

ZTE MF-193Eモデムを以前に正常に動作させました。 1年以上前にこのモデムを購入したとき、すぐに使用できました。現在、Ubuntuのバージョンが進歩するにつれて、事態はますます困難になっています。

このモデムは、Ubuntu 15.04（64ビット）で数か月前まで動作しました。現在、Ubuntu 15.10（64ビット）では、接続できません。

モバイルブロードバンド接続のセットアップ があります。 APNでさまざまな文字列を試しましたが、これは以前は問題ではありませんでした。

（Windows 10ではモデムが正常に動作するため、これはハードウェアの問題ではありません。また、 モデムマネージャーGUI このデバイスを適切に検出します。SMSを送受信できます。問題なく）。

モデムを挿入すると、問題なく検出され、Unityにモデムの名前とともにCDアイコンが表示されます。数秒後、メッセージボックスが表示されます

Mobile Broadband Network: you are registered on the home network

ネットワークアイコンの近く。

接続しようとすると、ネットワークマネージャーアプレットのワイヤレスアイコンがこれらの遠心運動を開始しますが、最終的に接続に失敗し、オフラインであるというメッセージが表示されます。

/var/log/syslogから分離できる行はこれです。

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

ただし、これが関連するものかどうかはわかりません。

/var/log/syslogのその他の行は here にあります。

Update 1-December 06 2015

あるメンバーが指摘したように、nf_conntrack_pptpモジュールアプローチを試してみました。

次のコマンドを実行しました、

$ 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

その後、同じモデムでモデムを試しました。ログにも識別可能な変更はありません。

更新2-2015年12月6日

ルートとして実行され、

systemctl restart network-manager.service

画面（端末）に出力がありません。

上記のポイントからモデムを使用して接続しようとするログに対応するログは、 here にあります。

Update 3-December 06 2015

ofonoをインストールしてから、モデムを再試行しました。

ログを参照してください こちら 。

更新4-2015年12月6日

再びルートとして実行され、

systemctl restart network-manager.service

上記のポイントからモデムを使用して接続しようとするログに対応するログは、 here にあります。

Update 5-December 06 2015

/etc/dbus-1/system.d/nm-dispatcher.confのすべての「拒否」を「許可」に変更しました。

接続しようとしました。運がありません。

いくつかのネットワークは、イーサネット接続で接続および切断します。

その後にSudo systemctl restart network-manager.serviceが続きます。

モデムのプラグアウトとプラグイン。

もう一度接続してみました。接続しません。

ログは here です。

Update 6-December 06 2015

実行済み

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

そして

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

複数のエラーのため、mm-test.pyを実行できませんでした。指定された場所でファイルを見つけました。 https://github.com/openshine/ModemManager/blob/master/test/mm-test.py から取得しました。

上記のコマンドは、Wikiのコマンドとは多少異なります。

ログファイルは here です。

Update 7-December 07 2015

再度実行（/lib/udev/rules.d/40-usb_modeswitch.rulesで提案された変更と再起動後）

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

そして

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

/var/log/syslogも含まれています。

ログファイルは here です。

Update 8-December 08 2015

更新されたログのセットは ここ です。

アップデート9-2015年12月8日

テスト1

  1. 今回は、Ubuntu 14.04 32ビットDVDからコンピューターを起動しました。コンピューターが起動するとすぐに、MMログのキャプチャを開始しました。

  2. モデムを挿入しました。 lsusbは、19d2：2003デバイスに切り替える必要がある19d2：1232デバイスとして認識されていることを示しました。 usb-modeswitchのインストールにはマシンの再起動が必要であるため（したがって、DVDの実行のインストールが失われます）、カスタムスイッチファイルを準備し、コマンドライン（Sudo usb_modeswitch -I -c 19d2:2003）からモデムを切り替えました。

  3. 切り替えが完了するとすぐに、ネットワークマネージャーメニューでMobile Broadband Networkと新しいブロードバンド接続を使用していることが通知されました。

  4. 上記の接続を通常の方法で設定し（APN名は問題ではありませんでした）、接続は自動的に確立されました。

  5. モデムを取り外して取り出しました。

  6. MMログのキャプチャを停止しました。

セッション開始からモデムイジェクトまでの完全なMMログとsyslogは here にあります。

テスト2

Ubuntu 14.04 64ビットDVDを使用した同じテスト。

ログは here にあります。

更新10-2015年12月9日

今回はwvdialでテストし、wvdialをrootとして実行すると、successful接続が得られることがわかりました。

wvdial confおよびlog、および対応するsyslogは here です

主な推測：状況は、対応するユーザーのユーザーグループに関係している可能性があります。

しかし、示されているように ここ 、

これらすべてのツールを使用して、ダイヤルアップ接続を確立するには、ユーザーは「dip」および「dialout」グループのメンバーである必要があるため、ダイヤルアップ経由で接続するすべてのユーザーをこれらのグループに入れます。

しかし、見つけることができるように、

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

そのため、ユーザーはすでに指定されたグループのメンバーです。

さて、おそらく問題はこれらのポイントのいずれかに要約されます。

  1. ユーザーはどの追加グループに必要ですか？
  2. ルートとしてモバイルブロードバンド接続セットアッププロセスを実行するにはどうすればよいですか？ （セキュリティ上の問題？）

アップデート11-2015年12月9日

wvdialはUSB3で動作し、USB1ではnot動作します。

Syslog here を見つけてください。

dmesg | grep tty > /tmp/dmesg.tty.txtの出力も含まれています。しかし、ファイルの先頭近くにあるこれらの4行を参照してください。

アップデート12-2015年12月10日

  1. SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end"の4行目（/lib/udev/rules.d/77-mm-zte-port-types.rules）をコメントアウトしました。

  2. マシンを再起動しました。ケーブルをソフト切断し、モデムを挿入しました。

  3. 接続しようとしました。失敗しました。

Syslogファイルは here です。

アップデート13-2015年12月10日

まったくの絶望から、ローカルの変更が接続に影響を与えているかどうかを確認するために、Ubuntu 15.04および15.10 DVDでマシンをテストしました。

  1. Xubuntu 15.04 64ビットDVDでマシンを起動しました。接続は魅力のように成功しました。
  2. Ubuntu 15.10 64ビットDVDでマシンを起動しました。接続は以前と同様に失敗しました。

15.04と15.10の間に何が起こったのですか？

とてもイライラします。

2015年12月14日-14日更新

  1. 回答の指示に従って、新しいファイル/lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesを作成しました。

  2. マシンをリブートしました（またはSudo udevadm control --reloadを実行し、実際に両方を試しました）。モデムを挿入しました。

  3. モデムが認識されました。

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

  4. ケーブルをソフト切断し、モデムを使用して接続しようとしました。失敗しました。

  5. モデムを取り出しました。

マシンが一度ハングする、それはランダムなイベントですか？私のマシンは通常、年に一度ハングしません。

Syslogファイルと作成されたルールファイルは here です。

2015年12月15日-15日更新

  1. /lib/udev/rules.d/40-usb_modeswitch.rulesに次の行を追加しました。

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

  2. ファイル/lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesをそのまま残します。

  3. マシンを再起動しました。モデムを挿入しました。

  4. モデムが認識されました。

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

  5. ケーブルをソフト切断し、接続しようとしました。失敗しました。

  6. モデムを取り出しました。

  7. /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesを削除しました。

  8. 再起動し、プロセス全体を再試行しました。再び失敗しました。

Syslogファイル（完全、重要な部分を見落とす危険はありませんでした）および言及されたルールファイル（40）は here です。

更新日16-2015年12月11日

  1. /lib/udev/rules.d/40-usb_modeswitch.rulesに1232ルールを1つだけ残し、もう1つを削除しました。

  2. Sudo udevadm control --reloadを実行しました。

  3. モデムを挿入しました。

  4. モデムが認識されました。

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

  5. ケーブルをソフト切断し、接続しようとしました。失敗しました。

  6. モデムを取り出しました。

しかし、上記のデフォルトシステムをテストしませんでしたか？ /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesをその場所に残すつもりでしたか？

Syslogファイル（完全、重要な部分を見落とす危険はありませんでした）および言及されたルールファイル（40）は here です

2015年12月17日更新17

  1. /lib/udev/rules.d/40-usb_modeswitch.rulesの1232ルールをコメントアウトし、2003年のルールを追加しました。

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

  2. Sudo udevadm control --reloadを実行しました。

  3. モデムを挿入しました。

  4. モデムは1232デバイスとして認識されました。接続を試みることは提案されていません（私の知る限り、2003年に切り替えが行われない限り、ブロードバンドネットワークに登録されません）

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

  5. モデムを取り出しました。

Syslogファイルと前述のルールファイル（40）は here

更新日2015年12月18日

  1. すべてのルールファイルを元の形式で配置します。

  2. シェルスクリプトを使用して1秒ごとにlsusb出力を監視しました。タイムスタンプ付きファイルで出力をキャプチャしました。

  3. モデムを挿入しました。 （モデムは最初にlssuboutouput.Fri Dec 11 16:56:29 BDT 2015.txtファイルに表示されます）。キャプチャからわかるように、1232デバイスから2003デバイスに切り替えることは明らかです。

  4. 接続しようとしました。失敗しました。

  5. モデムを取り出しました。

Syslogファイル、タイムスタンプ付きlsusb出力、および言及されたルールファイルは here です。

ここで、syslog出力をタイムスタンプと一致させることができます。

更新日19-2015年12月11日

問題を特定できるように、このテストを完全に新しい方向で実行しました。

  1. ポータブルメディア/lib/udev/rules.d/40-usb-media-players.rulesおよび/lib/udev/rules.d/77-mm-zte-port-types.rules（Ubuntu 15.10マシンから）に保存されます。

  2. Xubuntu 15.04 64ビットDVDを使用してマシンを起動しました。

  3. diff 77-mm-zte-port-types.rules /lib/udev/rules.d/77-mm-zte-port-types.rules > diff15.10and15.04_77-mm.txtを実行しました。最初のファイルは、15.10から保存されたファイルです。

    Diffファイルを調べると、idProduct 1232または2003は表示されません。

  4. diff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules > diff15.10and15.04_40-usb.txtを実行しました。繰り返しますが、最初のファイルは15.10から保存されたものです。

    繰り返しますが、diffファイルを調べると、idProduct 1232または2003は表示されません。

  5. モデムを挿入しました。モデムがモデムとして認識されました。

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

  6. モバイルブロードバンド接続を設定した後、すぐに接続できます。

  7. モデムを取り出しました。

  8. 最新のUSB_ModeSwitchをインストールしました。

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

    期待どおりにNULLを返します。

  9. Sudo udevadm control --reload-rulesを実行しました。

  10. モデムを挿入しました。モデムがモデムとして認識されました。

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

  11. すぐに接続できました。

MMとNMをUbuntu 15.10にアップグレードして、どこが壊れているのかを確認することもできました。私は実際に試してみましたが、無限の依存関係の問題のためにgaveめました。

上記のすべてのdiffファイルは here です。

2015年12月20日更新20

テスト1

  1. 元の状態の/lib/udev/rules。

  2. このセッションでは、モデムデバイスはまだ挿入されていません。

  3. ModemManagerをデバッグ用にセットアップし、udevadmキャプチャをセットアップします。

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

  4. モデムに接続し、ブロードバンドネットワークに登録されていると表示されるまで待機しました。

  5. 接続に失敗しました。

  6. モデムを取り出しました。

  7. 圧縮されたログファイル。

テスト2

/lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesを使用して上記のテストを繰り返しました。

ログファイル名は一目瞭然です。

上記のすべてのログファイルとsyslogおよび78のルールファイルは here です。

すべてのログファイルにタイムスタンプが付いていて、マッチングが容易になることを願っています。

更新日2015年12月15日

  1. ルールファイルを提案どおりに変更しました。
  2. マシンを再起動しました。
  3. モデムを挿入し、接続してみました。うまく行かなかった。

ルールファイルとsyslogは ここ です。

2015年12月22日更新-22

1つのコメントでアドバイスされているように、 http://kernel.ubuntu.com/~kernel-ppa/mainline/ からさまざまなカーネルをインストールし、それぞれで起動した後にモデムを使用して接続を試みました。

  1. 4.2.8-040208-generic、失敗。

  2. 4.1.15-040115-generic、失敗。

  3. 4.0.9-040009-汎用、障害。

したがって、おそらく、カーネルの問題を除外できます。

2016年2月23日更新-2016年2月16日

Ubuntu 16.04でモデムが機能し始めました。このバージョンはまだAlpha 1ですが、私のラップトップでは問題なく動作します。

networkingnetwork-managerusb-modemmodemmobile-broadband
12
Masroor

Ubuntu 16.04でモデムが機能し始めました。このバージョンはまだ開発段階ですが、私のラップトップでは正常に動作します。

それがどのように機能し始めたかについて、より技術的な詳細を提供できればと思います。

1
Masroor

ofonoパッケージのロードはおそらくうまくいきましたが、おそらくモデムモデルのZTE MF193EがZTEリストに載っていないようです。 MF190Jなどの他のZTEモデムと比較すると、このモデムは、ドングルが挿入されたときにusb_modeswitchを実行し、ルートとして新しいudevルールをファイルに追加するために、同じ特別なudevルールを必要とする可能性が高い
/lib/udev/rules.d/40-usb_modeswitch.rules
次の2行で、たとえば# ZTE MF190Jコメントの近くに：

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

空白行を追加すると、見た目が快適になります。

おそらく再起動するのが賢明です。すべてが魔法のように機能することを見つけるためだけです:-)

か否か。ご存知のように、これは私にとって深い水ですが、それでもうまくいかない場合は、別のModemManagerデバッグログが必要になります。

編集：

私は現在、modemmanager.txtの2行を見ています。

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

そして

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

前者はブロードバンドのセットアップを指し、後者は「PDPコンテキスト」への内部バインディングを指します（それが何であれ）。見た目では、モデムはapn='WAP'を含む9つの代替コンテキストを提供しますが、ModemManagerは大文字と小文字を区別しない一致を解決します。

大文字と小文字の違いがその後の問題の原因である可能性があります：たとえば、pppが'wap'の設定（'WAP'ではなく）を望んでいて、それを見つけられない、またはリモートエンドがapn='WAP'を期待しているが、それがチョークする「スワップ」を取得する、などです。

最初のオプションは、「WAP」ではなく「wap」を使用するように構成を変更することで、簡単にテストできます（おそらく除外されます）。以前にこれを試したことがあるかもしれませんが、その時点ではofonoパッケージなしで、別のテストが問題になることはありませんが、2番目のオプションがより可能性が高くなります。

2番目のオプションも、モデムから使用可能な大文字の「PDPコンテキスト」一致があることを考えると、より問題です。この問題をグーグルでは、大文字と小文字を区別しない一致は（明らかに関連する）仕様「3GPP TS 23.003章9.1」によって正しいようであり、これを行うためのパッチが昨年11月にModemManagerに追加されました（バージョンmm-1-4 、私は収集することができます）。したがって、この場合、モデムは通知されておらず、大文字と小文字を区別するマッチングを想定していますが、残念ながらModemManagerはフォールバックとしてではなく、大文字と小文字を区別しないマッチングをまっすぐに使用します。

2番目の問題の解決策の1つは、当然、別のModemManagerを使用することです。このパッチより前のバージョンを見つけてインストールするか、（十分な時間をかけて）独自のModemManagerをロールします。しかし、どちらも気まぐれなことではないので、これを（現在）問題であるという証拠を得るために少し調べて、可能であればそれを回避する他の方法を見つける必要があるかもしれません。または少し運が良ければ、何かを知っている人が立ち寄ります...

編集2

はい、依存関係のため、バージョンのロールバックは簡単ではありません。そして、自分で転がすことも喜びとはほど遠い。

2つの可能な便利なツール：コマンドmmcliおよび（ http://m2msupport.net/m2msupport/module-tester/ ）。

問題は、ModemManagerがapn = 'WAP'でPDPコンテキスト9を選択するのに、apn = 'wap'でPDPコンテキスト1を選択することだと思います。たぶん、これらのツールのいずれかを使用して対処できます。接続中に強制的に9を選択できるようにするか、またはモジュールテスターツールで実行できるようにアドバタイズされているモデムから不適切な「wap」コンテキストを削除します。

モデムテスターツールはブラウザのJavaツールのように見えるので、Javaがどこにあるかを知るためにブラウザをセットアップする必要があり、そのJava知っておくべきこと。次に、そのアプローチを検討してください。自分では使っていませんが、スクリーンショットを見ると、PDPコンテキストが「データコール」タブとして表示され、最初に表示されるすべてのものをメモしてから、「wap」エントリを編集して「wap」apnラベルを、例えば「wap1」と「wap2」に変形します（「WAP」を探すときに「非表示」になるように）。その後、保存して閉じ、ドングルを再度ジャグリングします。ログを取得します。まだ再生を拒否する場合は、syslogで十分なようです。

mmcliコマンドも、この話で役立つようです。 man mmcliを読んでそれについて読んでみましたが、PDPコンテキストについては何も見ませんでした。

編集3

いいね！ DVDからテストします。それは私がAPNで間違った軌道に乗っており、すべてがpppを起動することにあることを教えてくれました。少なくとも、それはmyえる私の新しいツリーになるでしょう。

まず、pppdのバージョンの違い（2.4.5から2.4.6）に注意してください。ただし、ドングルにいる全員がこのエクスカーションに参加していたので、おそらく問題ではないでしょう。

うーん、ppp;私は最後の千年の記憶をかき立てる必要があります:-)。あいにく今日は忙しいですが、次に時間があるときにベースに触れて、あなたがどこまで来たかを確認します。私が最初に検討すべき路地は次のとおりです。1）ユーザーは適切なグループに属しますか？ 2）資格情報は正しいですか？ 3）ppp/chat構成ファイルのmodは正しいですか？ pppデバッグログはnm.txtに出力されます（数日前）が、より詳細なログを要求する方法も必要です。

編集4

/etc/ppp/pap-secretsおよび/etc/ppp/chap-secretsがグループdip（必要に応じてchgrpを使用）およびモード740（または-rw-r-----）（必要に応じてchmodを使用）を持っていることを確認します。私はしませんでした。

編集5

このツリーについてはどうでしょうか。動作しているwvdial syslogと動作していないsyslogを比較すると、何らかの理由でwvdialがttyUSB3を使用している一方で、動作していないModemManagerがttyUSB1を使用し続けているようです。それがまったく重要かどうかはわかりませんが、明らかにttyUSB1とttyUSB3は両方ともAT対応モデムとして応答します。

したがって、テストとして、/etc/wvdial.confを編集して、[Dialer Defaults]の下に次の行を含めることができます。

Modem = /dev/ttyUSB1

1つのテスト用、およびttyUSB3別のテスト用。両方ともルートとして実行されています。別の動作があるかどうかを確認するだけです。特に、ttyUSB1の使用が問題であるのにttyUSB3の使用が問題でない場合は、ModemManagerでttyUSB3を使用する方法を検討するとよいでしょう。他のテスト結果については、ppp landでフェレットを追いかけることに戻ります。

編集6

Dmesgログは無視できると思います。すべてのログでそうでした。新しいsyslogはttyUSB3テストのみを表示しますが、NetworkManagerがttyUSB3を使用してttyUSB1（このモデムの場合）を無視するように求められると、寿命が長くなると推測できます。

また、特に＃10の混乱を伴う（ https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/819784 ）が見つかりました:

/lib/udev/rules.d/77-mm-zte-port-types.rulesの明らかに適用可能なudevルールは適用されませんが、おそらくどこに行くべきでしょう。そして、udevマジックについての非常に初歩的な101以前の洞察だけで、私はとにかくその4行目に疑問を投げかけることを検討します。

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

コメントアウトするには、その行に最初の#が必要だと思います。詳細には、このファイルを読むと、「2003」製品ルールを含む適切なビットを使用するために、少なくともテストのために、SUBSYSTEM == "tty"およびSUBSYSTEMS = "usb"の呼び出し状態が必要です。 「tty」フィルタリングをスキップしても安全です。そして今、私にはこれ以上良いものはありません。

編集7

お気に入りの検索エンジンで十分な時間を過ごした後、ttyUSBの選択が根本的な問題であるともう少し信じています。私が指摘したudevルールは大丈夫です。その編集を元に戻す必要があります。

しかし、製品ID「2003」の場合、そのファイルの終わりに向かう構成規則は誤解を招くと信じ始めました。ログから、製品ID「2003」は実際にはドングルのメモリデバイス側であるのに対し、モデム側は製品ID「1232」であるように見えます。これをテストするには、ファイル/lib/udev/rules.d/77-mm-zte-port-types.rulesで製品ID「1232」の2つの「2003」ルールを複製します。

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"

または、その横に新しいファイルを追加します。 78-ralph.rulesという名前ですが、その周りにSUBSYSTEMおよびSUBSYSTEMS保護も追加する必要があります。

次に、ドングルを引き出し、udevadm control --reloadを実行（または再起動）して、ドングルを挿入します。そして、今度はうまくいかない限り、さらに別のsyslogキャプチャー。

ただし、効果的な問題は、ModemManagerが事前調査時にプラグインlibmm-plugin-zte.soを破棄し、一般的なモデムハンドラを使用してしまうことです。製品IDが正しい場合、これが理由である可能性があります。その事前調査はID_MM_ZTE_PORT_TYPE_MODEM属性を探しますが、これは製品ID "1232"（パッチの前）に欠けており、zteプラグインは破棄されます。

編集8

syslogログは少し短いです。 ModemManagerがzteプラグインのインストールに失敗する最初の部分がありません。しかし、とにかくGenericモデムプラグインが使用されていることは明らかです。さて、私が早くあなたに与えたusb_modeswitchルールも間違っているかもしれません。 from "2003"に切り替えたと思ったときにto "2003"に切り替えることにしました。しかし、man usb_modeswitch（前に見ておくべきだった）は、from itではなくto製品IDにシフトすることを示唆しています。いずれにせよ、ログはそれが起こることを示しています。したがって、代わりに「1232」を使用するようにそのルールを変更し、もう一度やり直してください。

少なくとも、udevについて少し学ぶ必要があります。

編集9

良い。問題は、（または）ModemManagerが事前調査時にZTEプラグインを削除することです。 15.10のModemManagerデバッグログ（ログセット "debuglogs *"）はすべて、vendor-id/product-idテストのためにZTEプラグインが破棄されることを物語っています。

ソースに移動、ルーク！この機会にModemManagerのソースコードを簡単に確認しましたが、プラグインが19d2/2003を含まないvid/pidのテーブルとして示されています...ただし、そのテーブルソースが見つからなかったため、確認できませんでした。

または、ここにタイミングの問題があるかもしれません。たとえば、デバイスが19d2/1232の間、ModemManagerは事前調査を実行します。この考えは、78-mm-zte-port-types-RALPH.rules udevルールを持つことで、ModemManagerがデバイスで少し幸せになるという観察と一致しています。しかし、デバイスが19d2/2003に切り替えられたとき、なぜそれが幸せのままで、そのプラグインを利用しないのでしょうか？

たぶん、より多くのログが必要です:-) ModemManagerをデバッグし、デバイスを接続するときにコマンドudevadm monitor --e |& tee udevadm.log（別の端末で）をキャプチャします。そのコマンドは（---（https://wiki.ubuntu.com/DebuggingUdev ）から取得しました

これを2回実行します。1回は78-mm-zte-port-types-RALPH.rulesなしで、もう1回はルール付きです...両方とも、再起動後の2回です。つまり.

  1. /lib/udev/rules.dファイルの有無にかかわらず*-RALPH.rulesをセットアップする
  2. デバイスを引き出す
  3. リブート
  4. デバッグ用のModemManagerのセットアップおよびudevadmキャプチャのセットアップ
  5. デバイスを接続し、1分間待ちます
  6. ログファイルを圧縮する
  7. 次のテストで1から繰り返す

そのロギングは、ZTEプラグインがドロップされた場所を示す必要があり、私が理解しているように、udevイベント処理についても通知します。

編集10

（私はここでテザーの終わりに近づいていますが、あと1、2回息が残っています:-)

まず、すべてのudevの装飾は、いくつかの属性にいくつかの疑問符が付いているだけで、本来あるべき姿になっているように見えます。特に、78-*-RALPH.rulesは破棄する必要があります。役に立たない。

私はこれから何かを読むことができると思うが、それがどのように修正されるべきか正確にはわからない。基本的に、私が見ているように、ドングルが差し込まれたとき、udevイベントが突然発生します。 ttyUSB1に関するものに注目すると、「初期」イベントがあります。

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

usb_serialドライバーがロードされ、/dev/ttyUSB1が表示されます。それは特に別のイベントを引き起こします：

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

それはModemManagerもトリガーすると思います。ログ間に厳密な相関関係がないため、syslogに移動してこの証拠を確認する必要があります。このイベントには、3867.435102のタイムスタンプが付けられ、syslogは、3867.437412のスタンプが付けられたカーネルログ行の直後に、それに最も近い後続のModemManagerログ行を示します。

私の考えでは、ModemManagerはまだトリガーされるべきではなく、後続のttyUSB1イベントの後にのみトリガーされるべきです。

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

zTE属性が付加されています。

MMログでは、1449934745.363291とスタンプされた行にあります。これは、明らかに「カーネルタイム」スタンプではなく「リアルタイム」タイムスタンプです。

その後、ModemManagerは、その事前プローブat1449934745.450398、つまり87ミリ秒後に行われます。これは、カーネル時間で言えば、3867.524519に近く、上記の「良い」UDEVイベントレポートの55ミリ秒前です。

syslogでは、ModemManagerがttyUSB1に属性が設定されていないという苦情を申し立てていることに注意してください。おそらくその苦情は80-mm-candidate.rulesで発生する「マーキング」に関連している可能性があります。そのファイル内のコメントから、そのマーキングはこの問題に正確に対処しようとするように見えますが、そうであれば、この場合は機能しないようです。

これを解決する可能性の1つは、80-mm-candidate.rulesの「tty」ルールを次のように変更することです。

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

私の考えでは、ZTE属性が設定されるまでID_MM_CANDIDATE設定が遅延することを保証します。 .ID_PORT設定は60-serial.rulesルール（以前は60-persistent-serial.rulesと呼ばれていました）の効果であり、マーキングルールに追加された条件は単に値があることです。

条件は、ルールをより一般的に保つためだけに、厳密にはZTE属性ではありません。ここでの割り当てはENV{.MM_USBIFNUM}="?*"によって行われるため、より具体的な1つのステップは、代わりに77-mm-zte-port-types.rulesを要求することです。

一般に、udevルールの順序についてはよくわかりません。また、ModemManagerがあまりにも速く動作するのを本当に止めるかどうかもまったくわかりません。ただし、そうでない場合、80-mm-candidate.rulesの機能はほとんどないか、15.04からModemManagerへの「改善」に至る可能性があります。

編集21

はぁ。おそらく無関係ですが、7-zte-mutil_port_device.rulesファイルを確認することをお勧めします。それは他の実験からの残骸ですか？とにかく、ここでは関係ありません。

515.558184と516.381549の間にはまだ1秒近くあります。ここでModemManagerは熱心に誤って/dev/ttyUSB1をつかみ、セットアップされていないという不満を訴えながら、事前調査を行ってZTEプラグインを破棄します。つまり、ルールパッチはModemManagerを待機させません。

ENV{.MM_USBIFNUM}="?*"の代わりにENV{.ID_PORT}=="?*"を使用してテストしたと思います。

実際、ENV{ID_MM_CANDIDATE}=1の設定が重要であるかどうかを確認するには、一時的に80-mm-candidate.rulesから離れ、syslogが/dev/ttyUSB1を無視するかどうかを（ModemManagerで）参照する必要があります。 「ない」と思う。

それから、14.04などの作業バージョンを使用できます。もちろん、必要に応じて、仮想ボックスで15.10を実行できます。

この時点で敗北を主張する必要があると思います。

4
Ralph Rönnquist

これを一見すると、このドラゴンが適切に対処されたのは今回が初めてではないようです。 12.10および13.04の以前はバグでしたが、おそらくバグが修正されなかったか、新しいパッチが以前に正常に動作していたものを壊しました。

技術仕様を正しく読んでいる場合、この方向（MF190J）を示す必要があります。

Gモデム（ZTE MF190J）は引き続き手動で調整する必要があります。

0
John75077