Как отключить хайлинк huawei e3372

Обновлено: 20.11.2024

Настроить ключ Huawei E3372 LTE для работы на маршрутизаторе с OpenWRT 15.05 Chaos Calmer очень просто. Для этого потребуются два дополнительных пакета: kmod-usb-net-cdc-ether и usb-modeswitch . Их можно установить либо через веб-интерфейс (Система > Программное обеспечение), либо запустив в командной строке следующее:

Появится новый сетевой интерфейс (в моем случае eth1), который просто нужно добавить в группу wan брандмауэра (Сеть > Интерфейсы > eth1 > Правка > Настройки брандмауэра > Назначить зону брандмауэра). Всё, роутер в сети! Веб-интерфейс остается доступным через браузер по обычному IP-адресу ( 192.168.8.1 ).

Для установки пакетов, очевидно, требуется уже существующее подключение к Интернету. Маршрутизатор можно временно подключить к другой сети Wi-Fi (Сеть > Wi-Fi > Сканировать > Присоединиться к сети), например. точка доступа со смартфона. Не забудьте отключить или удалить эту сеть после завершения (Сеть > Wi-Fi > Отключить/Удалить).

Двойная конфигурация NAT

При запуске серверных приложений на маршрутизаторе или в сети необходима дополнительная настройка, чтобы сделать их доступными из Интернета.

И устройство OpenWRT, и ключ Hi-Link работают в режиме маршрутизатора и отделяют внутреннюю сеть от внешней через NAT, и этот двойной NAT — довольно эффективный способ блокировать входящие соединения. Поскольку NAT нельзя деактивировать на ключе, уродливое и сложное решение часто состоит в том, чтобы отключить OpenWRT NAT и использовать вместо него ключ. Это довольно плохой обходной путь, и есть гораздо лучшее решение для ключей с доступной функцией DMZ (которая зависит от версии прошивки).

В интерфейсе конфигурации ключа ( 192.168.8.1 ) найдите настройки DMZ (Настройки > Безопасность > Настройки DMZ) и включите функцию DMZ с целевым IP-адресом 192.168.8.100 , который должен быть IP-адресом сетевой интерфейс eth1 на маршрутизаторе, к которому подключен ключ (дважды проверьте в OpenWRT в разделе Сеть > Интерфейсы > eth1 > IPv4). Теперь все входящие соединения передаются напрямую в OpenWRT. Функции брандмауэра, SIP и UPnP ключа можно отключить. В отличие от того, что говорится в других руководствах, для параметра NAT можно оставить значение по умолчанию (конус), поскольку он не оказывает никакого влияния на поведение DMZ.

В настоящее время у меня есть E8372h-608 марки Telenor, он уже разблокирован, но я пытаюсь отключить HiLink и использовать стандартное последовательное соединение. Возможно ли это с помощью usb_modeswitch?

Что именно вы подразумеваете под "разблокированным"?

Он не имеет торговой марки (можно использовать со случайными SIM-картами) или он постоянно настроен на режим модема?

Джош написал: Что именно вы подразумеваете под «разблокированным»?

Это не простой модем, это маршрутизатор, и большинство маршрутизаторов нельзя переключить в режим последовательного коммутируемого доступа.

Существует альтернативное сообщение о переключении режима USB, которое может работать (или не работать) для большинства устройств Huawei, предоставляя им функцию последовательного набора вместо прямой сетевой функции.

Если это возможно с E-8372, то его Wi-Fi не будет работать. вы готовы потерять Wi-Fi?

LOM пишет: Это не простой модем, это маршрутизатор, и большинство маршрутизаторов нельзя переключить в режим последовательного коммутируемого доступа.

Если это возможно с E-8372, то его Wi-Fi не будет работать. вы готовы потерять Wi-Fi?

Убедитесь, что у вас установлен usb_modeswitch 2.51 или более поздней версии, затем включите HuaweiAltModeGlobal в /etc/usbmodeswitch.conf

LOM пишет: Убедитесь, что у вас установлен usb_modeswitch 2.51 или более поздней версии, затем включите HuaweiAltModeGlobal в /etc/usbmodeswitch.conf

12d1:14db - это идентификатор usb после переключения, дальше переключаться нельзя.
Идентификатор USB перед переключением, вероятно, 12d1:1f01, и это идентификатор, который вы должны использовать в своей команде.

