Помилка 'ip-config-unavailable', коли USB-модем намагається підключитися


12

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

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

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

(Модем працює добре в Windows 10, тому це зовсім не проблема з обладнанням. Крім того, GUI Modem Manager чудово виявляє цей пристрій. SMS-повідомлення можна надсилати та отримувати без будь-яких проблем.)

Коли я вставляю модем, він виявляється добре, піктограма CD відображається в 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 року

Виконується як корінь,

systemctl restart network-manager.service

Немає виводу на екран (термінал).

Відповідний журнал з вищевказаної точки до спроби з'єднання за допомогою модему можна знайти тут .


Оновлення 3 - 06 грудня 2015 року

Встановив ofonoі потім спробував модем ще раз.

Будь ласка, дивіться журнал тут .


Оновлення 4 - 06 грудня 2015 року

Знову виконується як root,

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 .

Вищезазначені команди дещо відрізняються від команд у Wiki.

Файли журналів тут .


Оновлення 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. Як тільки комп'ютер завантажився, почав фіксувати журнал MM.

  2. Вставлено модем. lsusbпоказав, що його розпізнають як пристрій 19d2: 1232, який потрібно перенести на пристрій 19d2: 2003. Оскільки для установки usb-modewitch потрібна перезавантаження машини (а отже, і втрата установки для запуску DVD), я підготував користувацький файл перемикача і переключив модем з командного рядка ( sudo usb_modeswitch -I -c 19d2:2003).

  3. Як тільки перемикання було здійснено, мені повідомили, що я Mobile Broadband Networkввімкнув програму New Broadband Connection у меню менеджера мережі.

  4. Я встановив вищезгадане з'єднання звичайним способом (назва APN не була проблемою), і з'єднання було встановлено автоматично.

  5. Я відключив і вийняв модем.

  6. Зупинено захоплення журналу MM.

Повний журнал ММ та системний журнал для запуску сеансу для модему викидання можна знайти тут .

Тест 2

Той самий тест з 64-розрядним DVD-диском Ubuntu 14.04.

Журнали можна знайти тут .


Оновлення 10 - 09 грудня 2015 року

Цього разу перевірили wvdialі виявили, що якщо wvdialзапустити як root, ми отримаємо успішне з'єднання.

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

Первинна думка: ситуація може мати щось спільне з групою користувачів відповідного користувача.

Але як зазначено тут ,

З усіма цими інструментами, щоб встановити комутований зв’язок, користувач повинен бути членом груп "dip" та "dialout", тому розміщуйте всіх користувачів, які повинні підключитися через комутований комутатор до цих груп.

Але як ми можемо знайти,

$ 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. Спробував підключитися. Невдало.

Файл syslog тут .


Оновлення 13 - 10 грудня 2015 року

З відчаю, щоб побачити, чи впливають деякі локальні зміни на з'єднання, протестували апарат із DVD-дисками Ubuntu 15.04 та 15.10.

  1. Завантажили машину за допомогою 64-бітного DVD Xubuntu 15.04. Зв’язок був вдалим, як шарм.
  2. Завантажили машину за допомогою 64-розрядного DVD Ubuntu 15.10. З'єднання не вдалося, як і раніше.

Що сталося між 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. Викинув модем.

Машина зависає один раз, це випадкова подія? Моя машина зазвичай не висить раз на рік.

Syslog файл і створені файли правила знаходяться тут .


Оновлення 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. Перезавантажили і спробували весь процес знову. Знову невдало.

