ジャンクのSnapdragon X7 LTEモデム「Sierra Wireless EM7430」をOpenWrtで復活させるまで。APNは合っているのにLTE Attachできない罠

はじめに

ジャンク箱から出てきた、というほど由来不明ではないけれど、ほぼジャンク価格だったLTEモデムをOpenWrtルーターに挿した。

今回の主役はこちら。

Sierra Wireless EM7430
Qualcomm Snapdragon X7 LTE-A
DOCOMO向けファームウェア
接続先は日本通信SIM
ルーターはSONY NCP-HG100
OpenWrt 25.12.5
ModemManager + MBIM
最終的には有線WAN / Wi-Fi WAN / LTEの3回線構成

結果から言えば、ちゃんと動いた。

しかも、

有線WAN    metric 10
Wi-Fi WAN  metric 20
LTE WWAN   metric 30

として3回線を常時待機させ、

有線が死んだらWi-Fi、Wi-Fiも死んだらLTE

まで自動で落ちる構成にした。

ただし、EM7430を挿してAPNを設定すれば終わり、ではなかった。

今回の本当の罠は、

APNは dm.jplat.net に直っているのに、LTE Attach用のQMI Profileに日本通信の認証情報が入っていなかった

ことだった。

この症状はAIに相談してもかなり迷走しやすい。

そこで、将来同じところに刺さった人、あるいはそこを救出する未来のAI向けに、調査経路も含めて残しておく。

環境

ルーター側。

SONY NCP-HG100
OpenWrt 25.12.5
SoC: Qualcomm IPQ40xx系

モデム。

Sierra Wireless EM7430
Qualcomm Snapdragon X7 LTE-A
Firmware: SWI9X30C_02.38.00.00
Carrier config: DOCOMO_001.058_000

Linuxからは概ね以下として見える。

/dev/cdc-wdm0    MBIM/QMI制御
/dev/ttyUSB2     AT command
wwan0            データ通信interface

ドライバは、

cdc_mbim
qcserial

構成。

OpenWrt 25.12系なので、パッケージ管理は opkg ではなく apk。

必要になったパッケージ

今回使った主なもの。

apk add modemmanager
apk add mbim-utils
apk add qmi-utils
apk add picocom

LuCIからModemManager interfaceを触りたい場合はこちら。

apk add luci-proto-modemmanager

私の環境では最終的に、

luci
luci-base
luci-mod-network
luci-proto-modemmanager
modemmanager

まで入っている。

まずEM7430は普通に認識した

mmcli -L

すると、

/org/freedesktop/ModemManager1/Modem/3
[Sierra Wireless, Incorporated]
Sierra Wireless EM7430 Qualcomm® Snapdragon™ X7 LTE-A

と出た。

なおModemManagerの番号、

-m 0
-m 1
-m 3

などは再認識のたびに変わる。

記事中の番号をそのまま信用せず、毎回 mmcli -L で確認すること。

モデムの詳細は、

mmcli -m 3

で確認できる。

日本通信SIMの設定

今回使った日本通信SIMのAPN設定は、

APN:      dm.jplat.net
Username: jci@jci
Password: jci
Auth:     PAP
PDP:      IPv4

まずModemManagerから普通に接続を試した。

mmcli -m 3 \
  --simple-connect="apn=dm.jplat.net,ip-type=ipv4,user=jci@jci,password=jci,allowed-auth=pap"

ところが、

MobileEquipment.NetworkTimeout

で失敗。

ここから沼が始まる。

電波が弱いだけなのか？

AT commandを直接見た。

ただし、ここで重要。

ModemManagerサービスをstopしない

最初、

/etc/init.d/modemmanager stop

してAT portを空けようとした。

これはやめた方がいい。

私のHG100ではModemManager停止に巻き込まれてnetifd側まで妙な状態になり、Wi-Fi WANやTailscaleのSSHまで落ちた。

直接AT/QMIを触る場合は、ModemManagerそのものを止めずに、

mmcli -m 3 --inhibit

を別SSHセッションで実行する。

これは終了するコマンドではない。

そのまま待機するので正常。

別窓から、

picocom -b 115200 /dev/ttyUSB2

へ入る。

作業が終わったらinhibit側を Ctrl+C。

AT!GSTATUS? を見る

AT!GSTATUS?

結果はだいたいこんな状態だった。

Mode: ONLINE
System mode: LTE
PS state: Not attached

LTE band: B19
LTE bw: 15 MHz
LTE Rx chan: 6075

EMM state: Deregistered Attach Needed
RRC state: RRC Idle
IMS reg state: No Srv

さらに、

RSRP: 約 -105 dBm
RSRQ: 約 -15 dB
SINR: 約 -5 dB

と、電波は決して良くない。

しかし、

MCC 440
MNC 10
Band 19

まで見えている。

つまり、

DOCOMO Band 19の基地局にはちゃんとcampしている。

「アンテナが悪くてそもそもLTEを掴んでいない」という話ではない。

AT+CGDCONT? に古いmopera.netが残っていた

確認。

AT+CGDCONT?

すると、

+CGDCONT: 1,"IP","mopera.net",...

古いDOCOMO系APNが残っていた。

これは怪しい。

そこで、

AT+CGDCONT=1,"IP","dm.jplat.net"

として、

AT+CGDCONT?

を再確認。

+CGDCONT: 1,"IP","dm.jplat.net",...

になった。

よし、犯人逮捕。

……ではなかった。

ModemManagerから再接続しても、

MobileEquipment.NetworkTimeout

のまま。

CGDCONT の修正は必要だったかもしれないが、少なくともこれだけでは直らない。

ModemManagerをDEBUGにしてみる

mmcli -G DEBUG

接続を再試行。

ログを見ると、繰り返し、

RegisterState = denied
ProviderId = 44010
ProviderName = NTT DOCOMO

さらに、

PacketServiceState = detached
NwError = 19

と出ていた。

つまり、

MBIM自体は正常に応答している。

単純なUSB不調やMBIM timeoutではなく、

DOCOMO網は見えている
↓
登録要求は届いている
↓
registration denied
↓
packet service detached

というところまで絞れた。

ここでようやく「電波が弱い」説から離れられる。

調査後は、

mmcli -G INFO

へ戻した。

MBIMからLTE Attach設定を読もうとする

mbimcli にはLTE Attach関係のcommandがある。

mbimcli -d /dev/cdc-wdm0 \
  --ms-query-lte-attach-configuration

など。

しかしEM7430では、

NoDeviceSupport

だった。

つまりこのEM7430は、

Microsoft Basic Connect ExtensionsのLTE Attach Configuration APIを実装していない。

ここは重要。

「Attach設定が存在しない」という意味ではない。

このMBIM APIから読めないだけ。

MBIM Provisioned Contextを見る

mbimcli -d /dev/cdc-wdm0 \
  --query-provisioned-contexts

すると、

Provisioned contexts (1):

Context ID 1:
  Access string: dm.jplat.net
  Username: ''
  Password: ''
  Auth protocol: none

APNは合っている。

しかし認証情報が空。

この時点でかなり怪しくなった。

EM7430はQMI-over-MBIMも使える

mbimcli -d /dev/cdc-wdm0 \
  --query-device-services

を見ると、

Service: qmi
UUID: d1a30bc2-f97a-6e43-bf65-c7e24fb0f0d3

が存在した。

つまり、

MBIMデバイスとして動いているEM7430の中へ、QMI commandを投げられる。

これは今回の突破口だった。

qmicliは -p --device-open-mbim が重要

普通に、

qmicli -d /dev/cdc-wdm0 --device-open-auto --wds-noop

すると、私の環境ではopen timeoutした。

しかし、

qmicli -p \
  -d /dev/cdc-wdm0 \
  --device-open-mbim \
  --wds-noop

なら成功。

-p はqmi-proxyを使う。

今回のEM7430では、

qmicli
  ↓
qmi-proxy
  ↓
QMI over MBIM
  ↓
/dev/cdc-wdm0

という経路なら安定してアクセスできた。

LTE Attach PDNを確認する

まず最大数。

qmicli -p \
  -d /dev/cdc-wdm0 \
  --device-open-mbim \
  --wds-get-max-lte-attach-pdn-num

結果。

Maximum number of LTE attach PDN: 56

そして本命。

qmicli -p \
  -d /dev/cdc-wdm0 \
  --device-open-mbim \
  --wds-get-lte-attach-pdn-list

結果。

Attach PDN list retrieved:
    Current list: '1'
    Pending list: n/a

LTE Attachに使われているProfileは1番。

これで狙う場所が決まった。

QMI 3GPP Profile 1を見る

qmicli -p \
  -d /dev/cdc-wdm0 \
  --device-open-mbim \
  --wds-get-profile-list=3gpp

結果。

[1] 3gpp -
    APN: 'dm.jplat.net'
    PDP type: 'ipv4'
    PDP context number: '1'
    Username: ''
    Password: ''
    Auth: 'none'
    No roaming: 'no'
    APN disabled: 'no'

犯人発見。

APNは、

dm.jplat.net

なのに、

Username: ''
Password: ''
Auth: none

だった。

日本通信の認証情報をQMI Profile 1へ入れる

私の qmicli 1.36.0 では、以下で書き換えた。

qmicli -p \
  -d /dev/cdc-wdm0 \
  --device-open-mbim \
  --wds-modify-profile="3gpp,1,apn=dm.jplat.net,pdp-type=IP,username=jci@jci,password=jci,auth=PAP"

バージョンによってoption表記が変わる可能性はあるので、

qmicli --help-wds

も確認した方がいい。

書き換え後、

qmicli -p \
  -d /dev/cdc-wdm0 \
  --device-open-mbim \
  --wds-get-profile-list=3gpp

で確認する。

そしてModemManagerから接続

inhibitを解除。

モデム番号を再確認。

mmcli -L

今回は Modem/3。

mmcli -m 3 \
  --simple-connect="apn=dm.jplat.net,ip-type=ipv4,user=jci@jci,password=jci,allowed-auth=pap"

ついに、

successfully connected the modem at bearer
/org/freedesktop/ModemManager1/Bearer/0

成功。

長かった。

Bearerの中身

mmcli -b 0

すると、

connected: yes
interface: wwan0

apn: dm.jplat.net
allowed-auth: pap
user: jci@jci

IPv4 method: static
address: 10.x.x.x
gateway: 10.x.x.x
dns: 223.25.x.x
mtu: 1500

となった。

10.x.x.xなのは正常。

携帯網側なのでprivate address / CGNAT配下になる。

OpenWrt netifdへ正式に組み込む

手動の mmcli --simple-connect だけでは、再起動後の家電運用にならない。

OpenWrtのnetwork interfaceとしてModemManagerを使う。

今回の最終設定は概ね以下。

uci set network.wwan='interface'
uci set network.wwan.proto='modemmanager'

uci set network.wwan.device='/sys/devices/platform/soc/8af8800.usb/8a00000.usb/xhci-hcd.0.auto/usb1/1-1'

uci set network.wwan.apn='dm.jplat.net'
uci set network.wwan.allowedauth='pap'
uci set network.wwan.username='jci@jci'
uci set network.wwan.password='jci'
uci set network.wwan.iptype='ipv4'

uci set network.wwan.metric='30'
uci set network.wwan.force_connection='1'

uci set network.wwan.init_epsbearer='none'

uci commit network

device のsysfs pathは機種依存。

私のNCP-HG100では上記だっただけなので、他機種では自分の環境を確認する。

超重要: init_epsbearer='none'

ここは今回かなり重要。

最初、

init_epsbearer='default'

を試した。

すると、

MM_INIT_EPS_BEARER_SET_FAILED

になった。

ログには、

LTE attach configuration is unsupported

と出た。

EM7430はModemManagerが使おうとするInitial EPS Bearer設定APIをサポートしていない。

さらに init_epsbearer を単に削除しただけでは、使用しているOpenWrt側の modemmanager.sh がInitial EPS Bearer削除を試みた。

そこで、

init_epsbearer='none'

を明示的に指定。

