ошибка 'ip-config-unavailable', когда USB-модем пытается соединиться

После взятия взгляда этого кажется, что это не первый раз, когда с этим драконом правильно имели дело. Это была ошибка прежде в 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

и это могло бы хорошо работать этот путь.

Загрузка ofono пакет делал хорошее, вероятно, но по-видимому Ваша модемная модель, ZTE MF193E, не находится в списке ZTE. Сравнивая его с другими модемами ZTE, например, MF190J, этому модему, вероятно, будет нужно то же специальное предложение udev правило, для выполнения usb_modeswitch когда аппаратный ключ вставляется, и достигнуть этого, как корень, можно добавить новое 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 хочет a 'wap' конфигурация (а не 'WAP') и не находит его, или что удаленный конец ожидает apn='WAP', но получает 'WAP', на котором это дросселирует.

Первая опция могла легко быть протестирована (и исключена, вероятно) путем изменения конфигурации для использования 'WAP' вместо 'WAP'. Вы, возможно, попробовали это прежде, но в то время без ofono пакет, таким образом, другой тест не причинит боль, хотя вторая опция более вероятна.

Вторая опция является также большим количеством проблемы, учитывая, что существует прописное "соответствие" контекста PDP, доступное от модема. Гугля эту проблему, кажется, что нечувствительное к регистру соответствие корректно (по-видимому соответствующей) спецификацией "3GPP глава 9.1 TS 23.003" и патч, чтобы сделать, это было добавлено к ModemManager в ноябре в прошлом году (в его версию mm-1-4, я могу собраться). Так в этом случае Ваш модем не был сказан, и он ожидает чувствительное к регистру соответствие, в то время как ModemManager к сожалению, использует нечувствительное к регистру соответствие прямо, а не как нейтрализацию.

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

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

Да, откат версии не легок из-за зависимостей. И прокрутка Ваше собственное далека от радости также.

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

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

Инструмент модемного тестера, кажется, инструмент Java в браузере, таким образом, Вам нужен Ваш браузер, настроенный для знания, где Java, и Вам нужен тот Java, который будет известен о. Затем исследуйте тот подход; я не использовал его сам, но наблюдение снимков экрана, я предполагаю, что это представит контексты PDP как вкладку 'Data Calls', где Вы сначала принимаете во внимание все, что это показывает, и затем отредактируйте записи '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 право модификации файла конфигураций? Журнал отладки 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 оба отвечают как В способных модемах.

Так, как тест, возможно, можно отредактировать /etc/wvdial.conf так это под [Dialer Defaults] включает строку:

Modem = /dev/ttyUSB1

для одного теста, и ttyUSB3 для другого; оба выполнения как корень; только, чтобы видеть, существует ли другое поведение. Особенно, при использовании ttyUSB1 проблема, тогда как использование ttyUSB3 не, затем было бы хорошо изучить, как заставить ModemManager использовать ttyUSB3 также. Для любого другого тестового результата я сказал бы, что мы вернемся к преследованию хорьков на земле ppp.

РЕДАКТИРОВАНИЕ 6

Журнал dmesg может быть проигнорирован, я думаю; это было похоже на это во всех журналах. Новый системный журнал только показывает тест ttyUSB3, но возможно мы можем предположить, что жизнь поправляется если NetworkManager может быть жестким, чтобы использовать ttyUSB3 и проигнорировать ttyUSB1 (для этого модема).

Я также нашел (https://bugs.launchpad.net/ubuntu / + source/modemmanager / + ошибка/819784) с особенно дезориентацией сообщения № 10 :-(

По-видимому применимое udev правило в /lib/udev/rules.d/77-mm-zte-port-types.rules не применяется, but'd, предположительно, быть, куда пойти. И, с только очень элементарным, пред101 понимание udev волшебство, я во всяком случае рассмотрел бы опрос его 4-й строки, которая говорит:

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

Я думаю, что строке нужна начальная буква # чтобы быть прокомментированным. Подробно, мое чтение файла состоит в том, что он требует состояния вызова ПОДСИСТЕМЫ == "tty" и ПОДСИСТЕМ = "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, но затем также необходимо добавить ПОДСИСТЕМУ и защиту ПОДСИСТЕМ вокруг этого.

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

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

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

syslog журнал немного короток; пропавшие без вести начала, где ModemManager не удается установить zte плагин. Однако ясно, что Универсальный модемный плагин используется во всяком случае. Теперь, может случиться так что usb_modeswitch правило, которое я дал Вам вначале, является неправильным также; это решает переключиться на "2 003", когда я думал, что это переключилось от "2 003". Но, man usb_modeswitch (на который я должен был посмотреть прежде), отчасти предполагают, что это смещается к идентификатору продукта, а не от него. В любом случае журнал показывает это для случая. Таким образом измените то правило использовать "1232" вместо этого, и попытка все снова и снова.

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

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

Хороший. Проблема все еще (или также), в котором ModemManager отбрасывает плагин ZTE пред зондирование. Файлы регистрации событий отладки ModemManager для 15,10 (наборы журнала "debuglogs*") все рассказывают историю, что плагин ZTE отбрасывается из-за теста vendor-id/product-id.

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

Или возможно здесь существует проблема синхронизации. Например, что предварительное зондирование выполнений 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)

Сделайте это два раза: однажды без 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

(Я почти в конце моей привязи здесь, но у меня есть одно или еще два дыхания left:-),

Во-первых, весь 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 и 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 установка является эффектом a 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 в virtualbox, если, конечно, это уже не, все находится в virtualbox.

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