ジャンクの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して直せばいい。
でも、素人が使う機械は逆。
オンライン講義の最中に回線が死んでから、
「スマホのテザリングをオンにして……」
なんて考えさせたら負けである。
異常時に人間が賢くなることを期待するより、箱の方を少し賢くしておく。
今回は、そんなルーターになった。