Ошибка «ip-config-unavailable» при попытке подключения USB-модема

У меня есть модем ZTE MF-193E, который раньше работал нормально. Когда я купил этот модем больше года назад, он работал с готовностью из коробки. Теперь, когда Ubuntu прогрессирует в версии, мне становится все сложнее и сложнее.

Этот модем даже работал пару месяцев назад с Ubuntu 15.04 (64-битная версия). Теперь, в Ubuntu 15.10 (64-разрядная версия), он не может подключиться.

Я установил мобильную широкополосную связь . Я пробовал разные строки для APN, но раньше это не было проблемой.

(Модем отлично работает в Windows 10, так что это не аппаратная проблема вообще. Кроме того, графический интерфейс менеджера модема приятно обнаруживает это устройство. SMS могут отправляться и приниматься без проблем.)

Когда я вставляю модем, он обнаруживается хорошо, в 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 - 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 - 06 декабря 2015

Выполнен от имени root,

systemctl restart network-manager.service

Нет вывода на экран (терминал).

Соответствующий журнал из вышеприведенного пункта о попытке подключения через модем можно найти здесь .

Обновление 3 - 06 декабря 2015

Установил ofonoи снова попробовал модем.

Пожалуйста, смотрите журнал здесь .

Обновление 4 - 06 декабря 2015

Снова выполняется как корень,

systemctl restart network-manager.service

Соответствующий журнал из вышеприведенного пункта о попытке подключения через модем можно найти здесь .

Обновление 5 - 06 декабря 2015

Изменено все «запретить» на «разрешить» в /etc/dbus-1/system.d/nm-dispatcher.conf.

Пробовал подключаться. Неудачно.

Несколько сетевых подключений и отключений с подключением Ethernet.

Вслед за sudo systemctl restart network-manager.service.

Модем подключи и подключи.

Попробовал снова подключиться. Не подключается.

Журнал здесь .

Обновление 6 - 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 .

Вышеуказанные команды несколько отличаются от команд в вики.

Файлы журнала находятся здесь .

Обновление 7 - 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Входит также.

Файлы журнала находятся здесь .

Обновление 8 - 08 декабря 2015

Обновленный набор журналов здесь .

Обновление 9 - 08 декабря 2015

Тест 1

1. На этот раз загрузил компьютер с 32-битного DVD Ubuntu 14.04. Как только компьютер загрузился, начался захват журнала ММ.

2. Вставил модем. lsusbпоказал, что оно распознается как устройство 19d2: 1232, которое необходимо подключить к устройству 19d2: 2003. Так как для установки usb-mode switch требуется перезагрузка компьютера (и, следовательно, потеря установки для запуска DVD), я подготовил файл пользовательского переключателя и переключил модем из командной строки ( sudo usb_modeswitch -I -c 19d2:2003).

3. Как только переключение было выполнено, мне сообщили, что я Mobile Broadband Networkвключен, и в меню сетевого менеджера появилось сообщение о новом широкополосном соединении.

4. Я установил вышеупомянутое соединение обычным способом (имя APN не было проблемой), и соединение было установлено автоматически.

5. Я отключил и выбросил модем.

6. Перестал захватывать журнал ММ.

Полный журнал MM и системный журнал для начала сеанса для извлечения модема можно найти здесь .

Тест 2

Тот же тест с 64-битным DVD Ubuntu 14.04.

Журналы можно найти здесь .

Обновление 10 - 09 декабря 2015

На этот раз мы проверили wvdialи обнаружили, что, если wvdialон запускается с правами root, мы получаем успешное соединение

wvdialКонф и журнал, и соответствующий системный журнал находится здесь

Основная гипотеза: ситуация может иметь отношение к группе пользователей соответствующего пользователя.

Но, как указано здесь ,

Со всеми этими инструментами, чтобы установить коммутируемое соединение, пользователь должен быть членом групп «dip» и «dialout», поэтому включите в эти группы всех пользователей, которые должны соединяться через dialup.

Но, как мы можем найти,

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

Итак, пользователь уже является членом указанных групп.

Теперь, возможно, проблема сводится к одному из этих пунктов,

1. Какой дополнительной группой должен быть пользователь?
2. Как запустить процесс настройки мобильного широкополосного подключения от имени пользователя root? (проблемы с безопасностью?)

Обновление 11 - 09 декабря 2015

wvdialработает с USB3 и не работает с USB1.

Пожалуйста, найдите системный журнал здесь .

Также включен вывод dmesg | grep tty > /tmp/dmesg.tty.txt. Но видите эти четыре строки рядом с началом файла?

Обновление 12 - 10 декабря 2015

