У меня есть модем 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
На этот раз загрузил компьютер с 32-битного DVD Ubuntu 14.04. Как только компьютер загрузился, начался захват журнала ММ.
Вставил модем.
lsusb
показал, что оно распознается как устройство 19d2: 1232, которое необходимо подключить к устройству 19d2: 2003. Так как для установки usb-mode switch требуется перезагрузка компьютера (и, следовательно, потеря установки для запуска DVD), я подготовил файл пользовательского переключателя и переключил модем из командной строки (sudo usb_modeswitch -I -c 19d2:2003
).Как только переключение было выполнено, мне сообщили, что я
Mobile Broadband Network
включен, и в меню сетевого менеджера появилось сообщение о новом широкополосном соединении.Я установил вышеупомянутое соединение обычным способом (имя APN не было проблемой), и соединение было установлено автоматически.
Я отключил и выбросил модем.
Перестал захватывать журнал ММ.
Полный журнал 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
Итак, пользователь уже является членом указанных групп.
Теперь, возможно, проблема сводится к одному из этих пунктов,
- Какой дополнительной группой должен быть пользователь?
- Как запустить процесс настройки мобильного широкополосного подключения от имени пользователя root? (проблемы с безопасностью?)
Обновление 11 - 09 декабря 2015
wvdial
работает с USB3 и не работает с USB1.
Пожалуйста, найдите системный журнал здесь .
Также включен вывод dmesg | grep tty > /tmp/dmesg.tty.txt
. Но видите эти четыре строки рядом с началом файла?
Обновление 12 - 10 декабря 2015
Закомментирована линии 4 (
SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end"
) в/lib/udev/rules.d/77-mm-zte-port-types.rules
.Перезагрузил мою машину. Софт отключил кабель и вставил модем.
Пытался подключиться. Неудачный.
Файл системного журнала находится здесь .
Обновление 13 - 10 декабря 2015
Из отчаяния, чтобы увидеть, влияют ли некоторые локальные изменения на соединение, протестировал машину с Ubuntu 15.04 и 15.10 DVD.
- Загрузил машину с Xubuntu 15.04 64-битный DVD. Связь была успешной, как шарм.
- Загрузил машину с Ubuntu 15.10 64-битный DVD. Сбой соединения, как и раньше.
Что произошло между 15.04 и 15.10?
Так расстраивает.
Обновление 14 - 10 декабря 2015
Создан новый файл,
/lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules
как указано в ответе.Перезагрузил мою машину (или выполнил
sudo udevadm control --reload
, на самом деле пробовал оба). Вставил модем.Модем получил признание.
$ lsusb Bus 001 Device 005: ID 19d2:2003 ZTE WCDMA Technologies MSM
Софт отключил кабель и попытался подключиться с помощью модема. Неудачный.
Выкинул модем.
Машина зависает один раз, это случайное событие? Моя машина обычно не зависает один раз в год.
Файл системного журнала и созданные файлы правил находятся здесь .
Обновление 15 - 11 декабря 2015
Добавлены следующие строки в
/lib/udev/rules.d/40-usb_modeswitch.rules
.# ZTE MF193E ATTR{idVendor}=="19d2", ATTR{idProduct}=="1232", RUN+="usb_modeswitch '%b/%k'"
Оставил файл
/lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules
без изменений.Перезагрузил мою машину. Вставил модем.
Модем получил признание.
Bus 001 Device 005: ID 19d2:2003 ZTE WCDMA Technologies MSM
Софт отключил кабель и попытался подключить. Неудачный.
Выкинул модем.
Удалены
/lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules
.Перезагрузился и снова попробовал весь процесс. Снова неудачно.
Файл системного журнала (завершено, я не рискнул пропустить ни одной важной части) и упомянутый файл правил (40) находятся здесь .
Обновление 16 - 11 декабря 2015
Оставлено только одно правило 1232
/lib/udev/rules.d/40-usb_modeswitch.rules
, удалено другое.Выполненная
sudo udevadm control --reload
.Вставил модем.
Модем получил признание.
Bus 001 Device 005: ID 19d2:2003 ZTE WCDMA Technologies MSM
Софт отключил кабель и попытался подключить. Неудачный.
Выкинул модем.
Но разве мы не тестировали систему по умолчанию выше? Вы хотели оставить /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules
на своем месте?
Файл системного журнала (завершено, я не рискнул пропустить ни одной важной части) и упомянутый файл правил (40) находятся здесь
Обновление 17 - 11 декабря 2015
Прокомментировал правило 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'"
Выполненная
sudo udevadm control --reload
.Вставил модем.
Модем был признан устройством 1232 . Мне не предлагается пытаться подключиться (насколько мне известно, оно не будет зарегистрировано в широкополосной сети, если переключение не произошло в 2003 году)
Bus 001 Device 008: ID 19d2:1232 ZTE WCDMA Technologies MSM
Выкинул модем.
Файл системного журнала и упомянутый файл правил (40) находятся здесь
Обновление 18 - 11 декабря 2015
Положите все файлы правил в их первоначальном виде.
Смотрел
lsusb
вывод каждую секунду, используя скрипт оболочки. Захваченный вывод в файлах с отметкой времени.Вставил модем. (Модем сначала появляется в файле
lssuboutouput.Fri Dec 11 16:56:29 BDT 2015.txt
). Как видно из снимков, ясно, что оно переключается с устройства 1232 на устройство 2003 года.Пытался подключиться. Неудачный.
Выкинул модем.
Файл системного журнала, lsusb
выходные данные с отметками времени и упомянутые файлы правил находятся здесь .
Теперь вы можете сопоставить выходные данные системного журнала с отметками времени.
Обновление 19 - 11 декабря 2015
Выполнил этот тест в совершенно новом направлении с желанием, чтобы я мог изолировать проблемы.
Сохранено на переносном носителе
/lib/udev/rules.d/40-usb-media-players.rules
и/lib/udev/rules.d/77-mm-zte-port-types.rules
(с машины Ubuntu 15.10).Загрузил машину с 64-битного DVD Xubuntu 15.04.
Выполненная
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 не показывает
idProduct
1232 или 2003.Выполненная
diff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules > diff15.10and15.04_40-usb.txt
. Опять же, первый файл из того, который был сохранен 15.10.Опять же, проверка файла diff не показывает
idProduct
1232 или 2003.Вставил модем. Модем был признан модемом.
$ lsusb Bus 001 Device 008: ID 19d2:2003 ZTE WCDMA Technologies MSM
Может легко подключиться после настройки мобильного широкополосного соединения.
Выкинул модем.
Установлен последний USB_ModeSwitch.
diff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules
Теперь возвращает NULL, как и ожидалось.
Выполненная
sudo udevadm control --reload-rules
.Вставил модем. Модем был признан модемом.
$ lsusb Bus 001 Device 008: ID 19d2:2003 ZTE WCDMA Technologies MSM
Мог легко подключиться.
Я мог бы попробовать обновить MM и NM до Ubuntu 15.10, просто чтобы увидеть, где он ломается. Я на самом деле пытался, но сдался из-за бесконечных проблем с зависимостями.
Все вышеупомянутые файлы diff находятся здесь .
Обновление 20 - 12 декабря 2015
Тест 1
В
/lib/udev/rules
оригинальном состоянии.Модемное устройство еще не было вставлено в этом сеансе.
Настройте ModemManager для отладки и настройки захвата udevadm.
sudo udevadm monitor --e |& tee udevadm.update20.WITHOUT78.log sudo killall ModemManager; sudo ModemManager --debug 2>&1 | tee MM.update20.WITHOUT78.log
Подключил модем и подождал пока он скажет что он зарегистрирован в широкополосной сети.
Пытался соединиться неудачно.
Выкинул модем.
Упакованные файлы журнала.
Тест 2
Повторили вышеуказанный тест с
/lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules
на месте.
Имена файлов журнала говорят сами за себя.
Все вышеперечисленные файлы журнала плюс системный журнал и 78 файлов правил находятся здесь .
Я хотел бы, чтобы все файлы журналов были снабжены временными метками, чтобы облегчить сопоставление.
Обновление 21 - 15 декабря 2015
- Изменен файл правил, как предложено.
- Перезагрузил мою машину.
- Вставил модем и попробовал подключиться. Это не работает.
Файл правил и syslog
находятся здесь .
Обновление 22 - 16 декабря 2015
Как советовали в одном комментарии, установили различные ядра с http://kernel.ubuntu.com/~kernel-ppa/mainline/ и попытались подключиться с помощью модема после загрузки в каждом.
4.2.8-040208-универсальный отказ.
4.1.15-040115-generic, ошибка.
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
комментарием:плюс пустая строка, поэтому она выглядит приятной для глаз.
После этого, вероятно, целесообразно перезагрузить компьютер, только чтобы убедиться, что все работает как по волшебству :-)
Или не. Как вы знаете, это глубокая вода для меня, но если она все еще не работает, понадобится другой журнал отладки ModemManager, для еще одной дикой догадки.
РЕДАКТИРОВАТЬ:
Сейчас я смотрю на две строки в modemmanager.txt:
и
Я предполагаю, что первое относится к вашей широкополосной настройке, а второе относится к внутренней привязке к «контексту 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]
включал в себя строкудля одного теста и
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" и SUBSYSTEMS = "usb", чтобы использовать хорошие биты, включая правила продукта "2003", и, по крайней мере, для тестирования, должно быть безопасно пропустить фильтрацию "tty". И сейчас у меня нет ничего лучше.РЕДАКТИРОВАТЬ 7
Проведя некоторое время с моей любимой поисковой системой, я немного больше верю в то, что выбор ttyUSB здесь является основной проблемой. Правило udev, на которое я указывал, в порядке, и вы должны отменить это изменение.
Однако я начал верить, что правила конфигурации ближе к концу этого файла для идентификатора продукта «2003» вводят в заблуждение. Из журналов мне кажется, что идентификатор продукта «2003» на самом деле является стороной ключа устройства, а сторона модема имеет идентификатор продукта «1232». Вы можете проверить это, скопировав два правила «2003» для идентификатора продукта «1232» в файле
/lib/udev/rules.d/77-mm-zte-port-types.rules
или, что еще лучше, добавьте новый файл рядом с ним, например, 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
правил и один раз с правилами ... оба раза после новой перезагрузки. Т.е./lib/udev/rules.d
с или без*-RALPH.rules
файлаЭто ведение журнала должно сообщать, где удален плагин ZTE, и, как я понимаю, оно также расскажет об обработке событий udev.
РЕДАКТИРОВАТЬ 10
(У меня почти закончился трос, но у меня осталось еще одно или два вдоха :-)
Во-первых,
udev
кажется , что все украшения заканчиваются так, как должны, с парой знаков вопроса в паре атрибутов. В частности,78-*-RALPH.rules
следует выбросить; это не полезноЯ думаю, что я могу прочитать что-то из этого, но я не совсем уверен, как это следует исправить. В принципе, как я вижу, когда ключ подключен, происходит поток событий udev. Сосредоточив внимание на тех, что касаются ttyUSB1, существует «раннее» событие:
который заставляет
usb_serial
драйвер загружаться и/dev/ttyUSB1
появляться. Это, в частности, вызывает другое событие:Я думаю, что это также вызывает
ModemManager
. Вы должны пойти, чтобыsyslog
увидеть доказательства этого, поскольку нет строгой корреляции между журналами. Событие имеет метку времени3867.435102
иsyslog
представляет свою ближайшую последующуюModemManager
строку журнала сразу после того, как отмечена строка журнала ядра3867.437412
.По моему мнению, еще
ModemManager
не должен быть запущен, но только после последующего события ttyUSB1:который прикрепил атрибуты ZTE.
В журнале ММ мы будем на линии с отметкой
1449934745.363291
, которая, по-видимому, является отметкой времени «реального времени», а не отметкой «времени ядра».ModemManager
затем выполняется предварительное зондирование1449934745.450398
, т. е. через 87 мс, что в терминах времени ядра будет близко3867.524519
и за 55 мс до этого «хорошего» отчета о событии UDEV, описанного выше.Обратите внимание, что in
syslog
,ModemManager
подает жалобы, для которыхttyUSB1
не установлены атрибуты, и, возможно, эта жалоба связана с «маркировкой», происходящей в80-mm-candidate.rules
. Согласно комментарию в этом файле, эта маркировка является попыткой решить именно эту проблему, но в этом случае, похоже, она не работает в этом случае.Возможно, одна из возможностей решения этой проблемы - изменить правило "tty"
80-mm-candidate.rules
на:На мой взгляд, это обеспечит
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) по-прежнему требует ручной настройки.
источник
usb_modeswitch
Правило для этого устройства уже было в стандартном наборе правил.Вы пробовали это:
а затем сделайте этот скрипт и запустите его:
и это может работать нормально таким образом.
источник
sh
на самом деле это символическая ссылкаdash
?