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


12

ZTE MF-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

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

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

私が隔離できる行/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

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

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

が続きsudo systemctl 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. 今回は、Ubuntu 14.04 32ビットDVDからコンピューターを起動しました。コンピュータが起動するとすぐに、MMログのキャプチャを開始しました。

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

  3. スイッチングが達成されたとすぐに、私は私が上だったと知らされたMobile Broadband Networkとネットワークマネージャのメニューの新しいブロードバンド接続appreard。

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

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

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

セッション開始からモデム取り出しまでの完全なMMログとsyslogは、ここにあります

テスト2

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

ログはここにあります


更新10-2015年12月9日

今回のテストでは、rootとして実行すると、接続が成功することがwvdialわかりました。wvdial

wvdialconfに、ログ、および対応するsyslogがあり、ここで

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

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

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

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

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

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

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

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

更新11-2015年12月9日

wvdialUSB3では動作し、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日

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

  1. Xubuntu 15.04 64ビットDVDでマシンを起動しました。接続は魅力のように成功しました。
  2. Ubuntu 15.10 64ビット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. モデムを取り出しました。

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

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. に1つの1232ルールのみを残し /lib/udev/rules.d/40-usb_modeswitch.rules、もう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. の1232ルールをコメントアウトし、/lib/udev/rules.d/40-usb_modeswitch.rules2003 年のルールを 追加しました。

    # 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)はこちら


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

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

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

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

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

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

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

ここで、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ファイルの検査では、idProduct1232または2003 は表示されません。

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

    繰り返しますが、diffファイルを調べるとidProduct1232または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ファイルはここにあります


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

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

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


アップデート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-generic、失敗。

  2. 4.1.15-040115-generic、失敗。

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

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


アップデート23-2016年2月16日

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


1
過去に同様の問題にぶつかり、DHCPを無効にし、携帯電話会社のゲートウェイアドレス番号を使用し、GoogleのDNSサーバーを使用することになりました。これは2、3年前のことであり、必要な正確な手順を思い出せず、これが同じ問題であるかどうかはわかりませんが、エラーはほとんど逐語的でした。もっと助けてほしい。
KGIII

1
@KGIIIこれを試してみたいと思います。1つのアイドルクエリだけで、DHCPと関係がある場合、Windowsでどのように機能しますか?DHCPサーバーは、アドレスを割り当てるときに違いを生じますか?さらに、同じLinuxマシン(モデムが接続に失敗する)は、イーサネットDHCPで動作します。とにかく、実生活での実験は、何千ものアイドル討論に値するでしょう。
マズロ

私はしたいと思い異なる方法でWindowsネットワークのハンドルを、すでにこの特定のハードウェアまたはハードウェアの種類に対処するように設定されている場合があります。最近Windowsにあまり注意を払っていないので、おそらくそのための最良の情報源ではないでしょう。
KGIII

@KGIIIアドレスを設定してみました。残念ながら、モバイルブロードバンド接続で使用できるオプションは、自動(PPP)の2種類のみです。だから、それは閉じた道です。とにかくありがとう。
マズロ

1
問題の原因としてのカーネルを排除するために、kernel.ubuntu.com / 〜kernel-ppa / mainlineから4.0および4.1カーネルをインストールしてテストしてみてください。
ムル

回答:


4

ofonoパッケージの読み込みはおそらくうまくいきましたが、明らかに、モデムモデルのZTE MF193EはZTEリストに載っていません。MF190Jなどの他のZTEモデムと比較すると、このモデムはドングルが挿入されたときudevに実行するために同じ特別なルールを必要usb_modeswitchとし、それを達成するために、rootとして 次の2つのudevファイル
/lib/udev/rules.d/40-usb_modeswitch.rules
で新しいルールを追加できます例えば、# 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コンテキスト」への内部バインディングを指します(それが何であれ)。見た目では、モデムはを含むものを含む9つの代替コンテキストを提供しますapn='WAP'が、ModemManager大文字と小文字を区別しない一致を解決します。

大文字と小文字の違いがその後の問題の原因かもしれません:たとえば、pppが'wap'(ではなく'WAP')構成を望んでいて、それを見つけられない、またはリモートエンドがを期待apn='WAP'しますが、「wap」を取得し、それが詰まる。

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

モデムから使用可能な大文字の「PDPコンテキスト」一致がある場合、2番目のオプションも問題になります。この問題をグーグルで検索すると、大文字と小文字を区別しない一致が(明らかに関連する)仕様「3GPP TS 23.003章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コンテキスト9を選択するのに、apn = 'wap'でPDPコンテキスト1を選択することだと思います。おそらく、これらのツールのいずれかを使用して対処できます。接続中に強制的に9を選択できるようにするか、モデムから不良の「wap」コンテキストを削除します。これは、モジュールテスターツールで可能なことがアドバタイズされます。