Отключите переключение в файле /etc/usb_modeswitch.conf, повторно подключите устройство и проверьте исходный идентификатор с помощью lsusb.
Затем снова включите переключение и повторите команду, используя правильный идентификатор USB.

LOM писал(а): 12d1:14db это usb id после переключения, дальше переключать нельзя.
Идентификатор USB перед переключением, вероятно, 12d1:1f01, и это идентификатор, который вы должны использовать в своей команде.

Продолжать смысла нет, в одном режиме это устройство имеет сетевой интерфейс cdc_ether, а в другом — сетевой интерфейс rndis. Ни в одном из режимов нет последовательных интерфейсов.

сначала убедитесь, что вы не видите идентификатор USB 12d1:14db.

Отключите usb_modeswitch глобально в "/etc/usb_modeswitch.conf", а также включите там ведение журнала. Следующий подключаемый модуль должен оставить несколько строк в файле журнала в «/var/log», указывающих, что переключение режимов отключено.

Если вы не видите там журнал usb_modeswitch, это означает, что usb_modeswitch никогда не срабатывал, что, в свою очередь, означает, что ваш модем никогда не появлялся в режиме хранения. Причина может заключаться в том, что он был постоянно установлен в режим модема специальной командой или в том, что он никогда не появляется в режиме хранения с самого начала.

Если вы видите журнал usb_modeswitch и он подтверждает, что переключения не было, вы должны увидеть другой идентификатор USB при выполнении команды «lsusb» — возможно, 12d1:1f01, как предполагал LOM.

Теперь вы можете попробовать различные варианты usb_modeswitch. Просто убедитесь, что вы снова подключаете модем после каждой попытки.

Джош написал: рунейбук,

сначала убедитесь, что вы не видите идентификатор USB 12d1:14db.

Спасибо, я смог перейти в предыдущий режим, моя проблема в том, что я пропускал флешку через ПК с Windows на виртуальную машину Linux, и она переключалась до того, как попала в Linux.

У меня USB-модем huawei LTE e3372h в режиме hilink.
Мне удалось подключить его как работающий (онлайн) шлюз.

Если я физически отключу (т.е. удалю из USB-порта) модем при включенном шлюзе, OPNsense выйдет из строя:

Больше не отвечает на запросы ping из локальной сети (ping 192.168.1.254)
Больше не отвечает на ssh
веб-интерфейс больше не доступен
LAN DHCP больше не доступен (например, новое подключение к Wi-Fi с устройства Android не получит никакого IP-адреса)

Для восстановления необходимо повторное включение питания (перезагрузка).

Пока что я не тестировал/не проверял:

Отключение USB при отключенном шлюзе.
Локальный доступ (с экраном или клавиатурой, подключенными к устройству OPNsense) при сбое.

Дайте мне знать, если я могу предоставить дополнительную информацию/тесты.

Версия OPNsense: 19.7 (актуальная), но проблема была и в 19.1.

Текст был успешно обновлен, но возникли следующие ошибки:

bonjour81 прокомментировал 30 ноября 2019 г.

добавлен комментарий hippi-viking 6 января 2020 г.

Вы тот, кто создал подобную тему на форуме OPNSense?
У меня такая же проблема (это я написал последние два ответа).
Я подозреваю, что это может быть проблема перегрузки со сценарием выбора шлюза. В последний раз из-за этого зависал брандмауэр (буквально несколько часов назад) был страннее обычного: примерно через месяц безотказной работы телефон зависал, а брандмауэр рухнул не сразу. Другой (кабельный) восходящий канал вышел из строя после сбоя телефона, повторная отправка DHCP-запроса решила проблему на некоторое время (мне также пришлось перезапустить suricata, чтобы разблокировать кабельный интерфейс). Но брандмауэр по-прежнему дает сбой примерно через 5 минут, так что проблема с перегрузкой все еще существует.

bonjour81 прокомментировал 6 января 2020 г.

Привет!
Да, я такой же. Я обнаружил ваши сообщения на форуме opnsense (извините, я не знаю почему, уведомления на форуме были отключены, поэтому я не знал о ваших комментариях).

Приятно знать, что я не одинок. даже если проблема еще не решена.

И на форуме, и здесь довольно тихо :)

прокомментировал cryptoluks 6 мая 2020 г. •

Недавно я перешел с pfSense на OPNsense и теперь борюсь с той же проблемой.

Использование Huawei 3372 в режиме флешки, который отлично работал с pfSense 2.4.5.

