vol32. Windows スポットライト
Windows スポットライト
日替わりで、壁紙やロック画面の写真が変わる。
日々、ネットから写真をダウンロードしているらしい。
これはよい機能だね。
TVのディスプレイに応用すれば日替わりフォトフレームになるな。
dynamic-theme というアプリを使うと、このwindows スポットライトの写真を壁紙にも
適用できる。
https://forest.watch.impress.co.jp/docs/review/1107477.html
https://www.microsoft.com/ja-jp/store/p/dynamic-theme/9nblggh1zbkw
vol31. Ethernet AVB gPTP のannounce message について
gPTPのGMを決定するプロトコルとして、BMCA(Best Clock Master Algorithm)がある。
BMCA は、GMになる能力のあるデバイス(gmCapableがtrueのデバイス)が、自身のクロック
精度情報を載せたAnnounce message をネットワーク内にマルチキャスト配信することに
より、どのデバイスがGM(Grand Master)になるかを決定するプロトコル。
各デバイスはAnnounce message を受け取ると、
1. 受信したAnnounce messageに記載されているクロック情報と、自身のクロック情報を比較
2. 自身のクロックが劣っていれば、
- slave port role へと移行
- Announce message の送信をやめる
3. 自身のクロックが勝っていれば、Announce message を送信し続ける
かくして最後まで勝ち残ったデバイス(annouce message を最後まで送信しつづけれたデ
バイス)がGrandMaster となる。
デバイスが単体の場合のgPTP の挙動
では、デバイスが単体の場合の挙動はどうなるか？
つまり、デバイスをEthernet switch に接続しない場合だ。
システム内に他のgmCapable デバイスが存在しないので、そのデバイスは
GrandMaster として動き続け、Announce message を送信し続ける ?
実際に、openAVBのgPTPを動かして挙動を確認してみた。
GMとして動作している状態で、Ethernet Switch とのケーブルを物理的に外したら
Announce mssageの発行が停止し、pdelay_req を送信する挙動になった。
何故か？
答えは、対向機(リンクパートナー)がasCapable = false と判定されたためだ。
802.1AS 対応デバイスと認定されなかったのだ。
gPTP デバイスはpdelay_reqを周期的に発行し、リンクパートナーが常に存在しているかを
診断している。pdelay_req の応答があるか、測定されたpropagation delay値がthresh
hold を越えていないかといった項目を確認し、判別している。
今回の実験では、pdelay_reqに対する応答がなかったため、802.1AS対応デバイスが存在
しなくなったと判定され、その結果、ethernet port のport role がDisabledPort 状態
へと移行したため、Announce message が発行されなくなった。
なるほどね。
vol30. Windows/Linux on virtual machine/Linux on remote でクリップボードの共有
私の開発環境は、windows PCとその上で走る仮想マシン上でLinux、そして、remote に
desktop PCのLinuxを使用している。
これらのクリップボードの共有のしくみは以下の通り
-
- vmware-toolsを利用
Linux OS on virtual - tmux
- xclip を利用
- .tmux.conf に以下の設定
bind-key -t vi-copy 'y' copy-pipe "xclip -sel clip -i"
bind-key p run-shell 'xclip -sel clip -o | tmux load-buffer -; tmux paste-buffer' - tmux list-buffers コマンドでクリップボード確認
Linux OS on virtual - Linux OS remote
- X forwarding を利用
- ssh -X でremote にログイン
一枚の絵で書くと以下のとおり。
X forwarding を利用するとremote のPCとクリップボードが共有できるのは知らなかった。
vol29. SIOCADDRT: File exists/RTNETLINK answers: File exists エラー
$sudo systemctrl restart networking
を実行すると、以下のエラー
Job for networking.service failed because the control process exited with error code.
See "systemctl status networking.service" and "journalctl -xe" for details.
ログ通りに
$journalctl -xe
を実行すると、
May 15 16:24:12 pc-linux avahi-daemon[598]: Joining mDNS multicast group on interface enp5s0.IPv4 with address 192.168.0.63
May 15 16:24:12 pc-linux avahi-daemon[598]: New relevant interface enp5s0.IPv4 for mDNS.
May 15 16:24:12 pc-linux avahi-daemon[598]: Registering new address record for 192.168.0.63 on enp5s0.IPv4.
May 15 16:24:12 pc-linux dhclient[12150]: bound to 192.168.0.63 -- renewal in 241 seconds.
May 15 16:24:12 pc-linux ifup[12133]: bound to 192.168.0.63 -- renewal in 241 seconds.
May 15 16:24:12 pc-linux ifup[12133]: SIOCADDRT: File exists
May 15 16:24:12 pc-linux ifup[12133]: ifup: failed to bring up enp5s0
May 15 16:24:15 pc-linux avahi-daemon[598]: Joining mDNS multicast group on interface enp8s0.IPv4 with address 192.168.101.2
May 15 16:24:15 pc-linux avahi-daemon[598]: New relevant interface enp8s0.IPv4 for mDNS.
May 15 16:24:15 pc-linux avahi-daemon[598]: Registering new address record for 192.168.100.20 on enp8s0.IPv4.
May 15 16:24:15 pc-linux ifup[12133]: RTNETLINK answers: File exists
May 15 16:24:15 pc-linux kernel: IPv6: ADDRCONF(NETDEV_UP): enp8s0: link is not ready
May 15 16:24:15 pc-linux ifup[12133]: ifup: failed to bring up enp8s0
May 15 16:24:15 pc-linux systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
May 15 16:24:15 pc-linux systemd[1]: Failed to start Raise network interfaces.
どうやら以下のログのとおり、ネットワークインターフェース enp5s0 と enp8s0 のifup で失敗している模様だ。
ifup[12133]: SIOCADDRT: File exists
ifup[12133]: ifup: failed to bring up enp5s0
ifup[12133]: RTNETLINK answers: File exists
kernel: IPv6: ADDRCONF(NETDEV_UP): enp8s0: link is not ready
ifup[12133]: ifup: failed to bring up enp8s0
ifup は/etc/network/interfaces の設定ファイルに基づいて、 ネットワークインターフェースの立ち上げを行うコマンド。
/etc/network/interfaces の設定は、
auto enp5s0
iface enp5s0 inet dhcp
post-up route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.3.254
auto enp7s0
iface enp7s0 inet static
address 192.168.101.2
netmask 255.255.255.0
gateway 192.168.101.1
auto enp8s0
iface enp8s0 inet static
address 192.168.100.20
netmask 255.255.255.0
gateway 192.168.100.1
ifup は -v オプションで詳細なログが表示される。 まずは、enp5s0が失敗する原因について調査。
$sudo ifdown --force enp5s0
$sudo ifup -v enp5s0
ifup: configuring interface enp5s0=enp5s0 (inet)
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
/sbin/dhclient -4 -v -pf /run/dhclient.enp5s0.pid -lf /var/lib/dhcp/dhclient.enp5s0.leases -I -df /var/lib/dhcp/dhclient6.enp5s0.leases enp5s0
....
DHCPDISCOVER on enp5s0 to 255.255.255.255 port 67 interval 6
DHCPREQUEST of 192.168.0.63 on enp5s0 to 255.255.255.255 port 67
DHCPOFFER of 192.168.0.63 from 192.168.3.254
DHCPACK of 192.168.0.63 from 192.168.3.254
bound to 192.168.0.63 -- renewal in 275 seconds.
route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.3.254
SIOCADDRT: File exists
ifup: failed to bring up enp5s0
なるほど、 route add コマンドの実行結果が、SIOCADDRT: File exists につながっているのね。
route add コマンドの直前まで、マニュアルでコマンドを実行して、routing table を表示してみると、
$sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.3.254 0.0.0.0 UG 0 0 0 enp5s0
192.168.0.0 0.0.0.0 255.255.248.0 U 0 0 0 enp5s0
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 enp8s0
192.168.101.0 0.0.0.0 255.255.255.0 U 0 0 0 enp7s0
route add コマンドで実施したいdefault gatewayがすでに追加されている。dhclient コマンドで設定されるみたいだ。
よって、/etc/network/interfaces から以下の行を削除。
post-up route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.3.254
同様の手順で、enp8s0 のerror の原因を調査してみると、以下の行が問題だったため、 削除。
gateway 192.168.100.1
最後にもう一度動作確認。
$sudo systemctrl restart networking
よし。エラーなし！！
ちなみに、以下のようにifdown コマンドでinteface not configured エラーになる場合は、 /run/network/ifstate が壊れている。 ifconfig コマンドを使ってネットワークを立ち上げたり、ifup/ifdown コマンドが失敗したりして、ifstate ファイルの更新が失敗して、 実際のネットワークインターフェースの状態と不整合が起きた時に発生する。
その場合は、--force option をifup/ifdown コマンドに渡してあげれば、ifstate ファイルの状態を無視してコマンドを実行してくれる。
$sudo ifdown -v enp5s0
ifdown: interface enp5s0 not configured
ネットワーク立ち上げ後は、以下が正常な状態
$ cat /run/network/ifstate
lo=lo
enp5s0=enp5s0
enp7s0=enp7s0
enp8s0=enp8s0
以下はネットワークがダウンしている状態
$ cat /run/network/ifstate
lo=lo
vol28. eclipse環境を構築する2
以下の記事の続き。
eclipse のdebug環境は、バックエンドにgdb を利用し、フロントエンドのGUIにgdb
の結果を出力したり、アイコン操作をgdbの各種コマンドに紐づけているといった仕
組みになっている。
native 環境では、gdbのみを利用するが、クロス環境では、target でgdb serverを
走らせ、hostでクロス向けのgdb を走らせる。debug前にgdb server をtargetで自動
的に走らせるために、sshやtcf等を利用する。
本来やりたかった、eclipseをwindows 上にインストールして、そこから仮想マシン
上で走るLinuxのアプリのデバッグやremote マシン上で走るアプリのデバッグでも、
クロス向けのgdbを準備する必要があり、これが一苦労だ。
ネット上で、自分の所望のクロス向けgdbを探してくるか、自分でgdbのソースコード
をダウンロードし、windows上でビルドする必要がある。gdbのビルド環境として、
cygwinやmingwといったwindows 環境向けのGNU開発環境を準備する必要がある。
結局、この手間を嫌い、eclipse をwindows上で走らせるのは断念。
動きがもっさりするけど、vmware上のlinux でeclipseを走らせ、その画面をx
forwarding でwindows 環境に飛ばす手法をとることにした。
vol27. ssh 接続問題奮闘記
先日開発のサブPCとして、desktop PC を入手。
そこにLinux をインストールし、メインのLinuxからsshでログインして、サブPCを使用
する環境で作業をしてきた。サブで立ち上げたいGUIアプリは、X forwarding を利用
して、メインPCに飛ばす使い方だ。
ただ環境を構築してから、数日間、ssh connection が切れる問題についてずっと悩
まされてた。
write failed: Broken pipe
のメッセージを残して、ssh 接続が切れる。
問題解決のために以下のことを実施した。
google 先生に聞いてみると、 ssh サーバーやクライアントの設定で、
以下をいじると直るとの投稿が多数あるため、試すも効かず。
ServerAliveInterval
ServerAliveMax
ClientAliveInterval
ClientAliveMax
TCP keep alivessh server 側の/var/log 下のログで、問題発生時に、更新のあったものを全て
目を通したが怪しいものはない
ssh client 側も debug オプションを最大にして(-vvv) 試すも、手がかりとな
るメッセージはないssh server 側のネットワークカードを違うもので試したが改善せず
ハードウェアの問題ではなさそう。問題発生時は、ssh server - client 間のping が一定時間(数秒) 繋がらず
ただ、ssh connection をつないだ状態で、意図的にserver 側のnetwork
interface をifconfig eth0 down で遮断しても、client 側では、
ssh でつないだシェルが応答しないだけで、
write failed: Broken Pipe とはならない。
よって、何らかの理由でnetwork が一定時間遮断されても問題ないはず。
そもそも、上記#1の設定がそのような状況に対応するためのものだ。以下の投稿を発見。カーネルの問題があるかもしれないとか。
私の環境では、ssh server にdebian stretch を使っており、
kernel のversion は4.9.0.6。怪しい。
https://unix.stackexchange.com/questions/259225/packet-write-wait-broken-pipe-even-leaving-top-runningそこで、とあるnetwork キャプチャーソフトを使って、問題発生時のTCP port22
のメッセージを観測していた所、Reset flag がセットされたTCP message が観測さ
れた!! 上記ブログの通りだ。
kernel のdriver の問題なのか？ stretch で他に利用できるkernel がないか調べ
たら、4.16.0があったのでそれで試したが、まだ問題発生。
ダウングレードしないといけないか？そして、最後にnetwork switch を介さずssh server とclient で直接接続したら、
！！！問題が発生しなくなった。すくなくとも一晩。
Ethernet switch の問題？
だが、違うEthenrnet switch を接続して試しても問題発生。うーむ。。。どういうことだ？？
結局今は、Ethernet switch を介さず直接接続で運用しています。
vol26. eclise環境(リモートデバック環境)を構築する1
私は現在、Linux base の組み込み機器を開発する仕事に従事している。
開発環境は、 windows PC 上に、仮想マシンを用意し、そこにlinux をインストール
して使用している。組み込み機器でソースコードをいじる部分は、linux device
driverやlinux 上のアプリ郡で、ほとんどシェル上で閉じた作業となる。
たまに、gstreamer のplugin といった複雑なアプリをデバッグする場合、GUI を用
いたデバッグをしたくなる。そこで、linux 上に、統合開発環境としてよく用いられ
ているeclipseをインストールしてみた。しかし、vmware 上でGUIを走らせるとGUIの
ウインドウの描画に時間がかかるせいか、動きがもっさりとしてとても開発効率が悪
い。
そこでeclipseをwindows 上にインストールして、そこからリモートデバッグ機能を
利用した環境を構築することにした。
この環境を構築しておけば、今後アプリのデバッグ効率も高まるはず。
後に、環境の構築方法や便利な設定を投稿していきたい。