モデムテスターツールはブラウザのJavaツールのようです。そのため、Javaがどこにあるかを知るためにブラウザをセットアップする必要があり、そのJavaを知る必要があります。次に、そのアプローチを検討してください。私自身は使用していませんが、スクリーンショットを見ると、PDPコンテキストが「Data Calls」タブとして表示され、最初に表示されるすべてのものをメモしてから、「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て保持します。私はしませんでした。dipchgrp740-rw-r-----chmod

編集5

どのようにこの木については、次のようになります。作業の比較wvdial非稼働のsyslogをsyslogのを、いくつかの理由と思われるwvdial使用ttyUSB3非稼働しながら、ModemManager使用し続けますttyUSB1。それはすべての重要なのだが、どうやらけどどうかはわからないttyUSB1ttyUSB3ATが可能なモデムなどの両方応答。

だから、テストとして、多分あなたは/etc/wvdial.confそれを編集することができます[Dialer Defaults]の行を含める。

Modem = /dev/ttyUSB1

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

編集6

dmesgログは無視できると思います。すべてのログでそうでした。新しいsyslogにはttyUSB3テストのみが表示されますが、おそらく、NetworkManagerを使用して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」であるように見えます。これをテストするには、ファイル内の製品ID「1232」の2つの「2003」ルールを複製します。/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"

または、その横に新しいファイルを追加します。たとえば、 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私が早くあなたに与えた規則も間違っているかもしれません。それがスイッチすることを決定、私はそれが切り替わっと思ったときに、「2003」から「2003」。しかし、man usb_modeswitch(私が前に見てきたはずである)種類のそれがシフトすることを示唆しているではなく、製品ID からそれ。いずれにせよ、ログはそれが起こることを示しています。したがって、代わりに「1232」を使用するようにそのルールを変更し、もう一度やり直してください。

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

編集9

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

ソース、ルークに行きます!この機会を利用してModemManagerのソースコードを簡単に確認しましたが、プラグインが19d2 / 2003を含まないvid / pidのテーブルとして示されています...確認しません。

または、ここにタイミングの問題があるかもしれません。たとえば、ModemManagerは、デバイスが19d2 / 1232の間に事前調査を実行します。この考えは、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回はルールを使用します。すなわち

  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)

それもきっかけだと思いますModemManagersyslogログ間に厳密な相関関係がないため、この証拠を確認するために移動する必要があります。イベントは、タイムスタンプで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、「kernel time」スタンプではなく「real time」タイムスタンプであるように、スタンプされた行にあります。

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

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

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

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

私の考えでは、これによりID_MM_CANDIDATE、ZTE属性が設定されるまで設定が遅延します。この.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機能がほとんどないか、まったく機能しない可能性があり、それからすべてがModemManager15.04から「改善」に帰着するでしょう。

編集21

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

熱心にそして誤ってグラブする間515.558184とその間にまだ約1秒があり516.381549、セットアップされていないことについて不平を言っている間、まだ事前調査を経てZTEプラグインを破棄します。つまり、ルールパッチは待機しません。ModemManager/dev/ttyUSB1ModemManager

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

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

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

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


残念ながら、うまくいきませんでした。私の質問のログをご覧ください。
マズーロ

うーん。このログは、モデムレベルでは起動しているが、pppレベルでは失敗していることを示しています。プラグアウト/インジェスチャの場合、nm.txtログ、および場合によってはsyslogも発生しますか?ところで、私はあなたがモデムを接続するときにケーブル上にもないと思います。
ラルフロンキスト

同じ.zipファイルを更新し、さらに2つのログを含めました。私は、テストを行うときにケーブルを(ソフトに)切り離すことをポイントにします。ケーブルは以前に問題になったことはありませんが。以前は、旅行前にデータパックを購入した後、ケーブルを接続したまま自宅のマシン(PC)でモデムをテストし、ラップトップでモデムを使用していました。繰り返しますが、尋ねてくれてありがとう、それを確認しても害はありません。
マズロ

答えの私の編集に注意してください:次のワイルドな推測。乾杯。
ラルフロンキスト

多数のAPN文字列、小文字/大文字、すべてを試してみました。運がありません。欲求不満が近づいています。
マスロア

1

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

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


0

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

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

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


残念ながら(?)usb_modeswitchこのデバイスのルールは既に標準ルールセットに含まれていました。
ラルフロンキスト

-2

これを試しましたか:

 rfkill list up

次に、このスクリプトを作成して実行します。

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

この方法でうまくいくかもしれません。


どのIPアドレスを入力する必要がありますか?これはPPP接続です。
マズーロ

1
-1不正な構文のみを含む複雑なスクリプトを全面的shに記述した場合dash
heemayl
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.