Файл syslog (повний, я не ризикував пропустити будь-яку важливу частину) і згаданий файл правил (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його на місці?

Файл syslog (повний, я не ризикував пропустити якусь важливу частину) і згаданий файл правил (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. Викинув модем.

Файл syslog і згаданий файл правил (40) тут


Оновлення 18 - 11 грудня 2015 року

  1. Покладіть всі файли правил у їх первісну форму.

  2. Переглядав lsusbвихід кожну секунду за допомогою сценарію оболонки. Захоплений вихід у файлах із штампом часу.

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

  4. Спробував підключитися. Невдало.

  5. Викинув модем.

Файл syslog, lsusbвихідні штампи та часові файли правил є тут .

Тепер ви, можливо, захочете співставити виходи syslog із часовими позначками.


Оновлення 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, просто щоб побачити, де він ламається. Я насправді намагався, але здався через нескінченні проблеми залежності.

Усі вищезазначені файли відмінностей тут .


Оновлення 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на місці.

Імена файлів журналу не є зрозумілими.

Усі вищенаведені файли журналу плюс syslog та 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-родовий, збій.

  3. 4.0.9-040009-загальний, збій.

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


Оновлення 23 - 16 лютого 2016 року

Модем почав функціонувати в Ubuntu 16.04. Ця версія все ще в Альфа 1, але чудово працює у моєму ноутбуці.


1
У минулому я натрапив на подібну проблему, і в кінцевому підсумку довелося вимкнути DHCP та використовувати адреси шлюзу від мобільної компанії та використовувати DNS-сервери Google. Це було два-три роки тому, і я не пригадую потрібних точних кроків, і не знаю, чи це та сама проблема, але помилка була майже дослівна. Бажаю, щоб я міг допомогти більше.
KGIII

1
@KGIII Я хочу спробувати це. Лише один непрацюючий запит, якщо він пов’язаний з DHCP, як це працює в Windows? Чи має DHCP-сервер якесь значення при розподілі адреси? Більше того, той же апарат Linux (в якому модем не підключається) працює з Ethernet DHCP. У будь-якому випадку, експеримент із реального життя буде вартим тисячі простою.
Массор

Я думаю, що Windows обробляє мережу по-іншому, і, можливо, вони вже налаштовані для роботи з цим конкретним обладнанням або обладнанням. Я не дуже приділяв багато уваги Windows, як пізно, тому я, мабуть, не найкращий джерело інформації для цього.
KGIII

@KGIII Я спробував встановити адреси. На жаль, єдині два варіанти, доступні для мобільного широкосмугового з'єднання - це два аромати, автоматичний (PPP). Отже, це закрита дорога. Все одно, дякую.
Массор

1
Просто для усунення ядра як джерела проблем, ви можете спробувати встановити ядра 4.0 та 4.1 з kernel.ubuntu.com/~kernel-ppa/mainline та протестувати їх?
муру

Відповіді:


4

Завантаження 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. Але і це не є чим займатися примхи, тому, можливо, нам потрібно трохи роздивитись, щоб отримати більше доказів, що це (зараз) проблема, і, якщо можливо, знайти інші способи подолати її. Або, маючи трохи удачі, хтось, хто щось знає, потрапляє на ...

EDIT 2

Так, відкат версій непростий через залежності. Та й катання власних теж далеко не радість.

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

Думаю, проблема полягає в тому, що ModemManager вибирає контекст PDP 1 з apn = 'wap', де він повинен обрати контекст 9 PDP з apn = 'WAP'. Можливо, це можна вирішити, скориставшись одним із цих інструментів. Або бути в змозі примусити вибір 9 під час з'єднання, або видаливши поганий контекст 'wap' з модему, до якого рекламований інструмент тестера модулів.

Інструмент тестеру модему, здається, є інструментом java у браузері, тому вам потрібен налаштований вами браузер, щоб знати, де знаходиться ваша java, і вам потрібно знати про те, про яке ви знаєте. Тоді, будь ласка, вивчіть такий підхід; Я сам не користувався цим, але, бачачи скріншоти, я здогадуюсь, що це буде представляти контексти PDP як вкладку "Дзвінки даних", де ви спочатку приймаєте до відома все, що відображається, а потім редагуєте записи "wap" на спотворюють ярлики apn 'wap' на, скажімо, "wap1" та "wap2" (щоб "приховати" їх під час пошуку "WAP"). Потім збережіть і закрийте і знову жонглюйте донглом. Захопити колоду; здається, що системного журналу зараз достатньо, якщо він все-таки відмовиться грати.

mmcliКоманда також здається корисною в цій історії; робити , man mmcliщоб читати про це, але я не бачу нічого про PDP контексти там.

EDIT 3

Гарний дзвінок! для тестування з DVD. Це сказало нам, що я не в тому, що я рухаюся з APN, і що все лежить у тому, щоб отримати PPP. Принаймні, це було б моє нове дерево, на яке потрібно брасти.

По-перше, ми зауважимо, що існує різниця у версіях для pppd (від 2.4.5 до 2.4.6), але це, мабуть, не проблема, оскільки тоді на цій екскурсії мали б бути всі охочі.

Хм, ппп; Мені потрібно збудити свої спогади останнього тисячоліття :-). На жаль, я сьогодні зайнятий, але я торкнуся бази, коли наступного часу встигну, щоб побачити, як далеко ви зайшли. Мої перші задні аллеї, на які слід звернути увагу, були б: 1) це користувач у потрібній групі? 2) правомочні права? 3) чи правильно мод файлу конфігурацій ppp / chat? Журнал налагодження ppp виходить у nm.txt (як за кілька днів тому), але також повинен бути спосіб запитати його для більш детальної реєстрації.

РЕДАКТ 4

Забезпечте /etc/ppp/pap-secretsі /etc/ppp/chap-secretsмати групу dip(використовуючи chgrpза потребою) та режим 740(або -rw-r-----) (використовуючи chmodза потребою). Моя не стала.

РЕДАКТ 5

Як щодо цього дерева, тоді: Порівнюючи робочий wvdialsyslog з неробочим syslog, здається, що з певних причин wvdialвикористовується, ttyUSB3коли непрацюючий ModemManagerпродовжує використовувати ttyUSB1. Я не впевнений , якщо це взагалі істотним, але , по- видимому , але ttyUSB1і ttyUSB3як реагувати , як AT , здатні модеми.

Тож, як тест, можливо, ви можете відредагувати, /etc/wvdial.confщоб він [Dialer Defaults]входив у рядок:

Modem = /dev/ttyUSB1

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

РЕДАКТ 6

Я думаю, що журнал dmesg можна ігнорувати; так було у всіх журналах. Новий syslog показує лише тест ttyUSB3, але, можливо, ми можемо припустити, що життя покращиться, якщо NetworkManagerможна буде користуватися ttyUSB3 і ігнорувати ttyUSB1 (для цього модему).