1. Закомментирована линии 4 ( SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end") в /lib/udev/rules.d/77-mm-zte-port-types.rules.

2. Перезагрузил мою машину. Софт отключил кабель и вставил модем.

3. Пытался подключиться. Неудачный.

Файл системного журнала находится здесь .

Обновление 13 - 10 декабря 2015

Из отчаяния, чтобы увидеть, влияют ли некоторые локальные изменения на соединение, протестировал машину с Ubuntu 15.04 и 15.10 DVD.

1. Загрузил машину с Xubuntu 15.04 64-битный DVD. Связь была успешной, как шарм.
2. Загрузил машину с Ubuntu 15.10 64-битный DVD. Сбой соединения, как и раньше.

Что произошло между 15.04 и 15.10?

Так расстраивает.

Обновление 14 - 10 декабря 2015

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. Выкинул модем.

Машина зависает один раз, это случайное событие? Моя машина обычно не зависает один раз в год.

Файл системного журнала и созданные файлы правил находятся здесь .

Обновление 15 - 11 декабря 2015

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. Перезагрузился и снова попробовал весь процесс. Снова неудачно.

Файл системного журнала (завершено, я не рискнул пропустить ни одной важной части) и упомянутый файл правил (40) находятся здесь .

Обновление 16 - 11 декабря 2015

1. Оставлено только одно правило 1232 /lib/udev/rules.d/40-usb_modeswitch.rules, удалено другое.

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на своем месте?

Файл системного журнала (завершено, я не рискнул пропустить ни одной важной части) и упомянутый файл правил (40) находятся здесь

Обновление 17 - 11 декабря 2015

1. Прокомментировал правило 1232 /lib/udev/rules.d/40-usb_modeswitch.rules, добавил одно за 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. Выкинул модем.

Файл системного журнала и упомянутый файл правил (40) находятся здесь

Обновление 18 - 11 декабря 2015

1. Положите все файлы правил в их первоначальном виде.

2. Смотрел lsusbвывод каждую секунду, используя скрипт оболочки. Захваченный вывод в файлах с отметкой времени.

3. Вставил модем. (Модем сначала появляется в файле lssuboutouput.Fri Dec 11 16:56:29 BDT 2015.txt). Как видно из снимков, ясно, что оно переключается с устройства 1232 на устройство 2003 года.

4. Пытался подключиться. Неудачный.

5. Выкинул модем.

Файл системного журнала, lsusbвыходные данные с отметками времени и упомянутые файлы правил находятся здесь .

Теперь вы можете сопоставить выходные данные системного журнала с отметками времени.

Обновление 19 - 11 декабря 2015

Выполнил этот тест в совершенно новом направлении с желанием, чтобы я мог изолировать проблемы.

1. Сохранено на переносном носителе /lib/udev/rules.d/40-usb-media-players.rulesи /lib/udev/rules.d/77-mm-zte-port-types.rules(с машины Ubuntu 15.10).

2. Загрузил машину с 64-битного DVD Xubuntu 15.04.

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, просто чтобы увидеть, где он ломается. Я на самом деле пытался, но сдался из-за бесконечных проблем с зависимостями.

Все вышеупомянутые файлы diff находятся здесь .

Обновление 20 - 12 декабря 2015

Тест 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на месте.

Имена файлов журнала говорят сами за себя.

Все вышеперечисленные файлы журнала плюс системный журнал и 78 файлов правил находятся здесь .

Я хотел бы, чтобы все файлы журналов были снабжены временными метками, чтобы облегчить сопоставление.

Обновление 21 - 15 декабря 2015

1. Изменен файл правил, как предложено.
2. Перезагрузил мою машину.
3. Вставил модем и попробовал подключиться. Это не работает.

Файл правил и syslogнаходятся здесь .

Обновление 22 - 16 декабря 2015

Как советовали в одном комментарии, установили различные ядра с http://kernel.ubuntu.com/~kernel-ppa/mainline/ и попытались подключиться с помощью модема после загрузки в каждом.

1. 4.2.8-040208-универсальный отказ.

2. 4.1.15-040115-generic, ошибка.

3. 4.0.9-040009-generic, ошибка.

Так что, возможно, мы можем исключить проблему с ядром.

Обновление 23 - 16 февраля 2016

Модем начал работать в Ubuntu 16.04. Эта версия все еще в Альфа 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в ноябре прошлого года (в его версию mm-1-4, Я могу собрать). Таким образом, в этом случае вашему модему не сообщили, и он ожидает сопоставления с учетом регистра, в то время как, ModemManagerк сожалению, прямое сопоставление без учета регистра используется, а не как запасной вариант.

Одним из решений второй проблемы, конечно же, является использование другого ModemManager: либо путем поиска и установки версии до этого патча, либо (при наличии достаточного количества свободного времени) сверните свою собственную ModemManager. Но это не то, что нужно делать по прихоти, поэтому, возможно, нам нужно немного осмотреться, чтобы получить больше доказательств того, что это (сейчас) проблема, и, если возможно, найти другие способы обойти это. Или с небольшим количеством удачи, кто-то, кто знает что-то, заходит ...

РЕДАКТИРОВАТЬ 2

Да, откат версии нелегок из-за зависимостей. И кататься самостоятельно тоже далеко не радостно.

Два возможных полезных инструмента: команда mmcliи ( http://m2msupport.net/m2msupport/module-tester/ ).

Проблема, я думаю, в том, что ModemManager выбирает контекст 1 PDP с помощью apn = 'wap', где он должен выбирать контекст 9 PDP с помощью apn = 'WAP'. Может быть, это можно решить с помощью одного из этих инструментов. Либо иметь возможность принудительно выбрать 9 во время соединения, либо удалив неверные контексты «wap» из модема, на которые, как объявляется, тестирующий модуль модуль способен.

Инструмент модем-тестер, похоже, является инструментом Java в браузере, поэтому вам нужно настроить браузер, чтобы знать, где находится Java, и вам нужна эта Java, чтобы знать о ней. Тогда, пожалуйста, изучите этот подход; Я не использовал его сам, но, видя скриншоты, я предполагаю, что он представит контексты PDP в виде вкладки «Вызовы данных», где вы сначала отмечаете все, что он показывает, а затем редактируете записи «wap», чтобы искажать метки apn «wap», скажем, «wap1» и «wap2» (чтобы «скрыть» их при поиске «WAP»). Затем сохраните и закройте и снова передерните ключ. Захватить бревно; кажется, системного журнала достаточно, если он все еще отказывается играть.

Команда mmcliтакже кажется полезной в этой истории; делать , man mmcliчтобы читать об этом, но я не вижу ничего о PDP контексты там.

РЕДАКТИРОВАТЬ 3

Хороший звонок! проверить с DVD. Это говорит нам о том, что я на неверном пути с APN, и что все дело в том, чтобы заставить ppp появиться. По крайней мере, это будет мое новое дерево, на которое можно лаять.

Во-первых, мы отмечаем, что есть разница в версии для pppd (от 2.4.5 до 2.4.6), но это, вероятно, не проблема, так как тогда все на ключе были бы на этой экскурсии.

Хм, ppp; Мне нужно расшевелить мои воспоминания прошлого тысячелетия :-). К сожалению, я сегодня занят, но я коснусь базы, когда в следующий раз у меня будет время, чтобы увидеть, как далеко вы продвинулись. Моими первыми задними переулками, которые нужно изучить, будет: 1) пользователь в правильной группе? 2) верно ли полномочия? 3) мод мода файла конфигурации ppp / chat прав? Журнал отладки 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 можно игнорировать; это было так во всех журналах. Новый системный журнал показывает только тест 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"

Я думаю, что эта строка нуждается в инициализации, #чтобы быть закомментированной. Подробно, мое чтение файла заключается в том, что для этого требуется состояние вызова SUBSYSTEM == "tty" и SUBSYSTEMS = "usb", чтобы использовать хорошие биты, включая правила продукта "2003", и, по крайней мере, для тестирования, должно быть безопасно пропустить фильтрацию "tty". И сейчас у меня нет ничего лучше.

РЕДАКТИРОВАТЬ 7

Проведя некоторое время с моей любимой поисковой системой, я немного больше верю в то, что выбор ttyUSB здесь является основной проблемой. Правило udev, на которое я указывал, в порядке, и вы должны отменить это изменение.

Однако я начал верить, что правила конфигурации ближе к концу этого файла для идентификатора продукта «2003» вводят в заблуждение. Из журналов мне кажется, что идентификатор продукта «2003» на самом деле является стороной ключа устройства, а сторона модема имеет идентификатор продукта «1232». Вы можете проверить это, скопировав два правила «2003» для идентификатора продукта «1232» в файле/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"

или, что еще лучше, добавьте новый файл рядом с ним, например, named 78-ralph.rules, но тогда вам также необходимо добавить защиту SUBSYSTEM и SUBSYSTEMS вокруг него.

Затем вытащите ключ, запустите udevadm control --reload(или перезагрузите компьютер) и вставьте ключ. А потом еще один syslogзахват, если только сейчас это не сработает.

