y.nakamura
2018年3月4日 14時27分
中村です。
LTEのifは通常はusb1ですが、これがusb0になることがあります。
最後に質問を書いています。
少し長くなりますが、状況などでわかっていることを全部書いておきます。
# ifconfig
...
usb0 Link encap:Ethernet HWaddr 02:80:79:XX:XX:XX
inet addr:192.168.15.208 Bcast:192.168.15.255 Mask:255.255.255.0
inet6 addr: fe80::80:79ff:fe97:8540/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:193 errors:0 dropped:0 overruns:0 frame:0
TX packets:295 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:15960 (15.5 KiB) TX bytes:33318 (32.5 KiB)
usb1 Link encap:Ethernet HWaddr ae:c1:44:XX:XX:XX
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
...
# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.15.1 0.0.0.0 UG 0 0 0 usb0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 usb0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.15.0 0.0.0.0 255.255.255.0 U 0 0 0 usb0質問内容は異なりますがusb1とusb0の話が出てくる記事が
過去に１つありました。
https://armadillo.atmark-techno.com/forum/armadillo/2841
if名がusb0になってしまうと、syslogに
connection-recover: ttyACM0: In the route setting, the destination host can not be reached
というログが繰り返し残ります。
systemctl -l status connection-recover.service でも
同じログが表示されます。
再接続サービスのスクリプトと設定ファイルを見ると...
設定ファイル
/etc/connection-recover/gsm-ttyACM0_connection-recover.conf
PRODUCT_NAME=Armadillo-X1L PING_DEST_IP=8.8.8.8 DEVICE=ttyACM0 TYPE=gsm NETWORK_IF=usb1 FORCE_REBOOT=FALSE
スクリプトの関係しそうな部分
/usr/bin/connection-recoverd
...
check_route() {
ip route get ${PING_DEST_IP} | grep ${NETWORK_IF} > /dev/null 2>&1
}
is_connect() {
if ! check_route; then
logger -t connection-recover "$DEVICE: In the route setting, the destination host can not be reached"
return 0
fi
ping -s 1 -c ${PING_COUNT} -w 10 -I ${NETWORK_IF} ${PING_DEST_IP} > /dev/null 2>&1
if [ $? -eq 0 ]; then
return 0
else
logger -t connection-recover "$DEVICE ping fail"
fi
return 1
}
...
*connected*)
is_connect
PING_STATUS=$?
if [ $PING_STATUS -ne 0 ]; then
reconnect
fi ;;
...となっています。
check_route()と同じことを手動でやってみると
# ip route get 8.8.8.8
8.8.8.8 via 192.168.15.1 dev usb0 src 192.168.15.208
cacheとなりますのでcheck_route()は失敗し、その結果、
is_connect()がsyslogに
... destination host can not be reached
を残し、再接続サービスは機能しないことになります。
(is_connect()のそのあとのpingを打つこともなく...です)
質問です。
[1] 再接続サービスの設定ファイルでif名をusb1に決め打ちする根拠は何ですか？
[2] 通常はusb1で、たまに(頻度はそんなに低くはない)usb0になる理由は何ですか？
[3] "gsm-ttyACM0"から"usb0"か"usb1"を求めるいい方法はありますか？
[1]と[2]は同じことを質問していることになるかもしれません。
[3]は設定ファイルで"usb1"と決め打ちしないようにするにはどうしたらいいか？です。
よろしくお願いいたします。
--
なかむら
コメント
y.nakamura
中村です。
古関さん、ご対応いただき、ありがとうございます。
> 特に、先日モジュールメーカーよりリリースされましたファームウェアrev30063を使用した状態で
> システムを再起動したときに起きやすいようです。
そんな感じですね。
パワーOFF状態からの起動でなく、rebootしたときに起きるようです。
> （上記ファームウェア以外でもタイミングによって再現する可能性はあるが、弊社では再現できていない）
私の環境では、ファームウェア入れ替え前も何度か発生していました。
> 対策として、添付のudevルールを/lib/udev/rules.d に配置し、
> LTEモジュールのインターフェース名をusb1に固定してください。
この方法でusb1に固定する方法を試してみました。
結果はＮＧなようです。
usb0になってしまうことがあります。
また、usb0になったとき、今まではなかったrename11というのができてます。
このときはusb1は存在しません。
# ifconfig
...
rename11 Link encap:Ethernet HWaddr 26:62:0d:XX:XX:XX
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
usb0 Link encap:Ethernet HWaddr 02:80:79:XX:XX:XX
inet addr:192.168.15.208 Bcast:192.168.15.255 Mask:255.255.255.0
inet6 addr: fe80::80:79ff:fe97:8540/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:185 errors:0 dropped:0 overruns:0 frame:0
TX packets:289 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:17083 (16.6 KiB) TX bytes:33376 (32.5 KiB)
...
# nmcli d
DEVICE TYPE STATE CONNECTION
eth0 ethernet connected ethernet-eth0
ttyACM0 gsm connected gsm-ttyACM0
rename11 ethernet connecting (getting IP configuration) Wired connection 2
wlan0 wifi disconnected --
...--
なかむら
at_koseki
中村様
古関です。
動作検証のご協力ありがとうございます。
こちらで色々タイミングを変えながら一晩連続試験をしているのですが、
再現できてない状況です。
rename11になるのは、にrenameしようとした名前が既に使用されていた場合の挙動ですね。。
LTEモジュールのインターフェース名変更のほうのudevルールが正しく動作していないように見えます。
お手数をお掛けして申し訳ありませんが、問題が再現した時に
以下のコマンドを実行して結果をいただけますでしょうか？
udevadm info --attribute-walk --path=/sys/class/net/rename11
udevadm info --attribute-walk --path=/sys/class/net/usb0
あと、問題再現時の起動ログかdmesgをいただけると助かります。
y.nakamura
中村です。
もしかして・・・カーネルのコンフィグレーションで
USB-LAN アダプタのASIX(AX88xxxとAX88179/178A)を有効にしてますが、
これが関係してますか？
ASIXドライバを有効にしていますが、今はUSB-LAN アダプタはつないでません。
USBには関係しないと思いますが、CIFSドライバも有効にしてます。
使用しているカーネルはat19、ブートローダはat12です。
ルートファイルシステムのdebianは、
debian-jessie-armhf_aiotg3l_20171026.tar.gzで、
SDブートです。
もしこのあたりが関係していそうならば、
環境構築で少し時間がかかりますが、
何も手を入れていない最新の
カーネルat20、ブートローダat13、debianは20180131
で試してみようかと思います。
eMMCはの書き換えは開発作業の都合でできませんので、
SDブートになります。
> udevadm info --attribute-walk --path=/sys/class/net/rename11
> udevadm info --attribute-walk --path=/sys/class/net/usb0
> あと、問題再現時の起動ログかdmesgをいただけると助かります。
添付します。
よろしくお願いします。
--
なかむら
| ファイル | ファイルの説明 |
|---|---|
| udevadm実行結果.txt | |
| dmsg実行結果.txt |
y.nakamura
y.nakamura
中村です。
70-x1-network.rulesの中の６行目("Armadillo-X1L Board"の方)の
KERNELS=="1-1:1.0"
を
KERNELS=="2-1:1.0"
に変更したところ、usb1に固定できたようです。
とりあえず私が使っている機体ではこれでＯＫになりましたが、
古関さんの環境では"1-1:1.0"でうまく動くとなると、
この違いの原因は何なのか？が問題になってくると思います。
# 6日にリリースされたアップデート
# https://armadillo.atmark-techno.com/news/20180306/software-update-aiotg…
# の atmark-x1-base (v1.5.3-1) にこの修正(私のところで動かなかったやつ)が
# 入ってしまってますよね？
# ついでに・・・
# このnewsページの次の２つのリンクが間違ってませんか？ (G3のページもです)
# ・インストールディスクイメージ install_disk_sd_20180305_x1.img
# ・DTB (Device Tree Blob) armadillo_x1-v21.00.dtb
--
なかむら
y.nakamura
中村です。
古関さん、
> 70-x1-network.rulesの中の６行目("Armadillo-X1L Board"の方)の
> KERNELS=="1-1:1.0"
> を
> KERNELS=="2-1:1.0"
> に変更したところ、usb1に固定できたようです。
>
> とりあえず私が使っている機体ではこれでＯＫになりましたが、
> 古関さんの環境では"1-1:1.0"でうまく動くとなると、
> この違いの原因は何なのか？が問題になってくると思います。
この原因は何でしょうか？
> # 6日にリリースされたアップデート
> # https://armadillo.atmark-techno.com/news/20180306/software-update-aiotg…
> # の atmark-x1-base (v1.5.3-1) にこの修正(私のところで動かなかったやつ)が
> # 入ってしまってますよね？
なので、原因次第では、今開発作業中のもので
6日リリースのものを使うことにしたときに
この部分を修正する必要がでてきますので。
"1-1"と"2-1"の違いは、CPUに２つあるUSBの
USB_OTG1とUSB_OTG2の違いかな？と
今まで思っていたのですが、違うのでしょうか？
--
なかむら
at_koseki
中村さま
古関です。
> 70-x1-network.rulesの中の６行目("Armadillo-X1L Board"の方)の
> KERNELS=="1-1:1.0"
> を
> KERNELS=="2-1:1.0"
> に変更したところ、usb1に固定できたようです。
お待たせしました。
この部分が違う原因が分かりました。
G3Lの複数ある製品バリエーションでカーネルが認識するこの番号が変わってしまうようです。
（※私がテストした環境はUSBコネクタの部分がUSBホストでは無くUSBデバイスタイプのモノ）
udevのルールが適切ではありませんでした。
ご迷惑をお掛けし、申し訳ありません。
対策としては、KERNELS=="1-1:1.0"の部分を削除したいと思います。
※ ファイル添付致します。
※ 使用している製品の型番を変更しないのであれば、KERNELS=="2-1:1.0"でも構いません。
早急にdebianパッケージ(atmark-x1-base)を更新致します。
KERNELS=="1-1:1.0"を削除することによる副作用として、
ELS31-Jを２つ接続した場合にudevルールが正しく動作しなくなります。
ただ、このケースはまずありえないので、ケアしないことにします。
| ファイル | ファイルの説明 |
|---|---|
| 70-x1-network.rules_.txt |
y.nakamura
中村です。
古関さん、
回答、ありがとうございます。
> 対策としては、KERNELS=="1-1:1.0"の部分を削除したいと思います。
> ※ ファイル添付致します。
udevルールファイルを入れ替えて、動作確認できました。
今回の問題はこれで解決となりますが、
今後、他のUSB関連で影響がでてくるかもしれませんので、
次の点について教えてください。
> G3Lの複数ある製品バリエーションでカーネルが認識するこの番号が変わってしまうようです。
> （※私がテストした環境はUSBコネクタの部分がUSBホストでは無くUSBデバイスタイプのモノ）
「複数ある製品バリエーションで」とのことですが、
この違いは具体的にはどのようなものでしょうか？
G3Lの変更通知
https://users.atmark-techno.com/change_notification/armadillo-iot-g3l
には、該当するものは存在しないようです。
アットマークテクノ社内の特定のハードウェアだけ、とか、
ES版と量産版の違いとか、そういったことでしょうか？
--
なかむら
at_koseki
古関です。
> 「複数ある製品バリエーションで」とのことですが、
> この違いは具体的にはどのようなものでしょうか？
> G3Lの変更通知
> https://users.atmark-techno.com/change_notification/armadillo-iot-g3l
> には、該当するものは存在しないようです。
>
> アットマークテクノ社内の特定のハードウェアだけ、とか、
> ES版と量産版の違いとか、そういったことでしょうか？
はい。弊社にある試験用の試作品や特定のお客様専用の製品バリエーションでして、
一般のお客様向けに公開していないハードウェア構成のものです。
udevのルールを更新したatmark-x1-base(v1.5.4)を公開しました。
別途リリース案内を出す予定ですが、現時点でも
apt-get update
apt-get install atmark-x1-base
でアップデート可能です。
よろしくお願い致します。
y.nakamura
中村です。
古関さん、
> はい。弊社にある試験用の試作品や特定のお客様専用の製品バリエーションでして、
> 一般のお客様向けに公開していないハードウェア構成のものです。
ご回答いただき、ありがとうございます。
> udevのルールを更新したatmark-x1-base(v1.5.4)を公開しました。
> 別途リリース案内を出す予定ですが、現時点でも
> apt-get update
> apt-get install atmark-x1-base
迅速な対応、どうもありがとうございます。
本件、これにてクローズとしたいと思います。
--
なかむら
at_koseki
2018年3月5日 14時18分
古関です。
ご報告ありがとうございます。
> [2]通常はusb1で、たまに(頻度はそんなに低くはない)usb0になる理由は何ですか？
LTEモジュールが認識されるタイミングによって発生する場合があります。
特に、先日モジュールメーカーよりリリースされましたファームウェアrev30063を使用した状態で
システムを再起動したときに起きやすいようです。
（上記ファームウェア以外でもタイミングによって再現する可能性はあるが、弊社では再現できていない）
対策として、添付のudevルールを/lib/udev/rules.d に配置し、
LTEモジュールのインターフェース名をusb1に固定してください。
※ フォーラムのシステム都合上、拡張子".rules"が添付できないのでtextで添付します。適宜リネームを願い致します。
近日中に製品アップデートにてdebianパッケージ atmark-x1-baseに入れる形で配布する予定です。
ご迷惑をお掛けしますが、よろしくおねがいします。
> [1]再接続サービスの設定ファイルでif名をusb1に決め打ちする根拠は何ですか？
> [3]"gsm-ttyACM0"から"usb0"か"usb1"を求めるいい方法はありますか？
gsm-ttyACM0から、紐付いたネットワークデバイス名"usb0" or "usb1"を引いてくる理想的な方法がなく[※]、
再接続サービスでは、インターフェース名を設定ファイルに固定で入れる "あまり良くない実装" になっております。
[※]
いくつか考えてみたのですが、スマートではないです。。
あるべき論では(1)でやるのが良いと考えています。
(1) nmcli、mmcliから取得
# nmcli connection show gsm-ttyACM0 |grep "connection.interface-name"
connection.interface-name: ttyACM0
# root@armadillo:~# mmcli -m 0|grep ports
| ports: 'ttyACM0 (at), usb1 (net)'
※ usb1がLTEモジュールのネットワークインターフェース名
(2) udevadmコマンドでLTEモジュールのvendorID/ProductIDを見て判別
* 以下の実行結果がどちらも真だった場合はusb1はLTEモジュール
※ 1e2d:00a0はLTEモジュールELS31-JのUSB vendorID/ProductID
udevadm info --attribute-walk --path=/sys/class/net/usb1 | grep 'ATTRS{idVendor}=="1e2d"'
udevadm info --attribute-walk --path=/sys/class/net/usb1 | grep 'ATTRS{idProduct}=="00a0"'