настройка_pppoe-соединения_в_debian_squeeze — Зейское сообщество пользователей Linux и Unix

Ранее я уже упоминал про трудности выбора “хорошего” LTE-модема под Linux. Сейчас продолжу тему.

Но сперва немного истории. По модели абстракции Linux (HAL=Hardware Abstraction Level) все устройства делятся на символьные и блочные. Блочные – это такие, для которых возможно позиционирование путём указания номера блока. Например, жёсткий диск. Символьные устройства позиционироваться не умеют, но в них можно записывать поток данных и/или читать что-нибудь оттуда. При этом, когда мы читаем, мы не можем выбирать что читать, а что – нет. Вот вам выхлоп, а дальше сами разбирайтесь что с ним делать.

Модемы с точки зрения Linux относятся к символьным устройствам, расцениваются как как “телетайпы” (TTY = TeleTYpe), они же “псевдотерминалы”, и обозначаются как-нибудь вроде /dev/ttyS0 (в случае RS232) или /dev/ttyUSB0 (USB). Для управления модемом в своё время были разработаны наборы AT-команд, а для передачи данных – протокол PPP (Point-to-Point Protocol).

Давным давно, когда компьютеры были большими, а программы – маленькими, для выхода в интернет применялись DialUP-модемы. Они представлялись в системе как serial terminal (ttyS0), посредством AT-команд получали информацию о том, какой номер набирать. После успешной установки соединения управление передавалось PPP-демону, который отсылал аутентификационную информацию, после чего устанавливал канал передачи данных. То есть PPP записывал в /dev/ttyS0, читал оттуда же и через виртуальный сетевой интерфейс ppp0 отдавал ядру пакетики, которые наполучал с той стороны.

Производители первых 3G модемов решили не заморачиваться с изобретением велосипеда и пошли по тому же пути. Хоть сотовый оператор связи в 99% случаев и не требует аутентификации по логину-паролю (что логично), но вот название точки доступа (APN) должно быть известно модему ещё до начала установления соединения. Как же его передать модему? AT-командой. А там, где AT-команды, там и PPP. И это несмотря на то, что PPP-сессия в реальности дальше модема не уходит. Сам модем её же и терминирует (декапсулирует), после чего шлёт данные оператору в виде обычного IP-трафика.

Но с появлением стандарта LTE возник затык. Максимальная скорость PPP-соединения в Windows ограничена пределом в 25 МБит/c. А сеть умеет и больше. Хоть и не хотелось, а велосипед изобретать таки пришлось. И наизобретали их даже больше, чем могли бы.

Qualcomm для своих чипов придумала интерфейс “QMI”. В Linux-е их поддерживает драйвер “qmi_wwan.ko”, они представляются в виде беспроводной сетевой карты “wwan0”. ЧСХ, в bridge запихнуть такую чудо-псевдосетевуху нельзя. Производитель “Sierra Wireless”, который выпускает довольно популярные в народе LTE-терминалы, продаваемые под десятком различных брендов, придумал собственный режим “Direct IP”. В Linux-е он поддерживается драйвером “sierra_net.ko”, интерфейс может быть виден как “usb0” либо как тот же самый “wwan0”. ЧСХ, внутри Sierra как правило находится всё тот же самый Qualcomm. И иногда одно и то же устройство (например, Sierra M7710) может работать как в одном (QMI), так и в дргугом (Direct IP) режимах.

Некоторые производители “мопедов” эмулируют виртуальную сетевую карту по протоколу NDIS. Им это удобно, потому что не нужно колхозить собственные драйвера: и Windows, и Linux понимают NDIS “из коробки”. Другое дело, что модемом в таком случае всё равно нужно как-то управлять. Если оный жёстко привязан к какому-либо оператору, то проблем скорее всего не будет. А если нет, то ему надо всё равно как-то сообщить название точки доступа (APN). Об этом чуть ниже.

Некоторые производители делают из модема а-ля “полноценный роутер” с блэкджеком и шлюхами NAT-ом и веб-мордой. Это, например, какой-нибудь Yota-самец или Huawei в режиме “HiLink”. Тут понятно: NAT он и в Африке NAT. При большом количестве соединений вычислительные мощности модема не справляются, “честное” IPSEC-соединение установить не удастся. В-общем, в газенваген сразу.

Дык как же осуществляется управление модемом? А очень просто. Модем теперь вообще не модем, а целый USB-хаб. Который при подключении в систему анонсирует сразу большую пачку USB-терминалов: для управления, для статистики, для передачи данных, для GPS (если есть) и так далее. В Linux они видны как “/dev/ttyUSB0”, “/dev/ttyUSB1”, “/dev/ttyUSB2” и т.п. Который из них для чего служит, выясняется либо опытным путём, либо раскуриванием документации к устройству.

И напоследок про основное отличие интерфейса QMI от всех остальных способов взаимодействия с модемом. В QMI передача данных и управление модемом (AT-команды) осуществляются через один и тот же псевдотерминал. Соответственно, чтобы отделять зёрна от плевел одно от другого во входящем потоке данных, требуется специально обученная софтина. В Linux-е этим занимается всё тот же “qmi_wwan.ko”, но он как бе внезапно kernel-space. Стало быть, где-то рядом обязательно должна валяться userspace-утилита, которая говорит драйверу что делать и куда идти.

Для не-QMI и не-PPP интерфейсов ситуация несколько проще. Там каналы управления и канал данных разнесены по разным псевдотерминалам (например, управление по /dev/ttyUSB0, а данные идут через /dev/ttyUSB1). В этом случае командовать модемом можно напрямую через псевдотерминал (“echo давай_уже_звони > /dev/ttyUSB0”). А драйвер только эмулирует сетевой интерфейс и пересылает данные оператору связи.

Как-то вот так всё непросто. Если повезёт, напишу вторую часть, практическую.