Huawei USB 3G Модеми та нумерація

У мене є модем Huawei E353, який я використовую з Raspberry Pi.

Коли я підключаю його, я отримую три TTYs - ttyUSB0, ttyUSB1 і ttyUSB2.

Але іноді модемний інтерфейс (де ви можете оформити AT-команди Hayes-типу) знаходиться на ttyUSB0 і іноді це на ttyUSB1.

Я не можу помітити жодного загального фактора, що робить різницю. І я не впевнений, але здається, що він завжди робить те ж саме на тій самій Pi (або, можливо, в тому ж самому ключі - у мене є декілька з них і не було можливості спробувати різні комбінації занадто багато) .

Чи може хтось запропонувати, що впливає на нумерацію tty?

— Tom
джерело

Відповіді:

Проблема, яка виникає, не є унікальною для пристроїв Huawei (тому ви можете отримати кращу відповідь, якщо ви вилучите її з назви).

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

Специфіка незначно відрізнятиметься від розподілу, але це зазвичай означає використання lsusb для пошуку унікальних атрибутів для пристрою, а потім кодування рядка для відповідності цих атрибутів у файлах налаштування udev. Google є вашим другом тут - googling udev try правила [розповсюдження] повинні дати вам специфіку, яка вам потрібна.

— davidgo
джерело

Я думаю, що ви пропустили тут. Я знаю, що коли я підключаю USB tty, нумерація буде ненадійною. Але справа тут в тому, що вони є три ttys для те ж саме Пристрій USB. lsusb не відображає їх як окремі пристрої з окремими ідентифікаторами. Я не зовсім впевнений, як відрізнити їх через udev.

— Tom

Все нумерація пристроїв (жорсткий диск, tty, що завгодно) повинна розглядатися як ненадійна, а не послідовна завантаження, тому що це може відбуватися у випадковому порядку.

Подивись на lsusb і dmesg щоб дізнатися деталі того, як створюються дні, а потім писати відповідні udev правила для створення символічних посилань з постійними іменами, на які можна покластися.

Редагувати :

Так, я прекрасно розумів, що це один пристрій, яким керує один драйвер, який виробляє три тті. Ви не можете розрізнити їх у вихідних даних lsusb (але ви можете бачити ідентифікатор постачальника / пристрою, який вам потрібно визначити, що відбувається в dmesg ), але я впевнений, що ви можете знайти відмінні атрибути udev.

Якщо нічого немає dmesg (малоймовірно), використовуйте

udevadm info -a -p  $(udevadm info -q path -n /dev/ttyUSB0)

щоб пройти шлях пристрою і побачити атрибути, і

udevadm monitor --udev --property

щоб отримати уявлення про те, що udev думає, що це робиться під час підключення пристрою.

— dirkt
джерело

Це може бути неправильним залежно від вашого розповсюдження.

— davidgo

@davidgo: Я все ще маю бачити нестандартний розподіл, де це неправильно. Чи потрібно розробляти? Принаймні для будь-якого розподілу використовуйте udev, це не неправильно.

— dirkt

Вибачте. Перший рядок вашої публікації вимикає мене - адже справедливі кілька пристроїв кодуються сучасними ОС для отримання фіксованих адрес (на основі udev) під час виконання - Ethernet пружини для початку, а також диски, на які звертаються імена uuid або partition багато інших. Ваше рішення для розробки правил udev - це місце, хоча.

— davidgo

@davidgo: І зауважте, що навіть нові назви мережевих інтерфейсів стилю не завжди працюють надійно - є кілька питань щодо stackexchange, що стосуються цього. Отже, просто не покладайтеся на них, якщо вам з якихось причин потрібно ідентифікувати конкретний пристрій.

— dirkt

Що стосується іншої відповіді, ви, здається, пропустили точку зору. Це не окремі пристрої, а один USB-пристрій, яким керує один драйвер ( huawei_cdc_ncm ), що представляє три ttys. Я не впевнений, як відрізнити ttys на виході lsusb - тим більше, що, здається, пристрій не представляє стандартний usbserial інтерфейс (всі інтерфейси або USB Mass Storage клас або клас 255 - Vendor Specific).

— Tom