При использовании OPNsense мне нужно было вручную загрузить модуль ядра cdce. Без него ни один интерфейс ue0 не подошел. (Просто поместите if_cdce_load="YES" в свой /boot/loader.conf.local или лучше сохраните его как настраиваемый через веб-интерфейс.)

Теперь вернемся к теме. Тестировал не интенсивно, так как это моя продуктивная система, но похоже паника возникает только при активном мониторинге шлюза. @bonjour81 @hippi-viking можете это подтвердить?

Мне также удалось зафиксировать некоторые следы.

bonjour81 прокомментировал 6 мая 2020 г.

Здравствуйте, я изменил настройки. Вы можете посмотреть здесь.
Я добавил TL-MR3020 между opnsense и e3372, таким образом я подключаю opnsense по RJ45 вместо USB.
Если вы перейдете по ссылке, вы увидите, что другой пользователь сделал это с помощью TL-MR3420.
Итак, насколько я знаю, вопрос все еще открыт, но использование таких устройств является возможным обходным путем.
Это добавит дополнительный уровень NAT, но это может быть не критично, учитывая, что вы не можете открыть порт и получить доступ к своей локальной сети из 4G в большинстве случаев.

прокомментировал криптолюкс 7 мая 2020 г.

Привет, я изменил настройки. Вы можете посмотреть здесь.
Я добавил TL-MR3020 между opnsense и e3372, таким образом я подключаю opnsense по RJ45 вместо USB.
Если вы перейдете по ссылке, вы увидите, что другой пользователь сделал это с помощью TL-MR3420.
Итак, насколько я знаю, вопрос все еще открыт, но использование таких устройств является возможным обходным путем.
Это добавит дополнительный уровень NAT, но это может быть не критично, учитывая, что вы не можете открыть порт и получить доступ к своей локальной сети из 4G в большинстве случаев.

Спасибо за ответ. Хорошо, это кажется хорошим обходным путем. Но я не совсем уверен, работает ли этот маршрутизатор для путешествий из коробки с «режимом флешки» CDC NCM Huawei, поскольку вы сказали, что используете флешку с режимом Hilink.

И на время я просто оставлю мониторинг шлюза отключенным, чтобы предотвратить панику ядра при извлечении флешки. Вроде работает..

Я думаю, что с дампом, может быть, кто-то из сопровождающих может быстро взглянуть на это? @fichtner @AdScellevis, что вы думаете о dump.txt? 😇

добавлен комментарий hippi-viking 13 мая 2020 г. •

Я подтверждаю, что на моих WAN-интерфейсах (включая мобильные устройства) включен мониторинг шлюза. У вас не возникает паники, когда мониторинг шлюза неактивен на конкретном интерфейсе (или на всех ваших интерфейсах)?

Комментарий AdScellevis от 13 мая 2020 г.

прокомментировал криптолюкс 13 мая 2020 г.

Я подтверждаю, что на моих WAN-интерфейсах (включая мобильные) включен мониторинг шлюза. У вас не возникает паники, когда мониторинг шлюза неактивен на конкретном интерфейсе (или на всех ваших интерфейсах)?

Да, у меня отключен мониторинг только для интерфейса WWAN/LTE (мониторинг WAN включен).

Я проверю это позже сегодня.

Я могу засвидетельствовать сбои при загрузке в связи с мониторингом шлюза (icmp), особенно в бета-версии 20.7, чем в 20.1, но это соответствует проблеме и предложенному исправлению. Это действительно было бы неплохо.

прокомментировал криптолюкс 14 мая 2020 г.

Хорошо, мне не удалось воспроизвести вчерашний сбой, даже с включенной "общей переадресацией" и включенным мониторингом шлюза. Это странно. Я не сильно изменился с тех пор, как около недели назад я смог вызвать панику ядра, когда сбои были очень постоянными, когда был включен мониторинг шлюза.

Может быть, мне нужно больше состояний интерфейса WWAN, чем просто мониторинг ICMP, чтобы вызвать панику? Хм.. Я немного не в курсе.

Скоро повторим попытку.

прокомментировал Фихтнер 14 мая 2020 г.

Я думаю, дело в том, что интерфейсы переключаются вверх и вниз либо при загрузке естественным образом, либо во время ненадежных моментов в сети. Если у вас есть какой-либо маршрут политики через интерфейс, который временно отключен, может произойти сбой.

