Подключение через USB-модемы
Резервный или основной мобильный интернет через более чем 150 модемов
Любой Keenetic, у которого есть USB‑порт, работает с USB-модемами мобильного интернета 3G/4G. Все устройства в домашней сети могут одновременно пользоваться интернетом через один USB-модем.
Основной и/или резервный
USB-модем, который вы подключите к «Кинетику», может служить как основным и единственным средством выхода в интернет, так и резервным для для любого другого настроенного активного подключения. Вы даже можете резервировать один модем другим: на двухпортовых интернет-центрах подключая их непосредственно, а на моделях с одним USB-портом — через USB-хаб. В интернет-центре остается только указать, в какой последовательности модемы должны сменять друг друга или страховать проводного провайдера.
Совместимость и/или скорость
Современные USB-модемы 3G/4G/LTE умеют работать в нескольких режимах: RAS, CDC-Ethernet, NDIS. Если модем входит в число более чем 150 нами поддерживаемых, будьте уверены, что интернет-центр запустит его в оптимальном скоростном режиме (то есть CDC-Ethernet или NDIS, а не RAS). Кстати, мы единственные продолжаем поддерживать модемы Yota согласно спецификации Yota Ready, когда интернет-центр инициализирует LTE-модем и начинает раздавать интернет вообще без какой-либо настройки. Вставил и работай.
В первую очередь мы добиваемся совместимости с предоставленными нам операторскими модемами (на операторских прошивках). Алгоритмы универсальной поддержки не доступных нашей лаборатории модемов с разномастными альтернативными прошивками также постоянно совершенствуются.
Связь без капризов
Вы наверняка слышали, что интернет-центры Keenetic, в отличие от многих других роутеров, умеют управлять питанием USB-модемов. Зачем это нужно? Дело в том, что многие современные модемы — это самостоятельные устройства, которые стартуют и работают независимо от интернет-центра. С одной стороны, это хорошо. Но с другой, многие компактные USB-модемы рассчитаны главным образом на эпизодическую работу в ноутбуке, но не на круглосуточную работу, от которой они, увы, могут сбоить или зависать. С помощью функции Ping Check интернет-центр Keenetic сам обнаружит, что интернета по какой-то причине нет, и автоматически перезагрузит модем по питанию, чтобы связь появилась снова.
Cdc ethernet что это
Поддерживаемые частоты
GSM / GPRS / EDGE 850 / 900 / 1800 / 1900
UMTS / DC-HSPA+ /WCDMA 900 / 2100
LTE 800/900/1800/2100/2600 MHz
Дополнительно
Поддержка карт MicroSD до 32 ГБ
Операционные системы:
Поддержка OC Windows XP SP3, Windows Vista SP1/SP2, Windows 7, Windows 8, Mac OS X 10.5, 10.6, 10.7, 10.8, Linux
PS: самая беспроблемная схема с роутером: прошивка HiLink на модеме с автопереключением в CDC + Zyxel Keenetic 4G III rev.A с прошивкой Padavan
Модифицированный веб-интерфейс для E3372 s на основе WebUI 16.100.05.00.03
Ориентирован на работу с прошивкой 22.286.03.00.00.
Работает также и с модифицированными прошивками 22.286.53.01.161_S_*.
Несовместим с оригинальной билайновской прошивкой 22.286.53.01.161 в части SMS.
После прошивки веб-интерфейса следует делать сброс настроек (Настройки->Система->Настр. по умолч.).
Предлагаю своё решение для ситуации, когда нужно перевести HiLink-модем в режим с портами, но http://192.168.8.1/html/switchProjectMode.html (switchDebugMode.html) не работает.
Для этих портов необходим драйвер FcSerial.
Надеюсь, что тут все понятно. Единственное необходимое пояснение: кнопка reverse переворачивает IMEI задом наперед. Это нужно для вычисления кодов в команде at^spword модема 3372.
В заключении, хочу выразить благодарность пользователям rust3028 и Chujoi13 за неоценимую помощь в подготовке и тестировании этого релиза.
Еще можно сделать переключение внутри самого модема. Для этого надо написать простенькую программку:
#include
#include
#include
#include
void main() <
int nfd=open(«/dev/ndisapp»,2);
ioctl(nfd,1,0);
>
Собрать ее с помощью android ndk и запускать внутри модема. Именно таким способом производит переключение сам вебсервер.
Кстати, у rust3028 уже имеется готовая программа переключения с произвольной задержкой, готовая для включения в autostart.
rust3028, может быть выложишь ее сюда, чтобы людям не мучаться с освоением ndk?
Автоматическое переключение модема в Debug Mode и Project Mode
Подходит для обоих модемов, на любой прошивке HiLink.
затем зайти по ftp на адрес 192.168.8.1 и забрать файл.
Полученный файл mtd11.bin содержит в себе упакованный образ vxworks, к которому добавлен заголовок раздела. Следующим этапом нам надо распаковать этот образ, отрезав предварительно заголовок. Это можно сделать так:
— Долго жмем ентер, пока таблица не закончится
— Закрываем лог в терминальной программе.
Во второй части я расскажу о встроенном в VxWorks отладчике, жизненно необходимом для исследования кода. В качестве пример мы заставим сам модем посчитать nlock-код по алгоритму v201.
Break at 0x50d818c0: VerifySL Task: 0x53e964b8 (I0_TAF_FID)
task stack: base 0x5414f000 end 0x54147000 size 32768 high 896 margin 31872
exc. stack: base 0x54151ffc end 0x54151000 start 0x54152000
exc. stack: size 4092 high 624 margin 3468
proc id: 0x5245028c ((null))
options: 0x9005
VX_SUPERVISOR_MODE VX_DEALLOC_STACK VX_DEALLOC_TCB VX_DEALLOC_EXC_STACK
VxWorks Events
—————
Events Pended on : Not Pended
Received Events : 0x0
Options : N/A
r0 = 0x5372759c r1 = 0x5414ef3c r2 = 0x00000000
r3 = 0x00000000 r4 = 0x5414ef3c r5 = 0x5372759c
r6 = 0x53727580 r7 = 0x00000000 r8 = 0x5369fb60
r9 = 0x00000010 r10 = 0x0000000f r11/fp = 0x5414ef60
r12/ip = 0x32303634 r13/sp = 0x5414ef38 r14/lr = 0x51463690
pc = 0x50d818c0 cpsr = 0x600c0113 ttbase = 0x53f74000
value = 0 = 0x0
[C]->b 0x50D819C0
value = 0 = 0x0
[C]->c
Break at 0x50d819c0: VerifySL +0x100 Task: 0x53e964b8 (I0_TAF_FID)
task stack: base 0x5414f000 end 0x54147000 size 32768 high 896 margin 31872
exc. stack: base 0x54151ffc end 0x54151000 start 0x54152000
exc. stack: size 4092 high 624 margin 3468
proc id: 0x5245028c ((null))
options: 0x9005
VX_SUPERVISOR_MODE VX_DEALLOC_STACK VX_DEALLOC_TCB VX_DEALLOC_EXC_STACK
VxWorks Events
—————
Events Pended on : Not Pended
Received Events : 0x0
Options : N/A
r0 = 0x537273ec r1 = 0x5414ef0c r2 = 0x00000006
r3 = 0x51bfe9c8 r4 = 0x5414ef0c r5 = 0x5414ef3c
r6 = 0x0000000f r7 = 0x537273ec r8 = 0x5369fb60
r9 = 0x00000010 r10 = 0x0000000f r11/fp = 0x5414ef34
r12/ip = 0x00000006 r13/sp = 0x5414ef0c r14/lr = 0x5414ef14
pc = 0x50d819c0 cpsr = 0x200c0113 ttbase = 0x53f74000
value = 0 = 0x0
[C]->d 0x5414ef0c,8,1
NOTE: memory values are displayed in hexadecimal.
0x5414ef00: 36 34 33 31 * 6341*
0x5414ef10: 35 30 38 39 *5084. *
value = 0 = 0x0
Вот так мы вычислили nlock-код c помощью модема. Этот код является абсолютно точным, образцовым. Можно при входе в процедуру VerifySL c помощью команды m вписать в память другой IMEI, и вычислить nlock-код от него. Я использовал эту возможность для отладки своего калькулятора кодов.
Возможности отладчика VxWorks очень обширны. Вот крайткий список полезных команд:
Надеюсь, моя статья подвигднет кого-нибдуь на изучение кода модема. Поверьте, это крайне увлекательное и полезное занятие!
Видеонаблюдение загородом посредством 3G интернета
Что бы решить данную задачу я решил построить такую сеть.
Взять самый дешевый сервер VDS. Недорогой роутер TP-LINK MR 3420, 3G модем от beeline, ip камеру. И построить такую сеть как на схеме.
Суть идеи такова: На сервере поднимается openvpn сервер, на роутере поднимается openvpn клиент, далее объединяем локальную сеть с сетью openvpn. Затем пробрасываем необходимые порты на сервере.
Описание сети:
Первая сеть это роутер + ip камера + ваш компьютер (шлюз). Адрес сети будет 192.168.0.0
У роутера 192.168.0.1
У камеры 192.168.0.100
У вашего компьютера, который будет шлюзом 192.168.0.2
Вторая сеть, это сеть openVPN – 192.168.3.0
IP адрес openVPN вашего роутера будет 192.168.3.2
IP адрес вашего сервера будет 192.168.3.1
И внешний ip адрес сервера для примера будет 205.234.139.100
Настройка openVPN на сервере.
Как настроить сервер openvpn, до пункта “Объединение сетей”, описано тут: Настраиваем OpenVPN сервер на подключения клиентов
Конфигурация сервера выглядит примерно так:
Чтобы каждому клиенту выдавался определенный ip адрес, в конфиге есть строчка
Создаем на сервере документ в папке /etc/openvpn/
Под названием ipp.txt
И в нем пишем “имя клиента, ip адрес”
Например вот так
Прошивка и настройка роутера TP-LINK MR3420.
Как прошить роутер описано по ссылке: TP-Link TL-MR3420 & TL-MR3220
Для начало нужно дать выход роутеру в интернет для установки дополнительного ПО.
Для того что бы роутер мог выйти в интернет заходим через web (http://192.168.1.1), заходим в network. Далее жмем edit в lan
Переходим на вкладку General Setup и изменяем ip локальное сети на
IP адрес: 192.168.0.1
Маска: 255.255.255.0
Шлюз: 192.168.0.2
DNS: 8.8.8.8
Для того что бы изменения вступили в силу, жмем «Save & Apply»
На компьютере поставим себе ip 192.168.0.2, и используем его как шлюз.
Теперь нужно расширить память роутера для установки дополнительного ПО.
Для этого берем флэшку (Например 4 Гб) и форматируем ее с файловой системой ext4.
Затем вставляем ее в USB хаб и подключаем к роутеру USB хаб.
Потом нужно перенести все настройки на флэшку и сделать что бы она сама монтировалась при старте.
Устанавливаем пакеты для флэшки:
Создаем точку подключения:
Затем монтируем флэшку:
Копируем туда установленные пакеты:
Немного правим конфиг:
Чтобы выглядело вот так:
Затем перезагружаем роутер:
Теперь мы не ограничены исходным размером flash роутера. И можем себе позволить поставить практически все
Смотрим свободное место:
Теперь нам нужно установить openvpn клиент на роутер, заодно и текстовый редактор nano, файловый мэнеджер mc, и русификатор luci.
Устанавливаем необходимые нам пакеты:
Для нормальной работы mc нужно выполнить две строчки:
И чтобы каждый раз их не выполнять руками нужно их добавить в /etc/profile:
Затем копируем на роутер в /etc/openvpn/ ключи и сертификаты созданные на сервере openvpn:
Объединим сети 192.168.0.0 и 192.168.3.0:
Ваш ip сервера openvpn 192.168.3.1, а ваш Ip на роутере openvpn адаптера tap0 192.168.3.2
Тогда что бы ваш сервер смог увидеть вашу локальную сеть (192.168.0.0) нужно на сервере прописать маршрут.
Теперь вашу локальную сеть на роутере вид ит сервер с openvpn.
Настроим проброс порта:
Допустим ваша ip камера работает по порту 99, тогда чтобы пробросить порт камеры или другого сетевого устройства пропишем такие строки в консоли, или как описано ниже создаем файл и пишем в него:
Теперь вы можете конектится к ip камере по адресу 205.234.139.100:99.
А чтобы не делать это вручную после перезагрузки сервера, создадим скрипт, в папке /root/ файл с названием start
и дадим ему права на выполнения:
Затем добавим строку в /etc/crontab
Теперь после перезагрузки сервера скрипт автоматически запустится.
Установка usb 3g Ethernet модема от huawey
Вставляем модем в USB хаб,
И пишем команду dmesg, вы должны увидеть примерно такие строки:
Это говорит о том что модем установлен и определился как eth2.
Следующим шаом нам нужно добавить 2 сетевых интерфейса.
1. 3G
2. VPN
для этого правим конфиг:
3G у нас будет DHCP клиентом, а VPN неуправляемым адаптером, добавляем:
В общем виде конфиг должен выглядеть примерно так:
Что-бы сервер мог видеть все 3 сети, нужно их объединить в межсетевом экране
Для этого изменим файл /etc/config/firewall
Сделать примерно так:
И делаем перезагрузку роутера
Усиления 3G сигнала на модеме.
Следующим шагом нужно припаять другой конец провода к модему:
Вскрываем корпус модема.
На лицевой стороне расположены: модуль для карты памяти, контакты для SIM-карты, радио модуль под крышечкой, разъём, внутренняя антенна и USB-выход.
Интересно, что этот разъём недоступен без разборки корпуса, то есть почти все обладатели этого модема об этом разъёме даже не подозревают. Пусть он остаётся на месте, он нам не нужен и нисколько не мешает. А мешает нам внутренняя антенна:
Антенна вытравлена прямо на плате, и нам необходимо её отключить. Для этого сначала выкусываем SMD-конденсатор, предназначенный для резонансной согласовки антенны. Потом небольшой фрезой, зажатой в дрель, делаем пропил по антенне, оставляя только небольшую площадку для припайки кабеля. Разрез делаем неглубоко, так как печатная плата многослойная. Прозваниваем тестером, успешно ли прошла «ампутация» и нет ли КЗ между площадкой под припайку кабеля и отрезанной антенной. Кстати, иногда эта площадка может иметь КЗ на землю – таковы особенности архитектуры некоторых модемов. Если бы мы не отрезали внутреннюю антенну, то после подключения внешней антенны сигнал бы делился между ними, возникло бы рассогласование и ничего бы не получилось.
Припаиваем кабель к модему. Паяем быстро, точно и аккуратно, не перегреваем плату. Центральную жилу припаиваем на площадку, оставшуюся от внутренней антенны; оплётку припаиваем к любому месту, являющемуся землёй и расположенному как можно ближе к площадке с припаянной центральной жилой.
После припайки кабеля, нужно аккуратно собрать модем и необходимо поднять антенну на максимальную высоту, затем методом проб поймать наилучший сигнал и закрепить на месте.
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Не путать с «интернет»!
Полный курс по Сетевым Технологиям
В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer
Видео: Ethernet на пальцах
Обобщенно про Ethernet
В терминах семиуровневой модели OSI (если не знаете про нее, почитайте, это интересно!), стандарт Ethernet живет на первом и на втором уровнях. На первом уровне описаны способы передачи электрических, оптических и беспроводных (радио, например) сигналов, а на втором формирование кадров (фреймов). И тут мы делаем вывод:
Ethernet “по полочкам”
Скорость
В 1999 году, благодаря технологическому “рывку”, на свет появился Gigabit Ethernet, который уже поддерживает подключения скоростью 1000 Мбит/с или 1 Гбит/с. Отметим, что “гигабитными” линками зачастую в корпоративных сетях подключает даже сервера.
Линком в профессиональной среде называют канал подключения того или иного узла. Фраза “подключил к свичу сервер гигабитным линком” означает, что коллега подключил кабелем UTP сервер к коммутатору по стандарту Gigabit Ethernet.
И пожалуй финалочку по скорость: впервые в 2002 году IEEE опубликовал стандарт 802.3ae, в котором описал 10 Gigabit Ethernet, или как его еще называют 10GE, 10GbE и 10 GigE. Догадаетесь, на какой скорости он работает? 😉
Кабели
Для работы с более высокоскоростными стандартами, такими как Gigabit Ethernet и 10 Gigabit Ethernet понадобится кабель категории 5e или 6 категории
Ethernet vs. Wi-Fi: преимущества
Стабильность сигнала
На самом деле развертывание локальной сети на базе проводного подключения дороже и сложнее. Но конечно есть преимущества, а особенно для организаций. В первую очередь, вспомним: Wi-FI передается по радиочастотам. Если вы живете в Москве и слушаю радио на машине въезжали в Лефортовский туннель вы точно знаете, что происходит с радиосигналом по мере погружения в туннель. Тоже самое происходит и с Wi-Fi.
Безопасность
Отметим, что как правило, Ethernet работает на удаленности 100 метров от от роутера. При большем расстоянии нужен некий репитер сигнала.
Ethernet vs. Wi-Fi: недостатки
Стоимость
С одной стороны, в домашней сети, достаточно просто подключить 1 кабель к порту вашего ПК и все работает. Здесь стоимость отличия от домашней Wi-Fi сети складывается только из стоимости кабеля. А что если вы организация? Кабелей нужно больше, к тому же, 1 кабель = 1 порт на коммутаторе. Соответственно, нужно закупать коммутаторы, фаерволы (безопасность, а как же?), маршрутизаторы. Именно поэтому, инвестиции в проводные Ethernet сети выше, чем в беспроводные.
Порты
Мобильность
Самое важное, пожалуй. С Ethernet вы жестко завязаны на одном месте (особенно это характерно в офисе, где у вас скоммутирована Ethernet розетка). Дома, если у вас “красивый” ремонт, кабели спрятаны под плинтус. Поэтому, мобильностью и гибкостью здесь и не пахнет.
С Wi-Fi можно легко подключать ноутбуки, планшенты и мобильные телефоны. Представьте забавный кейс: по пути в туалетную комнату, вы берете с собой ноутбук с кабелем, вместо мобильного телефона, в котором привычно листаете любимую ленту. Пожалуй, это тот самый случай, когда лучше почитать надписи на освежителе воздуха.
Итоги
Полный курс по Сетевым Технологиям
В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer
Как мы преодолевали передачу данных по USB
С чего все началось
Итак, в нашем замечательном приборе Беркут-ММТ (на базе PXA320 и GNU/Linux) есть не менее замечательный модуль OTDR (на базе STM32 и NutOS), представляющий собой импульсный оптический рефлектометр. Эта связка работает следующим образом: пользователь нажимает на экране на различные элементы UI, в приборе происходит немножечко магии, и желания пользователя трансформируются в команды вида «duration 300», которые уходят в измерительный модуль. Конкретно эта команда выставляет длительность измерений в 300 секунд. Модуль к прибору подключен по USB, для передачи команд поверх USB поднят CDC-ACM.
Кратенько — CDC-ACM позволяет эмулировать последовательный порт через USB. Так что для верхнего уровня наш измерительный модуль в системе доступен как /dev/ttyACM0. CDC-ACM служит для передачи команд в модуль или чтения текущих настроек/состояния модуля. Для передачи самой рефлектограммы служил USB Bulk интерфейс, который все свое время посвящал только одному — передаче данных рефлектограммы из модуля в прибор, как бинарного потока данных. В какой-то момент мы заметили, что рефлектограмма приходит к нам не полностью. Так мы открыли для себя, что USB может терять данные.
Схематично это выглядело так:
b5-cardifaced — это демон, который принимает команды по D-Bus и отправляет их в карту через CDC-ACM интерфейс. Результат выполнения посылает обратно по D-BUS.
usbgather — небольшая программка, которая работает на базе libusb и занимается тем, что выгребает из модуля рефлектограмму через USB Bulk и выдает ее на stdout.
Костыли и велосипеды
Сели мы и подумали — нам нужно понимать вся ли рефлектограмма к нам пришла для возможности пропуска неполных рефлектограмм. Стали мы придумывать различные хитрые заголовки, контрольные суммы и тд. Потом поняли что изобретаем ТСР. И тогда было принято волевое решение вместо USB Bulk завести TCP/IP поверх CDC-EEM. Почему CDC-EEM? Потому что CDC-EEM позволяет наиболее просто использовать USB как транспорт для передачи сетевого трафика. На самом приборе поддержка CDC-ECM в ядре есть, а модулях мы используем NutOS в качестве операционной системы и поддержка CDC-EEM и TCP/IP стек в NutOS был.
Фикс длинною в жизнь 3 месяца
Казалось бы — ни что не предвещало беды. Подняли CDC-EEM, настроили IP адреса. Ping? Есть ping! Ура. Изменили механизм передачи данных с USB Bulk на передачу данных через TCP-сокет. Вот-вот должно было наступить счастье, но тут внезапно при тестировании сеть упала с криками в dmesg о своей непростой жизни, наших кривых руках и вставшей колом очереди на отправку для нашего сетевого интерфейса. Примерно так:
Если кратенько, буквально в двух словах — каждый сетевой интерфейс имеет таймер, который засекает время с каждой последней отправки данных и если оно превысило некий интервал — мы видим это сообщение. Дальше все зависит от драйвера — некоторые после этого нормально работают, некоторые — нет.
Корень зла
Все вышеперечисленное усугублялось сообщениями в dmesg о неизвестных link cmd. Добавили побольше дебага и узнали, что нам на USB host приходит ответ на echo request, который мы не посылали.
Когда ничего не работает — настает время читать документацию. Вот и мы раздобыли доку по CDC-EEM, да не откуда-нибудь, а прямо с usb.org. Оказывается первый EEM-пакет это не только кучка данных, но еще и EEM-заголовок, в котором содержится тип пакета (управление или данные) и длина данных. И да, у CDC-EEM есть свой echo request/echo response.
Но наше счастье было бы не полным, если бы не еще одна деталь — при приеме служебных пакетов модуль зависал. Наглухо. Вместе с CDC-ACM.
У нас в модуле USB было настроено так, что передача шла пакетами по 64 байта. Соответственно один Ethernet пакет бился на N пакетов по 64 и передавался через USB. Вот так:
После весьма продолжительного изучения ситуации мы пришли к выводу, что происходит вот что: мы теряем часть EEM-пакета (да, USB не гарантирует доставку). Но мы прочитали из заголовка длину и опираемся на нее. Соответственно мы из следующего пакета вычитываем N потерянных байт, а следующие данные воспринимаем как начало нового EEM-пакета и интерпретируем первые 2 байта как заголовок. А там может оказаться все что угодно. Вплоть до взведенного в 1 бита, который указывает что это служебный пакет. В совсем плохих случаях мы ловим такие данные, которые при интерпретации как EEM-заголовок дают нам Echo Response огромной длины. Гораздо большей, чем наша оперативная память. Так мы поняли что наша реализация usbnet в NutOS требует серьезных доработок.
Больше проверок хороших и разных
В процессе ковыряния usbnet в NutOS было выяснено, что текущий вариант вообще не готов к приему служебных пакетов. От слова совсем. Мы сделали новый вариант, который стал способен корректно обрабатывать служебные пакеты, а именно: мы смотрели тип пакета, ибо на echo по стандарту мы ответить обязаны; проверяли длину — если она больше MTU — то мы явно словили мусор. Еще нашли странность в функции, запускающей передачу данных по endpoint’у: мы проверяли — не занят ли сейчас нулевой endpoint, и если занят — просто выходили и все. Вызывающий эту функцию всегда считал что передача данных запущена, а часто получалось что нет. В итоге мы теряли данные, причем в обе стороны.
Были войны с ТСР-сокетом — иногда данные не передавались и мы не видели почему. Не знаю что руководило разработчиками NutOS, но множество функций, имеющих возвращаемый тип int в любой непонятной ситуации возвращали «-1». Некоторые из них записывали реальный код ошибки в информацию о сокете, некоторые нет. Так что пришлось позаниматься протаскиванием кодов возврата с самых низов, вроде функции отправки данных с сетевухи, до самых верхов — функций типа NutTcpDeviceWrite?(). После этого мы смогли видеть где случился затык.
Потом были всякие допиливания и донастройки таймаутов в сокете, добавки статических записей в ARP-таблицы на модуле и на самом приборе: в нашей сети всего 2 устройства: прибор и модуль, нет смысла в устаревании записей в ARP-таблице.
Итоги
В нашей карте теперь есть маленький ТСР сервер, который служит для передачи данных из карты в прибор. Перед началом измерений в карте запускается TCP сервер и карта начинает ждать входящих подключений. После того, как клиент подключится к ТСР серверу, карта начинает измерения и через TCP сервер отправляет результаты в прибор.
Теперь схематично работа прибора с модулем выглядит примерно так:
Действующие лица:
b5-cardifaced — тот же что и раньше — транслирует команды из D-Bus в карту и отсылает результат обратно в D-Bus;
nc — собственно netcat, читает данные рефлектограммы из сокета и отдает их на stdout для дальнейшей обработки.
После всех этих приключений у нас теперь сетевой рефлектометр. Сетевой, правда, не на все 100% — управление происходит через CDC-ACM, а сбор данных из модуля — по TCP/IP через CDC-EEM. У нас все равно есть небольшая потеря данных, но за счет использования TCP/IP на выходе мы всегда получаем полную рефлектограмму. Мы узнали много нового о USB в целом и CDC-EEM в частности и USB я стал любить чуть меньше, чем раньше.
Нагрузочный тест показал, наш модуль на базе STM32F103 может прокачать 220 килобайт данных в секунду по TCP/IP over CDC-EEM, при том что модуль в это время занимается полезной работой и USB у нас работает без использования DMA.
