GNU/Linux >> Linux の 問題 >  >> Ubuntu

USBモデムが接続しようとすると「ip-config-unavailable」エラーが発生しますか？

以前は正常に動作していたZTEMF-193Eモデムを持っています。このモデムを1年以上前に購入したときは、箱から出してすぐに機能しました。
現在、Ubuntuのバージョンが進むにつれて、状況はますます困難になっています。

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

モバイルブロードバンド接続を設定しました。 APNでさまざまな文字列を試しましたが、これは以前は問題になりませんでした。

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

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

Mobile Broadband Network: you are registered on the home network

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

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

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

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

ただし、これが適切かどうかはわかりません。


/ var / log / syslogからのその他の行 ここで見つけることができます。

更新1–2015年12月6日

ある親切なメンバーが指摘したように、 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

画面（ターミナル）に出力がありません。

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

更新3–2015年12月6日

インストールされたofono その後、モデムを再試行しました。

こちらのログをご覧ください。

更新4–2015年12月6日

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

systemctl restart network-manager.service

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

更新5–2015年12月6日

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

接続してみました。運がない。

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

続いてsudosystemctl restart network-manager.service 。

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

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

ログはこちらです。

更新6–2015年12月6日

実行済み

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のコマンドとは多少異なります。

ログファイルはこちらです。

更新7–2015年12月7日

再度実行（ /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 も含まれています。

ログファイルはこちらです。

更新8–2015年12月8日

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

更新9–2015年12月8日

テスト1

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

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

  3. 切り替えが完了するとすぐに、
    モバイルブロードバンドネットワークに参加していることが通知されました。 およびネットワークマネージャメニューの新しいブロードバンド接続の表示
    。

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

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

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

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

テスト2

Ubuntu14.0464ビットDVDを使用した同じテスト。

ログはここにあります。

更新10–2015年12月9日

今回はwvdialでテストしました wvdial の場合、 ルートとして実行されます。
成功します 接続。

wvdial confとlog、および対応するsyslogはここにあります

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

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

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

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

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

したがって、ユーザーはすでに
指定されたグループのメンバーです。

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

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

更新11–2015年12月9日

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

ここでsyslogを見つけてください。

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

更新12–2015年12月10日

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

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

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

syslogファイルはここにあります。

更新13–2015年12月10日

絶望的な状況から、ローカルの変更が接続に影響を与えているかどうかを確認するために、Ubuntu15.04および15.10DVDを使用してマシンをテストしました。

  1. Xubuntu15.0464ビットDVDを使用してマシンを起動しました。接続は魅力のように成功しました。
  2. Ubuntu15.1064ビットDVDを使用してマシンを起動しました。以前と同じように接続に失敗しました。

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

とてもイライラします。

更新14–2015年12月10日

  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. モデムを取り出しました。

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

syslogファイルと作成されたルールファイルはここにあります。

更新15–2015年12月11日

  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）はここにあります。

更新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）はここにあります

更新17–2015年12月11日


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

    # 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. モデムを取り出しました。

関連：15.10から16.04 aptへのアップグレードがインストールされていませんか？

syslogファイルと前述のルールファイル（40）はここにあります

更新18–2015年12月11日

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

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

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

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

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

タイムスタンプ付きのlsusbのsyslogファイル 出力と言及されたルールファイルはここにあります。

ここで、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. Xubuntu15.0464ビットDVDを使用してマシンを起動しました。

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

    差分ファイルを調べても、 idProductは表示されません。 1232または2003。

  4. 実行されたdiff40-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をUbuntu15.10にアップグレードしてみて、どこで壊れているかを確認することもできました。私は実際に試しましたが、無限の依存関係の問題のために諦めました。

上記のすべてのdiffファイルはここにあります。

更新20–2015年12月12日

テスト1

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

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

  3. udevadmキャプチャのデバッグとセットアップのためにModemManagerをセットアップします。

    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のルールファイルが
ここにあります。

すべてのログファイルにタイムスタンプが付いていて、照合が簡単になっているといいのですが。

更新21–2015年12月15日

  1. 提案どおりにルールファイルを変更しました。
  2. マシンを再起動しました。
  3. モデムを挿入して接続を試みました。うまくいきませんでした。

ルールファイルとsyslog ここにあります。

更新22–2015年12月16日

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

  1. 4.2.8-040208-一般的な障害。

  2. 4.1.15-040115-一般的な障害。

  3. 4.0.9-040009-一般的な失敗。

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

更新23–2016年2月16日

モデムはUbuntu16.04で機能を開始しました。このバージョンはまだAlpha1ですが、私のラップトップでは正常に動作します。

承認された回答：

ofonoを読み込んでいます パッケージはおそらくうまくいきましたが、どうやらあなたのモデムモデル、ZTEMF193EはZTEリストにありません。 MF190Jなどの他のZTEモデムと比較すると、このモデムには同じ特別な udevが必要になる可能性があります。 ルール、 usb_modeswitchを実行する ドングルが挿入されたら、それを実現するために、rootとして新しい 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」ではなく「wap」を使用するように構成を変更することで、簡単にテストできます（おそらく除外できます）。以前にこれを試したことがあるかもしれませんが、当時は ofonoがありませんでした パッケージなので、2番目のオプションの可能性が高くなりますが、別のテストが問題になることはありません。

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

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

編集2

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

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

問題は、ModemManagerがapn ='wap'でPDPコンテキスト1を選択し、apn='WAP'でPDPコンテキスト9を選択する必要があることです。たぶん、これはそれらのツールの1つを使用することで対処できます。接続中に9を強制的に選択できるようにするか、モジュールテスターツールが可能であると宣伝されているモデムから不正な「wap」コンテキストを削除することによって。

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

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

編集3

よろしくお願いします！ DVDからテストします。それは、私がAPNで間違った方向に進んでいること、そしてそれはすべてpppを起動させることにあることを私たちに教えてくれました。少なくとも、それは吠える私の新しい木になるでしょう。

関連：デスクトップの電力使用量を見つけるためのソフトウェア？

まず、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 別の場合;両方ともrootとして実行されます。別の動作があるかどうかを確認するだけです。特に、 ttyUSB1を使用する場合 は問題ですが、ttyUSB3の使用は問題ではありません。その場合は、ModemManagerにttyUSB3を使用させる方法も検討することをお勧めします。その他のテスト結果については、pppランドでフェレットを追いかけることに戻ります。

編集6

dmesgログは無視できると思います。すべてのログでそのようになっています。
新しいsyslogはttyUSB3テストのみを表示しますが、 NetworkManager を使用すると、生活が改善されると考えられます。 ttyUSB3を使用し、ttyUSB1を無視するように指示することができます（このモデムの場合）。

私はまた（https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/819784）、特に投稿＃10の当惑を見つけました🙁

明らかに適用可能なudev /lib/udev/rules.d/77-mm-zte-port-types.rulesのルール 適用されませんが、おそらくどこに行くべきかです。そして、 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プラグインのインストールに失敗する最初の部分がありません。ただし、とにかく汎用モデムプラグインが使用されていることは明らかです。さて、それは usb_modeswitch かもしれません 私が早くからあなたに与えた規則も間違っています。 からに切り替えることにしました からに切り替わったと思ったときの「2003」 「2003」。ただし、 man usb_modeswitch （前に見ておくべきだった）ある種、それがにシフトすることを示唆している fromではなく商品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. セットアップ/lib/udev/rules.d *-RALPH.rulesの有無にかかわらず ファイル
  2. デバイスを引き出します
  3. 再起動
  4. udevadmキャプチャのデバッグとセットアップのためにModemManagerをセットアップします
  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 最も近い後続のModemManagerを表示します 3867.437412とスタンプされたカーネルログ行の直後のログ行 。

私の考えでは、 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 次に、 1449934745.450398での事前調査が行われます。 、つまり、87ミリ秒後、カーネル時間で 3867.524519に近くなります。 上記の「良い」UDEVイベントレポートの55ミリ秒前。

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

関連：15.04にアップグレードした後の読み取り専用ファイルシステム？

これを解決する1つの可能性は、 80-mm-candidate.rulesの「tty」ルールを変更することです。 あるべき：

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

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

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

一般的に、 udevについてはよくわかりません。 ルールの順序付け。これでModemManagerが本当に停止するかどうかもまったくわかりません。 あまりにも速く行動することから。ただし、そうでない場合は、 80-mm-candidate.rules 機能がほとんどないかまったくない場合、おそらくすべてが ModemManagerの「改善」に帰着します。 15.04から。

21を編集

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

515.558184の間にはまだほぼ1秒あります および516.381549 ここで、 ModemManager 熱心にそして誤って/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 か否か。 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.


Ubuntu

  1. 起動時にVPNに接続しようとするとエラーが発生しますか？

  2. Virtualbox UsbデバイスエラーNs_error_failure（0x80004005）Ubuntu 14.04 X64 Virtualbox 4.3？

  3. Ubuntu 13.04はUSBモバイルブロードバンドモデムをイーサネット接続として認識しますか？

  1. USB 3フラッシュドライブを接続するとコンピューターの速度が低下しますか？

  2. 18.04でYoutube-dlを更新しようとするとエラーが発生しますか？

  3. Ubuntu 16.04にNginxをインストールするときにエラーが発生しますか？

  1. Tata Photon +UsbモデムHuaweiEc156を構成しますか？

  2. /var/log/messages、/var/log/syslog、および/var/log/kern.logの違いは？

  3. USB Wifiは検出されましたが、接続できませんか？