stachi прокомментировал 18 мая 2020 г.

Та же проблема с подключением PPPoE. Если включен мониторинг шлюза и соединение обрывается, возникает паника ядра. При отключенном мониторинге шлюза все работает нормально (кроме Multi WAN, конечно). Я получил эту ошибку с 18.1, и она все еще происходит в 20.1

прокомментировал Фихтнер 18 мая 2020 г.

На этой неделе будет выпущен патч ядра версии 20.1.7. Скрестим пальцы.

Комментарий AdScellevis от 18 мая 2020 г.

Эта проблема была автоматически устранена по тайм-ауту (после 180 дней бездействия).

Если кто-то хочет заняться этой проблемой,
просто сообщите нам об этом, чтобы мы могли повторно открыть проблему и назначить для нее владельца.

Планируется ли полная поддержка модема Huawei E3372 USB LTE в режиме HiLink, включая управление подключением LTE?

Похоже, оригинальные модемы E3372 (прошивка 21.x и ниже) представлялись хосту как последовательные (COM) USB-устройства, через которые хост (ПК или Firebox) запускал соединение PPP или NCM с провайдером.

Я был приятно удивлен, что мой Firebox (прошивка 12.2.1) распознал модем, получил IP4 и позволил мне настроить его как еще один внешний интерфейс с отказоустойчивостью от нашего основного провайдера - multi-wan, link monitor, SD -WAN (ну PBR для меня) и т.д.

Ключ заключается в том, что фактическое состояние соединения LTE теперь управляется исключительно через веб-интерфейс модема — в отличие от «набора» соединения PPP/NCM с исходными «последовательными» модемами — и Firebox понятия не имеет, как это сделать. Я могу вручную открыть веб-интерфейс модема в браузере с ПК в локальной сети и переключать (подключать/отключать) его, но я бы предпочел, чтобы Firebox управлял им автоматически, чтобы свести использование данных LTE к минимуму ($$$).

Ответы

james.carson Модератор, представитель WatchGuard

Спасибо, что написали.

В настоящее время у нас есть запрос на функцию, похожую на ваш модем:

FBX-16458 -- Вариант модема USB LTE Huawei E3372 (VID: 12d1 PID: 1f1e)

Мы можем проверить VID/PID устройства, если оно подключено к Firebox, через файл поддержки, но для этого вам следует открыть запрос, так как его может просмотреть любой желающий на форумах. Если вы можете проверить его самостоятельно и он соответствует VID: 12d1 PID: 1f1e, то в настоящее время над этим работают.

В настоящее время поддержка Firebox для всех модемов заключается в простом открытии соединения в случае аварийного переключения. Любое регулирование/ограничение соединения в определенный момент должно быть согласовано с вашим оператором связи или настроено на модеме перед подключением к брандмауэру.

-Джеймс Карсон
Служба поддержки клиентов WatchGuard

Еще раз спасибо,
Пол

james.carson Модератор, представитель WatchGuard

Я попрошу, чтобы служба поддержки подтолкнула вас к этому. Похоже, они передали это дело команде, которая уже может вам помочь.

-Джеймс Карсон
Служба поддержки клиентов WatchGuard

Спасибо, что ответили, вопрос действительно был "эскалирован", но похоже, что у каждого специалиста службы поддержки Watchguard (на данный момент их 3) есть проблемы с пониманием прочитанного.

Вы не могли бы связать меня с людьми, занимающимися планированием продуктов Watchguard, ответственными за набор функций поддержки USB-модема?

Я только что опубликовал новую дискуссию по этому поводу, а потом нашел эту. 100% согласен с этим обсуждением. Необходимо пересмотреть программное обеспечение 4G.

Неловко поставлять новый брандмауэр, а затем устанавливать дополнительные устройства (Netgear LB2120, Nighthawks или Netcomms/Dlinks) для запуска опции 4G из-за программных ограничений. Это также увеличивает вероятность сбоя из-за того, что что-то отключено.

james.carson Модератор, представитель WatchGuard

Привет, @DaveDave
Из-за различных рынков и нормативных требований WatchGuard не может предложить сотовый модем с болтовым креплением для топки. Лучший подход, который мы нашли до сих пор, — поддерживать устройства, доступные на каждом рынке, насколько это возможно.

Если у вас есть устройство, которое еще не поддерживается, мы будем рады рассмотреть возможность его поддержки в будущем.

Читайте также: