Armadilloフォーラム

G3LのLTEのif名がusb0になったとき再接続サービスが機能しない

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の話が出てくる記事が
過去に1つありました。
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"と決め打ちしないようにするにはどうしたらいいか?です。

よろしくお願いいたします。

--
なかむら

コメント

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"'

ファイル ファイルの説明
70-x1-network.rules_.txt

y.nakamura

2018年3月5日 18時26分

中村です。

古関さん、ご対応いただき、ありがとうございます。

> 特に、先日モジュールメーカーよりリリースされましたファームウェアrev30063を使用した状態で
> システムを再起動したときに起きやすいようです。

そんな感じですね。
パワーOFF状態からの起動でなく、rebootしたときに起きるようです。

> (上記ファームウェア以外でもタイミングによって再現する可能性はあるが、弊社では再現できていない)

私の環境では、ファームウェア入れ替え前も何度か発生していました。

> 対策として、添付のudevルールを/lib/udev/rules.d に配置し、
> LTEモジュールのインターフェース名をusb1に固定してください。

この方法でusb1に固定する方法を試してみました。
結果はNGなようです。
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

2018年3月6日 12時51分

中村様

古関です。

動作検証のご協力ありがとうございます。
こちらで色々タイミングを変えながら一晩連続試験をしているのですが、
再現できてない状況です。

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

2018年3月6日 17時17分

中村です。

もしかして・・・カーネルのコンフィグレーションで
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

2018年3月7日 23時37分

中村です。

> USB-LAN アダプタのASIX(AX88xxxとAX88179/178A)を有効にしてますが、
> これが関係してますか?

カーネルだけ、G3Lのダウンロードサイトから取得した
(手を加えていない)イメージに入れ替えてみました。
at19, at20, at21、いずれも状況は変わらずで、
作っていただいたudevルールを/lib/udev/rules.dに配置すると、
gsm-ttyACM0がusb0になり、rename11ができてしまいます。
rebootで再起動すると必ず発生するようです。

--
なかむら

y.nakamura

2018年3月8日 2時03分

中村です。

70-x1-network.rulesの中の6行目("Armadillo-X1L Board"の方)の
KERNELS=="1-1:1.0"

KERNELS=="2-1:1.0"
に変更したところ、usb1に固定できたようです。

とりあえず私が使っている機体ではこれでOKになりましたが、
古関さんの環境では"1-1:1.0"でうまく動くとなると、
この違いの原因は何なのか?が問題になってくると思います。

# 6日にリリースされたアップデート
# https://armadillo.atmark-techno.com/news/20180306/software-update-aiotg…
# の atmark-x1-base (v1.5.3-1) にこの修正(私のところで動かなかったやつ)が
# 入ってしまってますよね?

# ついでに・・・
# このnewsページの次の2つのリンクが間違ってませんか? (G3のページもです)
# ・インストールディスクイメージ install_disk_sd_20180305_x1.img
# ・DTB (Device Tree Blob) armadillo_x1-v21.00.dtb

--
なかむら

y.nakamura

2018年3月13日 1時56分

中村です。

古関さん、

> 70-x1-network.rulesの中の6行目("Armadillo-X1L Board"の方)の
> KERNELS=="1-1:1.0"
> を
> KERNELS=="2-1:1.0"
> に変更したところ、usb1に固定できたようです。
>
> とりあえず私が使っている機体ではこれでOKになりましたが、
> 古関さんの環境では"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に2つあるUSBの
USB_OTG1とUSB_OTG2の違いかな?と
今まで思っていたのですが、違うのでしょうか?

--
なかむら

at_koseki

2018年3月13日 9時34分

中村さま

古関です。

> 70-x1-network.rulesの中の6行目("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を2つ接続した場合にudevルールが正しく動作しなくなります。
ただ、このケースはまずありえないので、ケアしないことにします。

ファイル ファイルの説明
70-x1-network.rules_.txt

y.nakamura

2018年3月13日 12時30分

中村です。

古関さん、
回答、ありがとうございます。

> 対策としては、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

2018年3月13日 18時47分

古関です。

> 「複数ある製品バリエーションで」とのことですが、
> この違いは具体的にはどのようなものでしょうか?
> 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

2018年3月13日 22時38分

中村です。

古関さん、

> はい。弊社にある試験用の試作品や特定のお客様専用の製品バリエーションでして、
> 一般のお客様向けに公開していないハードウェア構成のものです。

ご回答いただき、ありがとうございます。

> udevのルールを更新したatmark-x1-base(v1.5.4)を公開しました。
> 別途リリース案内を出す予定ですが、現時点でも
> apt-get update
> apt-get install atmark-x1-base

迅速な対応、どうもありがとうございます。

本件、これにてクローズとしたいと思います。

--
なかむら