USB 调制解调器尝试连接时出现“ip-config-unavailable”错误

Question 1

加载ofono软件包可能很好，但显然您的调制解调器型号 ZTE MF193E 不在 ZTE 列表中。与其他 ZTE 调制解调器（例如 MF190J）相比，此调制解调器可能需要相同的特殊udev规则，以便usb_modeswitch在插入加密狗时运行，为此，您可以以 root 身份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中的两行：

[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，因此再测试一次也无妨，尽管第二个选项更有可能。

第二种选择也更成问题，因为调制解调器提供了大写的“PDP 上下文”匹配。谷歌搜索这个问题，似乎不区分大小写的匹配符合（显然相关的）规范“3GPP TS 23.003 第 9.1 章”，并且ModemManager去年 11 月添加了一个补丁来执行此操作（据我所知，是在其版本 mm-1-4 中）。因此在这种情况下，您的调制解调器没有被告知，它期望区分大小写的匹配，但ModemManager不幸的是它直接使用不区分大小写的匹配而不是作为后备。

第二个问题的一个解决方案当然是使用不同的ModemManager：要么找到并安装此补丁之前的版本，要么（如果有足够的空闲时间）自己动手ModemManager。但两者都不是随心所欲的事情，所以也许我们需要浏览一下以获得更多证据证明这是（现在）的问题，如果可能的话，找到其他解决方法。或者运气好的话，会有人知道一些事情……

编辑2

是的，由于依赖关系，版本回滚并不容易。而且自己回滚也并不是一件愉快的事。

两个可能有用的工具：命令mmcli和 (http://m2msupport.net/m2msupport/module-tester/）。

我认为问题在于 ModemManager 选择了 apn='wap' 的 PDP 上下文 1，而它应该选择 apn='WAP' 的 PDP 上下文 9。也许可以使用这些工具之一来解决此问题。要么能够在连接期间强制选择 9，要么从调制解调器中删除错误的“wap”上下文，模块测试工具据称能够做到这一点。

调制解调器测试工具似乎是浏览器中的 Java 工具，因此您需要设置浏览器以了解 Java 的位置，并且需要知道该 Java。然后请探索该方法；我自己没有使用过，但看到屏幕截图，我猜它会将 PDP 上下文显示为“数据呼叫”选项卡，您首先记下它显示的所有内容，然后编辑“wap”条目以扭曲“wap”apn 标签，例如“wap1”和“wap2”（以便在查找“WAP”时“隐藏”它们）。然后保存并关闭，再次调整加密狗。获取日志；看来系统日志现在就足够了，以防它仍然拒绝播放。

这个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系统日志与非工作系统日志进行比较，似乎出于某种原因wvdial使用ttyUSB3，而非工作系统ModemManager继续使用ttyUSB1。我不确定这是否重要，但显然但ttyUSB1和ttyUSB3两者都响应为支持 AT 的调制解调器。

因此，作为测试，也许您可以进行编辑，/etc/wvdial.conf使其[Dialer Defaults]包含以下行：

Modem = /dev/ttyUSB1

对于一个测试，以及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不适用，但据说应该去哪里。而且，由于对魔术只有非常基本的、101 级之前的了解udev，我无论如何都会考虑质疑它的第 4 行，它说：

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

我认为该行需要首字母#，以便注释掉。具体来说，我对该文件的理解是，它需要 SUBSYSTEM=="tty" 和 SUBSYSTEMS="usb" 的调用状态才能使用好位，包括“2003”产品规则，并且至少对于测试来说，跳过“tty”过滤应该是安全的。而且我现在没有更好的办法。

编辑7

在花了不少时间使用我最喜欢的搜索引擎后，我更加相信 ttyUSB 的选择是这里的根本问题。我指出的 udev 规则没有问题，你应该恢复该编辑。

但是，我开始相信该文件末尾的产品 ID“2003”的配置规则具有误导性。从日志来看，我认为产品 ID“2003”实际上是加密狗的存储设备端，而调制解调器端的产品 ID 为“1232”。您可以通过在文件中复制产品 ID“1232”的两个“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 插件的开头。但是，很明显，无论如何都会使用通用调制解调器插件。现在，usb_modeswitch我早些时候给你的规则可能也是错误的；它决定切换到我以为是“2003”从“2003”。但是，man usb_modeswitch（我应该早点看看）有点暗示它发生了变化到产品 ID，而不是从无论如何，日志显示这种情况会发生。因此，请将该规则更改为使用“1232”，然后重试。

如果没有别的，至少我必须学习一些关于 udev 的知识。

编辑9

很好。问题仍然是（或者也是）ModemManager 在预探测时丢弃了 ZTE 插件。15.10 的 ModemManager 调试日志（日志集“debuglogs*”）都表明 ZTE 插件由于供应商 ID/产品 ID 测试而被丢弃。

找到源头，卢克！借此机会，我简单查看了一下 ModemManager 的源代码，发现该插件是一个不包含 19d2/2003 的 vid/pid 表...不过，我没有找到该表的源代码，所以无法验证。

或者这里可能存在时间问题。例如，当设备为 19d2/1232 时，ModemManager 会运行预探测。这种想法与以下观察结果一致：拥有 78-mm-zte-port-types-RALPH.rules udev 规则会使 ModemManager 对设备更满意一些。但是，为什么当设备切换到 19d2/2003 时，它不能保持满意并使用该插件呢？

udevadm monitor --e |& tee udevadm.log可能需要更多日志 :-) 调试 ModemManager，并在插入设备时捕获命令（在另一个终端中）。我从（https://wiki.ubuntu.com/DebuggingUdev）

重复两次：一次不使用规则78-mm-zte-port-types-RALPH.rules，一次使用规则……两次都从全新重启开始。即

/lib/udev/rules.d有或没有*-RALPH.rules文件的情况下设置
拔出设备
重启
设置 ModemManager 进行调试并设置 udevadm 捕获
插入设备并等待一分钟
打包日志文件
从 1 开始重复下一个测试

该日志应该告诉您 ZTE 插件被丢弃的位置，而且据我了解，它还将告诉您有关 udev 事件处理的信息。

编辑10

（我几乎已经精疲力竭了，但我还能再坚持一两次：-）

首先，所有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显示其最近的后续日志行。ModemManager3867.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)