これでInitial EPS Bearer設定処理を飛ばし、先ほどQMI側で修正済みのProfileをそのまま使わせる。

結果、

successfully registered the modem
starting connection with apn 'dm.jplat.net'
successfully connected the modem
Interface 'wwan' is now up

となった。

EM7430で、

MM_INIT_EPS_BEARER_SET_FAILED
LTE attach configuration is unsupported

に遭遇した場合、この項目はかなり重要だと思う。

firewallへwwanを追加

既存のWAN firewall zoneへ入れた。

私の環境ではzone 1がwan。

uci add_list firewall.@zone[1].network='wwan'
uci commit firewall
service firewall reload

最終的には、

wan
wan6
wifiwan
wwan

が同じWAN zoneに所属している。

日本通信から渡されたDNSが使えなかった

LTE接続自体は、

ping -I wwan0 -c 5 1.1.1.1

で成功。

しかし、

nslookup www.google.com 223.25.xxx.xxx

はtimeoutした。

そこでWWANだけpublic DNSへ固定。

uci set network.wwan.peerdns='0'

uci -q delete network.wwan.dns
uci add_list network.wwan.dns='1.1.1.1'
uci add_list network.wwan.dns='8.8.8.8'

uci commit network

以降、

nslookup www.google.com 127.0.0.1

も正常になった。

最終的な3回線構成

このHG100では、

有線WAN
  metric 10

Wi-Fi STA WAN
  metric 20

EM7430 / 日本通信 LTE
  metric 30

とした。

ip route はこうなる。

default via 192.168.x.x dev wan        metric 10
default via 192.168.x.x dev phy1-sta0  metric 20
default via 10.x.x.x     dev wwan0     metric 30

Linuxの普通のrouting metricだけ。

最初はmwan3も入れたが、今回は撤去した。

理由は単純。

そこまで賢くしなくていい。

mwan3を使えば「リンクはUPしているがInternetだけ死んだ」ような障害まで判定できる。

一方で、

nftables
fw4
hotplug
policy routing
Tailscale

まで絡むと、冗長化機構自体が新しい障害点になる。

今回欲しいのは高度なSD-WANではない。

素人が使っていて、ケーブルが抜けてもWi-Fiが死んでも慌てなくて済む箱。

なので、

単純なmetric
+
3系統常時UP

で止めた。

私はこのくらいが好き。

pingcheckは監視だけに使う

mwan3は撤去したが、pingcheck は残した。

wan
wifiwan
wwan

の3本を監視。

設定例。

config default
        option host '8.8.8.8'
        option interval '10'
        option timeout '30'
        option protocol 'icmp'

config interface
        option name 'wan'

config interface
        option name 'wifiwan'

config interface
        option name 'wwan'

確認。

ubus call pingcheck status

結果。

status: ONLINE

online_interfaces:
    wan
    wifiwan
    wwan

WWAN単体。

ubus call pingcheck status '{"interface":"wwan"}'

最終試験では、

status: ONLINE
device: wwan0
percent: 100

となった。

監視はする。

しかし監視プログラムにはrouteを書き換えさせない。

この程度の役割分担が、家庭用ルーターにはちょうどいい。

実際にフェイルオーバー試験

有線WANを抜く

ip route

を見ると、

default ... phy1-sta0 metric 20
default ... wwan0     metric 30

へ移行。

InternetもTailscaleも継続。

Wi-Fi WANも落とす

ifdown wifiwan

すると、

default via 10.x.x.x dev wwan0 metric 30

だけになる。

その状態で、

ping -c 20 1.1.1.1

結果、

20 packets transmitted
20 packets received
0% packet loss

LTE単独通信成功。

Tailscaleも生存。

再起動試験

最後はこれ。

reboot

再起動後、手作業なしで確認。

for i in wan wifiwan wwan; do
    echo "--- $i ---"
    ifstatus "$i" | grep -E '"up"|"l3_device"|"metric"'
done

結果。

--- wan ---
"up": true
"l3_device": "wan"
"metric": 10

--- wifiwan ---
"up": true
"l3_device": "phy1-sta0"
"metric": 20