Однако эффективная проблема заключается в том, что ModemManager отбрасывает плагин libmm-plugin-zte.soпри предварительном зондировании и использует общий обработчик модема. Если я прав насчет идентификатора продукта, то это может быть причиной; эта предварительная проверка ищет ID_MM_ZTE_PORT_TYPE_MODEMатрибуцию, а для идентификатора продукта "1232" (до исправления) этого не хватает, что приводит к тому, что плагин zte удаляется.

РЕДАКТИРОВАТЬ 8

Журнал syslogнемного короткий; отсутствует начало, когда ModemManager не может установить плагин zte. Тем не менее, ясно, что универсальный плагин модема используется в любом случае. Теперь, возможно, что usb_modeswitchправило, которое я дал вам на раннем этапе, также неверно; он решает переключиться на «2003», когда я думал, что он переключился с «2003». Но, man usb_modeswitch(который я посмотрел на раньше) вид предположить , что она переходит в идентификатор продукта , а не от него. В любом случае журнал показывает, что должно произойти. Поэтому, пожалуйста, измените это правило, чтобы использовать вместо него «1232», и попробуйте еще раз.

Если ничего больше, по крайней мере, я должен немного узнать об Udev.

РЕДАКТИРОВАТЬ 9

Хорошо. Проблема все еще (или также) в том, что ModemManager удаляет плагин ZTE при предварительном зондировании. Журналы отладки ModemManager для 15.10 (log устанавливает «debuglogs *») рассказывают историю, что плагин ZTE отбрасывается из-за теста vendor-id / product-id.

Иди к источнику, Люк! Я воспользовался этой возможностью, чтобы кратко просмотреть исходный код ModemManager, и это указывает на то, что плагин представляет собой таблицу vid / pid, которая не включает 19d2 / 2003 ... хотя я не нашел этот источник таблицы, поэтому я не мог не проверять.

Или, может быть, здесь есть проблема времени? Например, что ModemManager выполняет предварительное зондирование, пока устройство имеет значение 19d2 / 1232. Эта мысль согласуется с наблюдением, что наличие правил udev из 78-мм-zte-port-types-RALPH.rules делает ModemManager немного более счастливым с устройством. Но тогда почему он не остается доволен и использует этот плагин, когда устройство переключено на 19d2 / 2003?

Может быть, нужно больше журналов :-) С отладкой ModemManager, а также захватом команды udevadm monitor --e |& tee udevadm.log(в другом терминале) при подключении устройства. Я получил эту команду от ( https://wiki.ubuntu.com/DebuggingUdev )

Сделайте это два раза: один раз без 78-mm-zte-port-types-RALPH.rulesправил и один раз с правилами ... оба раза после новой перезагрузки. Т.е.

1. настройка /lib/udev/rules.dс или без *-RALPH.rulesфайла
2. вытащить устройство
3. перезагрузка
4. настройка ModemManager для отладки и настройки захвата udevadm
5. подключите устройство и подождите минуту
6. собрать файлы журналов
7. повторить с 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представляет свою ближайшую последующую 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.

В журнале ММ мы будем на линии с отметкой 1449934745.363291, которая, по-видимому, является отметкой времени «реального времени», а не отметкой «времени ядра».

ModemManagerзатем выполняется предварительное зондирование 1449934745.450398, т. е. через 87 мс, что в терминах времени ядра будет близко 3867.524519и за 55 мс до этого «хорошего» отчета о событии UDEV, описанного выше.

Обратите внимание, что in syslog, ModemManagerподает жалобы, для которых ttyUSB1не установлены атрибуты, и, возможно, эта жалоба связана с «маркировкой», происходящей в 80-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.rulesправила (которое вызывалось 60-persistent-serial.rulesранее), а добавленное условие к правилу маркировки заключается просто в том, что оно имеет значение.

Условие не является точно атрибутом ZTE, только для того, чтобы сделать правило более общим. Еще один конкретный шаг - вместо этого потребовать 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и 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 в виртуальной коробке, если, конечно, это уже все находится в виртуальной коробке.

Я думаю, что мне нужно претендовать на поражение на этом этапе.

Модем начал работать в Ubuntu 16.04. Эта версия все еще находится в стадии разработки, но отлично работает на моем ноутбуке.

Хотел бы я предоставить больше технических деталей о том, как он начал функционировать.

Если взглянуть на это с первого взгляда, то, похоже, это не первый раз, когда с этим драконом правильно обращаются. Раньше это было ошибкой в ​​12.10 и 13.04, возможно, эта ошибка никогда не была исправлена ​​или новый патч сломал что-то, что раньше работало правильно.

Надеюсь, если я правильно читаю ваши технические характеристики, мне нужно указать вам следующее направление (MF190J):

3G-модем (ZTE MF190J) по-прежнему требует ручной настройки.

Вы пробовали это:

 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

и это может работать нормально таким образом.