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

Загрузка 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 в ноябре прошлого года (в его версии мм-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 не относится, но якобы было бы куда пойти. И, только с очень элементарной, до-101 понимание udev волшебство, я так или иначе рассмотрю вопрос о его 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"

или лучше, добавьте новый файл рядом с ним, например, с именем 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 выше.

Обратите внимание, что в 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 в виртуальной коробке, если, конечно, это уже все в виртуальной коробке.

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

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

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