其中附加了中兴通讯的属性。

在 MM 日志中，我们会看到带有标记的行1449934745.363291，这显然是一个“实时”时间戳，而不是“内核时间”时间戳。

ModemManager然后在完成预探测1449934745.450398，即 87 毫秒后，从内核时间角度来看，这将接近3867.524519并早于上述“良好”的 UDEV 事件报告 55 毫秒。

请注意，在中syslog，确实提出了未设置其属性的ModemManager投诉，也许该投诉与中发生的“标记”有关。根据该文件中的注释，该标记似乎是试图解决这个问题，但如果是这样，它似乎在这种情况下不起作用。ttyUSB180-mm-candidate.rules

解决这个问题的一个可能性可能是将“tty”规则改为80-mm-candidate.rules：

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

在我看来，这将确保设置ID_MM_CANDIDATE延迟到 ZTE 属性设置完成为止。设置是规则（之前调用）.ID_PORT的效果，标记规则的附加条件只是它有一个值。60-serial.rules60-persistent-serial.rules

条件并非完全是 ZTE 属性，只是为了使规则更通用。更具体的一步是改为 require ENV{.MM_USBIFNUM}="?*"，因为此处的分配是通过发生的77-mm-zte-port-types.rules。

总的来说，我不太确定udev规则排序，我也完全不确定这是否真的能阻止ModemManager行动过快。然而，如果不能，那么80-mm-candidate.rules它就没有什么作用，也许一切都归结为ModemManager15.04 的“改进”。

编辑21

叹息。可能不相关，但你可能想检查一下你的7-zte-mutil_port_device.rules文件；那是其他实验的残留物吗？无论如何，与此无关。

515.558184和之间仍有近一秒钟的时间，516.381549在此期间，ModemManager急切且错误地获取/dev/ttyUSB1，尽管抱怨它未设置，但仍会进行预探测并丢弃 ZTE 插件。换句话说，规则补丁不会等待ModemManager。

我想您也测试过使用ENV{.MM_USBIFNUM}="?*"而不是ENV{.ID_PORT}=="?*"。

实际上，要确认设置是否ENV{ID_MM_CANDIDATE}=1重要，您应该暂时移开80-mm-candidate.rules，然后查看（在syslog）是否ModemManager忽略/dev/ttyUSB1。我怀疑“不是”。

然后，好吧，也许您可以使用一个工作版本，例如 14.04，并且如果需要，也许在虚拟机中运行 15.10，除非当然它已经全部在虚拟机中了。

我想此时我需要承认失败。

Answer