Я також виявив ( https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/819784 ) з особливим повідомленням № 10, що розчаровує :-(

Мабуть, застосовне udevправило /lib/udev/rules.d/77-mm-zte-port-types.rulesне застосовується, але, мабуть, слід куди подітись. І, маючи лише дуже рудиментарний, до 101 погляд на udevмагію, я б як-небудь розглянути питання про його четвертий рядок, який говорить:

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. Однак зрозуміло, що плагін Generic модем так чи інакше використовується. Тепер, можливо, usb_modeswitchнеправильне також правило, яке я вам дав на початку; він вирішує перейти на "2003", коли я подумав, що він перейшов з "2003". Але, man usb_modeswitch(який я подивився на раніше) вид припустити , що вона переходить в ідентифікатор продукту , а не від нього. У будь-якому випадку журнал показує, що це має відбутися. Таким чином, будь ласка, змініть це правило, щоб натомість використовувати "1232", і спробуйте ще раз.

Якщо нічого іншого, принаймні я повинен трохи дізнатися про udev.

РЕДАКТ 9

Добре. Проблема все ще полягає у тому, що ModemManager скидає плагін ZTE під час попереднього зондування. Журнали налагодження ModemManager для 15.10 (набори журналів "налагодження *") всі розповідають про те, що плагін ZTE відкидається через тест vendor-id / product-id.

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

А може, тут є питання про терміни. Наприклад, що ModemManager виконує попереднє зондування під час пристрою 19d2 / 1232. Ця думка узгоджується із зауваженням, що наявність 78-mm-zte-port-type-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

(Я майже в кінці своєї прив’язки тут, але у мене залишилося ще одне-два вдихи :-)

По-перше, всі 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Установка є ефектом 60-serial.rulesправила (званим 60-persistent-serial.rulesраніше), і додали умова маркування правила просто , що це має значення.

Умова не є атрибутом ZTE, а лише для того, щоб правило було більш загальним. Одним із кроків конкретніше було б скоріше вимагати ENV{.MM_USBIFNUM}="?*"замість цього, оскільки це призначення відбувається за допомогою 77-mm-zte-port-types.rules.

Взагалі, я не дуже впевнений у udevвпорядкуванні правил, і я також зовсім не впевнений, що це дійсно перестає ModemManagerдіяти занадто швидко. Однак якщо цього не 80-mm-candidate.rulesвідбудеться , то функціонування мало би мало, і, можливо, тоді все зведеться до "покращень" до ModemManager15.04.

21 EDIT

зітхати. Можливо, не має значення, але ви можете перевірити свій 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 у віртуальній скриньці, якщо, звичайно, це вже все є у віртуальній.

Я думаю, що мені потрібно претендувати на поразку.


На жаль, не вийшло. Будь ласка, дивіться журнали в моєму запитанні.
Масрур

Хм. Цей журнал передбачає, що він з'являється на рівні модему, але не працює на рівні ppp. Ви б не хотіли, щоб і журнал nm.txt відбувався, і, можливо, syslog, для підключення / жесту. До речі, я вважаю, що це також не на кабелі, коли ви підключаєте модем.
Ральф Ронквіст

Оновлений той самий .zip файл із ще двома журналами. Я вказую на те, що (м'який) відключити кабель під час тестів. Хоча кабель ніколи раніше не був проблемою. Раніше, купуючи пакети даних перед поїздкою, я завжди перевіряв модем у своїй домашній машині (ПК) з підключеним кабелем і згодом використовував модем у своєму ноутбуці. Знову ж, спасибі за запитання, немає жодної шкоди, щоб переконатися в цьому.
Массор

Зверніть увагу на мою редакцію у відповіді: наступна дика здогадка. ура.
Ральф Ронквіст

Пробував декілька рядків APN, малі та великі регістри, все. Не вдалося. Розчарування в дорозі.
Массор

1

Модем почав функціонувати в Ubuntu 16.04. Ця версія ще знаходиться на стадії розробки, але чудово працює у моєму ноутбуці.

Я б хотів, щоб я міг надати більше технічних деталей щодо того, як воно почало функціонувати.


0

Після погляду на це, здається, це не вперше з цим драконом належним чином. Раніше це було помилкою в 12.10 та 13.04, можливо, помилка ніколи не була виправлена ​​або новий патч зламав щось, що раніше працювало правильно.

Сподіваємось, якщо я читаю ваші технічні характеристики правильно, мені потрібно вказати на цей напрямок (MF190J):

3G-модем (ZTE MF190J) все ще потребує налаштування вручну.


На жаль (?) usb_modeswitchПравило для цього пристрою вже було у стандартному наборі правил.
Ральф Ронквіст

-2

Ви спробували це:

 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

і це може спрацювати нормально таким чином.


Яку IP-адресу потрібно ввести? Це з'єднання ДПП.
Массор

1
-1 для написання перекрученого сценарію, що не містить нічого, крім неправильних синтаксисів у всьому світі .. також ви знаєте, що shнасправді посилається на це dash?
heemayl
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.