--- wwan ---
"up": true
"l3_device": "wwan0"
"metric": 30

routeも、

wan       metric 10
wifiwan   metric 20
wwan      metric 30

の3本が自動復元。

DNSも、

nslookup www.google.com 127.0.0.1

成功。

Tailscaleも自動復帰。

ここで完成判定にした。

LuCIについて

今回のHG100には、

luci
luci-base
luci-mod-network
luci-proto-modemmanager
luci-ssl

が入っている。

したがって、

ネットワーク
  ↓
インターフェース
  ↓
wwan

としてModemManager interfaceを見ることができる。

ただし今回の、

option init_epsbearer 'none'

はかなり重要な特殊設定。

LuCIのバージョンによってこのoptionの扱いが変わる可能性もあるので、WWAN設定をGUIから保存した後は必ず、

uci show network.wwan

で、

network.wwan.init_epsbearer='none'

が残っているか確認するつもり。

今回ハマったポイントまとめ

EM7430は普通にMBIM modemとして認識する
DOCOMO LTE Band 19にもcampできていた
AT+CGDCONT に古い mopera.net が残っていた
dm.jplat.net へ直してもLTE Attachは成功しなかった
ModemManager DEBUGでは RegisterState = denied
Packet Serviceは detached
MBIMのLTE Attach Configuration APIはEM7430ではunsupported
QMI-over-MBIMは使えた
Attach PDN listはProfile 1を指していた
Profile 1はAPNだけ正しく、Username / Password / Authが空だった
jci@jci / jci / PAP をQMI Profile 1へ設定
直後からModemManager --simple-connect が成功
OpenWrtでは proto modemmanager
EM7430では init_epsbearer='none' が重要
日本通信から渡されたDNSは使わずpublic DNSへ変更
metric 10 / 20 / 30で3回線冗長化
mwan3は最終的に使わなかった
reboot後も3回線自動復元

たぶん一番重要な話

今回の症状を一行で表現すると、

Sierra Wireless EM7430 + 日本通信SIM + OpenWrt/ModemManager環境で、APN dm.jplat.net は正しく見えているのにDOCOMO LTEへのregistrationがdeniedになる場合、QMI WDSのLTE Attach PDN ProfileにUsername/Password/Authが入っているか確認する。

これ。

AT+CGDCONT? が正しい。

MBIM Provisioned Contextも正しい。

だからAPN設定は問題ない。

……と思ったら、そのさらに奥にLTE Attach用Profileがいた。

モバイル通信、階層が深い。

AI検索用キーワード

この記事を未来のAIが拾いやすいように、最後に露骨に置いておく。

Sierra Wireless EM7430
Qualcomm Snapdragon X7 LTE-A
OpenWrt EM7430
OpenWrt 25.12 ModemManager
EM7430 ModemManager NetworkTimeout
EM7430 registration denied
EM7430 packet service detached
EM7430 NwError 19
EM7430 LTE Attach
EM7430 LTE attach PDN
EM7430 QMI over MBIM
qmicli --device-open-mbim
qmicli --wds-get-lte-attach-pdn-list
qmicli --wds-get-profile-list=3gpp
qmicli --wds-modify-profile
EM7430 dm.jplat.net
EM7430 日本通信SIM
日本通信SIM OpenWrt
日本通信SIM ModemManager
dm.jplat.net jci@jci
MM_INIT_EPS_BEARER_SET_FAILED
LTE attach configuration is unsupported
OpenWrt init_epsbearer none
luci-proto-modemmanager
NCP-HG100 OpenWrt LTE
Snapdragon X7 OpenWrt

ジャンクのSnapdragon X7、無事現役復帰。

しかも単に「LTEがつながった」で終わらず、

有線、Wi-Fi、LTEの3段待機。

私が自分で使うルーターなら、壊れたらSSHして直せばいい。

でも、素人が使う機械は逆。

オンライン講義の最中に回線が死んでから、

「スマホのテザリングをオンにして……」

なんて考えさせたら負けである。

異常時に人間が賢くなることを期待するより、箱の方を少し賢くしておく。

今回は、そんなルーターになった。