1月 142023
 

このブログでは何回か VRF について書きました。 FreeBSD の VRFubuntu の VRF など。 FreeBSD のポリシールーティングのネタも書いたこともありました。

そのとき CentOS7 はカーネルがまだ VRF に対応していなくて、CentOS8 まで VRF は実質利用できない状態だったのだけど、今の時代、AlmaLinux8 を利用すればカーネル的に VRF が利用できるので、試してみました。

ubuntu のネットワーク設定より Red Hat Linux 系のネットワーク設定のほうが楽と、いうか、個人的にも直感的に設定できるような状態ですしね(^^;;。今回は由緒正しく /etc/sysconfig/network-scripts/ 配下のファイルを用意して VRF の設定をしてみたいと思います。

 
と、いうことでまずは構成図などを。



 
基本的に FreeBSD の VRF も同じ構成で組んでいます。セグメントは全部で 3 個。

  • Service-Segment: 外部からのアクセス用
  • Access-Segment: MySQL とか SNMP とかバックヤード系
  • mgmt: ssh でサーバにログインする用

 
今回のルーティングテーブルは合計二つ。Service-Segment と Access-Segment で一個のルーティングテーブル。 mgmt が VRF で設定するもう一個のルーティングテーブルになります。

FreeBSD で VRF するときに痛感したのですが、自分から出すパケットは default のルーティングテーブルからしか出ていきません。VRF で追加したルーティングテーブルの mgmt セグメントの 192.168.1.0/24 に ssh しようとしても default のルーティングテーブルから出ていきます。

例えば 192.168.52.201 で動作している MySQL にアクセスしようとした場合、default のルーティングテーブルから出ていくのですが Access-Segment で利用しているセグメントがローカルネットワークになっているのでそこから出ていきます。
MySQL サーバが 172.16.52.201 にあった場合、 default gateway の設定のある Service-Segment から出ていきますが、 MySQL のアクセスは Access-Segment から出ていきたいので route add -net 172.17.52.0/24 gw 192.168.52.1 とか Access-Segment にルーティング設定をしてあげる必要があります。

 
と、いうことで VRF を設定して本当に幸せになるのかよくわかりませんが、とりあえず設定して行ってみましょう。

上記の構成図に合わせて /etc/sysconfig/network-scripts/ にファイルを用意していきます。

ifcfg-eth0
ifcfg-eth1
ifcfg-eth2
ifcfg-vrf.eth2
route-vrf.eth2
route6-vrf.eth2

実際に中を見てみましょう。

Service-Segment: ifcfg-eth0

TYPE=Ethernet
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6ADDR=2001:470:fe36:face::217:1
IPV6_DEFAULTGW=2001:470:fe36:face::1
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=eth0
DEVICE=eth0
ONBOOT=yes
IPV6_PRIVACY=no
MACADDR=permanent
IPADDR=192.168.22.217
PREFIX=24
GATEWAY=192.168.22.1

 
Service-Segmet に接続する eth0 には default gateway を設定しています。

 
Access-Segment: ifcfg-eth1

TYPE=Ethernet
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6ADDR=2001:470:fe36:cafe::217:1
#IPV6_DEFAULTGW=2001:470:fe36:cafe::1
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=eth1
DEVICE=eth1
ONBOOT=yes
IPV6_PRIVACY=no
MACADDR=permanent
IPADDR=192.168.52.217
PREFIX=24
#GATEWAY=192.168.52.1

 
こちらは内部のアクセス用ネットワークなので、default gateway は設定していません。実際には route add -net でネットワークごとにルーティング情報を追加するんだろうなぁ。と、いう気配です。

 
mgmt: ifcfg-eth2

TYPE=Ethernet
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6ADDR=2405:6580:aa40::217:1
IPV6_DEFAULTGW=2405:6580:aa40::1
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=eth2
DEVICE=eth2
ONBOOT=yes
IPV6_PRIVACY=no
MACADDR=permanent
IPADDR=192.168.1.217
PREFIX=24
GATEWAY=192.168.1.1

 
マネージメント用ネットワークで外部から ssh でログインするときに利用します。これが VRF を利用するインターフェースなので default gateway が設定してあります。でもって次のファイルも必要です。

 
mgmt-VRF: ifcfg-vrf.eth2

TYPE=Ethernet
DEFROUTE=yes
BOOTPROTO=none
IPADDR=192.168.1.217
PREFIX=24
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=no
IPV6ADDR=2405:6580:aa40::217:1
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=vrf.eth2
DEVICE=eth2
ONBOOT=yes
VRF=mgmt0

 
NAME= と VRF= で VRF で動作の設定です。ifconfig -a したときに mgmt0 というインターフェースが生えてきます。

 
mgmt-route-IPv4: route-vrf.eth2

ADDRESS=0.0.0.0
NETMASK=0.0.0.0
GATEWAY0=192.168.1.1

 
VRF 側の IPv4 のルーティングテーブルの設定です。

mgmt-route-IPv6: route6-vrf.eth2

::/0 via 2405:6580:aa40::1

 
こちらが VRF 側の IPv6 のルーティングの設定。

 
で、これで準備ができたので一応再起動してみます。がっ!!

これがまた正しく動作しないのですよなぁ・・。 orz。

 
と、いうことで、追加で /etc/rc.local に設定を記載して、ちゃんど動作するようにコマンドを羅列します。 orz

ip link add dev mgmt0 type vrf table 10
ip link set dev mgmt0 up
ip link set dev eth2 master mgmt0
ip addr add dev eth2 192.168.1.217/24
ip link set dev eth2 up
ip route add default via 192.168.1.1 table 10
ip route add ::/0 via 2405:6580:aa40::1 table 10

route delete default
route delete default
route add default gw 192.168.22.1

ip route del ::/0 via 2405:6580:aa40::1
ip route del ::/0 via 2001:470:fe36:face::1
route -6 add default gw 2001:470:fe36:face::1

sysctl -w net.ipv4.tcp_l3mdev_accept=1
sysctl -w net.ipv4.udp_l3mdev_accept=1

 
最後の sysctl コマンドは /etc/sysctl.conf に記載しても良いですね。
問題はその上です。

上から順に、

  • インターフェース mgmt0 を vrf として作成し table 10 とします
  • インターフェース eth2 と mgmt0 をくっつけます
  • table 10 (VRF 側) に default route を設定します
  • default のルーティングテーブルが壊れているようなので default gateway を二回削除してからつけ直します (ほんとうにこれしないとダメだった・・orz)

 
ルーティングの情報は IPv4 と IPv6 両方で実施します。これで大丈夫みたい。

確認方法は以下です。

# ip route show
default via 192.168.22.1 dev eth0 
192.168.1.1 dev eth2 proto static scope link metric 102 
192.168.22.0/24 dev eth0 proto kernel scope link src 192.168.22.217 
192.168.52.0/24 dev eth1 proto kernel scope link src 192.168.52.217 

# ip -6 route show
::1 dev lo proto kernel metric 256 pref medium
2405:6580:aa40::/64 dev eth2 proto kernel metric 102 pref medium
2001:470:fe36:face::/64 dev eth0 proto kernel metric 100 pref medium
2001:470:fe36:cafe::/64 dev eth1 proto kernel metric 101 pref medium

# ip route show table 10
default via 192.168.1.1 dev eth2 
broadcast 192.168.1.0 dev eth2 proto kernel scope link src 192.168.1.217 
local 192.168.1.217 dev eth2 proto kernel scope host src 192.168.1.217 
broadcast 192.168.1.255 dev eth2 proto kernel scope link src 192.168.1.217 

# ip -6 route show table 10
local 2405:6580:aa40::217:1 dev eth2 proto kernel metric 0 pref medium
local fe80::751c:3cc8:a2c0:2fcb dev eth2 proto kernel metric 0 pref medium
multicast ff00::/8 dev eth2 proto kernel metric 256 pref medium
default via 2405:6580:aa40::1 dev eth2 metric 1024 pref medium

# ip -d link show type vrf
6: mgmt0:  mtu 65575 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 12:c4:f9:dc:1f:bf brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 1280 maxmtu 65575 
    vrf table 10 addrgenmode none numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 

 
なんか良さげな感じがしています。

192.168.22.1 から eth2 のアドレスに対してアクセスした場合、戻りパケットはちゃんと eth2 から出ていきます。 19.268.1.50 から eth0 のアドレスに対してアクセスした場合、ちゃんと eth0 から戻っていきます。ある意味 VRF が機能している。と、いう感じです。やりたかったことはこれですね。

 
ただ、自分から出ていくパケットについてが問題です。default のルーティングテーブルから出ていくのが基本で、別のルーティングテーブルを利用したい場合は ping -I eth2 192.168.1.40 みたいにインターフェースを指定する必要があります。明示的にコマンドを打つなら良いですが、例えば php から MySQL にアクセスするために VRF 側のルーティングテーブルを利用して外に出ていきたい。などというのはほぼ不可能です。

使い方が非常に限られる VRF ですが、機能的には一応、動作する。と、いうことですなぁ。

 
さてと。今回構築したこの AlmaLinux release 8.7 の環境ですが、もうしばらく利用したいと思います。次のエントリは今回作成した環境を利用します。が、直接的・動作的には全く関係ないですが、好ご期待;-)。

1月 082022
 

ウェブで色々調べてみると、みんな中途半端なネタしかなくて、ウェブ UI まで含めた Docker Registry を作るのにずいぶんと苦労しました。

今回はそれをきれいさっぱりとまとめてみたいと思います。

僕はそれほど Docker に詳しくはないけど、今回のターゲットの読者 (って、いるのかな?;-) は、普段から Docker コンテナを利用していて、 Docker image を自分が作成した Docker Registry で管理したい人向けです。

では始めます。今回のプラットホームは AlmaLinux 8.5 です。 docker は以下です。

$ cat /etc/os-release 
NAME="AlmaLinux"
VERSION="8.5 (Arctic Sphynx)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.5"
PLATFORM_ID="platform:el8"
PRETTY_NAME="AlmaLinux 8.5 (Arctic Sphynx)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:almalinux:almalinux:8::baseos"
HOME_URL="https://almalinux.org/"
DOCUMENTATION_URL="https://wiki.almalinux.org/"
BUG_REPORT_URL="https://bugs.almalinux.org/"

ALMALINUX_MANTISBT_PROJECT="AlmaLinux-8"
ALMALINUX_MANTISBT_PROJECT_VERSION="8.5"

$ rpm -qa | grep dock
docker-scan-plugin-0.12.0-3.el8.x86_64
docker-ce-rootless-extras-20.10.12-3.el8.x86_64
docker-ce-cli-20.10.12-3.el8.x86_64
docker-ce-20.10.12-3.el8.x86_64
$

 
まず、Docker image を取ってきます。まぁ、ほぼほぼ標準のイメージです。
あ、 /etc/group の docker グループに自分のアカウントを追加して上げましょう。一般ユーザ権限で docker コマンドが利用可能になります。

$ docker pull registry:2
<略>
$ docker pull konradkleine/docker-registry-frontend:v2
<略>
$ docker pull ekazakov/docker-registry-frontend
<略>

 
一番最初の docker pull は Registry サーバ本体です。
二番目の docker pull は ウェブで検索すると良く出てくる Registry のウェブ UI です。
三番目の docker pull は registry:2 のウェブ UI ですが、なんと、削除ボタンが付いていて不要な Docker image を削除することができます(が、僕はまだ削除したことないですf(^^;;)。

これで Docker image が揃ったので docker run してみます。と、言いつつまだまだ準備ができていません。

と、いうか、最近の docker pull/push は SSL に対応しているので、プライベートで立てる Registry サーパ (『リポジトリサーバ』とも言う) も SSL でアクセスできるようにして上げる必要があります。
つまり、 Docker image の registry:2 を起動するためには SSL 証明書が必要なんですな。 Let’s Encrypt などでまずは証明書を準備してください。

ここ、大切な部分です。この工程をはしょって『プライベートレジストリを構築するーっ!!』って、サイトが多くてイヤになる・・。非常にノイジー。古いコンテンツは消して欲しい。と、思う部分ですな。
とはいいつつ、僕のサイトにも古い記事が今でも残っているけど・・f(^^;;。

と、いうことで registry:2 を run するための証明書の準備です。

# mkdir /opt/docker/repository/certs/
# cd /usr/local/etc/letsencrypt/live/running-dog.net/
# cat cert.pem > /opt/docker/repository/certs/domain.crt
# cat chain.pem > /opt/docker/repository/certs/ca.crt
# cat privkey.pem > /opt/docker/repository/certs/domain.key

 
Let’s Encrypt で取得した証明書を /opt/docker/repository/certs/ と、いうディレクトリにそれぞれの名前で格納しました。自分のドメイン名に照らし合わせてください。
あーぅー。Linux の場合、 Let’s Encrypt のベースディレクトリはどこになるのだろう? 上記の例では FreeBSD 的に /usr/local/etc/letsencrypt/ になっていますな。自分の環境に合わせてくださいf(^^;;。

そして、追加でもう少し。

# cd /usr/local/etc/letsencrypt/live/running-dog.net/
# cat cert.pem > /etc/pki/tls/certs/running-dog.net.crt
# update-ca-trust
# systemctl restart docker

 
証明書を準備したら上記コマンドを実行してください。証明書を更新したときも実行してください。
SSL 証明書を /etc/pki/tls/certs/ に設置したあと update-ca-trust コマンドを叩いて dockerd を再起動しなます。
これをやらないと docker pull や push がエラーになるかもしれません。

 
さてと。これで SSL 証明書関連の準備が完了です。起動するときは以下のような感じ。

# mkdir /opt/docker/repository/data/
$ docker run -d -p 0.0.0.0:5000:5000 --restart=always \
 -v /opt/docker/repository/data:/var/lib/registry \
 -v /opt/docker/repository/certs:/certs \
 -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \
 -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key \
 --name registry-server \
 registry:2

 
-v でレジストリのデータを管理するディレクトリと、証明書が格納されているディレクトリをコンテナから参照できるようにしてあげます。

IP アドレスは 0.0.0.0 を指定してあげまていますが、Docker ホスト側の IP アドレスの Port:5000 に (telnet で) アクセスすると開いているかと思います。
Registry サーバは SSL でアクセスするので、 Docker ホストの IP アドレスに FQDN を指定してあけます。今回は registry.running-dog.net にしました。view internal な DNS ゾーンファイルに設定するか /etc/hosts に指定してください。

curl を利用して以下の要領でアクセスすれば良いです。

$ curl -k https://registry.running-dog.net:5000/v2/_catalog
$ curl -k https://registry.running-dog.net:5000/v2/centos/tags/list

 
上の curl は docker push されている、つまり、プライベートレジストリに登録されている Docker image の一覧が表示されます。
下の curl は、仮にプライベートレジストリに centos という Docker image が push されていたとすると登録してあるタグ番号一覧を返してくれます。

ここまでは Port:5000 でアクセスする Registry サーバ側の設定と起動方法になります。ウェブ UI がなくても上記 curl でイメージとタグ番号の確認はできます。

 
では、ここからはいよいよウェブ UI 側のコンテナの起動です。

インターネット上で検索してみると、docker run してサクっと Registry サーバに接続してその情報を表示してくれる。みたいなサイトがゴマンとありますが、あれ、みんなウソです。全然表示してくれない。なんでやねんっ!?

僕もずいぶんと悩みました。どんなにやってもウェブ UI のコンテナから Registry サーバにアクセスできないっ!! ずっと悩んでいたのですが、ようやっと、問題解決です。

先にタネ明かししますが Registry サーバへは SSL で Port:5000 にアクセスします。 URL 的には https://registry.running-dog.net:5000/ になりますね。
ウェブ UI 側も registry.running-dog.net の Port:5000 にアクセスするように docker run 時に指定するのですが、これは http で registry.running-dog.net の Port:5000 にアクセスしているんですね。プロトコルが https で Port:5000 にアクセスできていないので、ウェブ UI 上に Registry サーバ の情報を表示できなかったんですね。

ここの情報について書いているサイト、ほぼ皆無です。

ウェブ UI 側のコンテナは以下のように docker run してみましょう。

$ docker run -d -p 0.0.0.0:8080:80 \
 --net reg-Segment \
 -e ENV_DOCKER_REGISTRY_HOST=registry.running-dog.net \
 -e ENV_DOCKER_REGISTRY_PORT=5000 \
 -e ENV_DOCKER_REGISTRY_USE_SSL=1 \
 -e DOCKER_REGISTRY_SCHEME \
 --name registry-web \
 ekazakov/docker-registry-frontend:latest

 
今回は削除ボタンのある ekazakov/docker-registry-frontend:latest の Docker image を利用してみました。
-e で環境変数を指定します。よくあるのは ENV_DOCKER_REGISTRY_HOST と ENV_DOCKER_REGISTRY_PORT です。この二つだけの指定では ウェブ UI は http で ENV_DOCKER_REGISTRY_HOST に指定したホストの ENV_DOCKER_REGISTRY_PORT に指定したポート番号にアクセスします。

この瞬間、まさに『ダメだ。こりゃ。』な状態です。

https でアクセスするためには更に追加で DOCKER_REGISTRY_SCHEME と ENV_DOCKER_REGISTRY_USE_SSL=1 を指定してあげます。これで Registry サーバに https でアクセスしに行って、ウェブ UI 上に登録されている情報を表示してくれるようになります。

いやぁ・・。疲れた。あとはひたすらウェブ UI を使い込んでいくことなるかと思います。ふぅ・・。

 
と、いうことで、 https でアクセスする Registry サーバと Registry サーバから https で情報を取りに行ってウェブ UI に表示してくれる Registry サーバのウェブ UI がセットで起動できました。
あ、ウェブ UI 側は http://registry.running-dog.net:8080/ でアクセスできます。こちらのプロトコルは http です;-)。

 
では、どうして今回、ウェブ UI は『どうして表示できないのだ?!』と、悩んでいたのが解決できたか?についてですが『そもそも https でアクセス行ってないからじゃね?』と、思ったから。が、ベースとなっていますが Docker image である registry:2 も ekazakov/docker-registry-frontend:latest も docker exec で中に入ることができないんですねぇ・・。コンテナに与える環境変数は他にはないのか?確認する手段が無かった。と、いうのが大きな点ではありますが、ところがそうではないっ!!

$ docker ps -a
CONTAINER ID   IMAGE                                      COMMAND                  CREATED        STATUS        PORTS                                            NAMES
2f3a138f1b8e   ekazakov/docker-registry-frontend:latest   "/bin/sh -c $START_S…"   23 hours ago   Up 23 hours   443/tcp, 0.0.0.0:8080->80/tcp, :::8080->80/tcp   registry-web
d1e9dbf6e9a5   registry:2                                 "/entrypoint.sh /etc…"   24 hours ago   Up 24 hours   0.0.0.0:5000->5000/tcp                           registry-server
$ docker exec -it d1e9dbf6e9a5 /bin/bash
OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "/bin/bash": stat /bin/bash: no such file or directory: unknown
$ docker exec -it d1e9dbf6e9a5 /bin/sh
/ # ls -l /bin/busybox 
-rwxr-xr-x    1 root     root        841288 Nov 12 11:37 /bin/busybox
/ # exit
$

 
docker ps してから docker exec -it で registry:2 に /bin/bash で入ろうしたけど、/bin/bash がないので、試しに /bin/sh にしてみたらあらは入れた。ついでに registry:2 は busybox で動作しているのねぇ。 i386 i686 系の busybox って、初めて見た。みたいな。

 
konradkleine/docker-registry-frontend:v2 も /bin/bash はないけど /bin/sh で中に入れます。
ekazakov/docker-registry-frontend:latest は /bin/bash で中に入れました。

$ docker exec -it 2f3a138f1b8e /bin/bash
root@2f3a138f1b8e:/# env
HOSTNAME=2f3a138f1b8e
APACHE_RUN_USER=www-data
TERM=xterm
ENV_DOCKER_REGISTRY_PORT=5000
APACHE_LOG_DIR=/var/log/apache2
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
APACHE_RUN_GROUP=www-data
ENV_DOCKER_REGISTRY_USE_SSL=1
SOURCE_DIR=/tmp/source
WWW_DIR=/var/www/html
SHLVL=1
HOME=/root
START_SCRIPT=/root/start-apache.sh
ENV_DOCKER_REGISTRY_HOST=registry.running-dog.net
_=/usr/bin/env
root@2f3a138f1b8e:/# cat /root/start-apache.sh
<略>
root@2f3a138f1b8e:/# exit
$

 
こんな感じです。 ekazakov/docker-registry-frontend:latest の ウェブ UI は apache で起動しているみたいです。 /root/start-apache.sh の中に docker run 時に指定した環境変数を取り込んでホスト名・ポート番号・プロトコルが設定されます。
この /root/start-apache.sh のファイルの中をじっくりと確認することによって、そこから想像する分には『https://でアクセスするようにしないとアカンのねえ・・。』と、思いつくのでありました。
あとは環境変数を見つけてそれをコンテナに渡してあげれば・・。ふぅ。なんとか動き出した。と、いう状態なのでありました。それが 、 DOCKER_REGISTRY_SCHEME と ENV_DOCKER_REGISTRY_USE_SSL なのでありますね。

 
それにしても、有名どころの git で拾ってきた Docker image も docker exec で /bin/bash で中に入れないとき /bin/sh とかだと入れるとか、他にもっと実は色々な入り方 (裏技) があるのかもー。と、関心させられた事象だったのであります。

そして、Port:5000 番でアクセスする Registry サーバと、Port:8080 でアクセスする ウェブ UI 。ふぅ。なんとか構築することができたのであります。

 
今の docker pull/push は SSL が基本です。http でアクセスできていた古いインターネット上の記事には惑わされないようにしてください;-P。

7月 272017
 

ちょっと前のエントリで FreeBSD のポリシールーティングについて書きました。そのときは FreeBSD においては pf で設定しました。そして、他のやり方がないのか検討し、その記事の下のほうには setfib コマンドでルーティングテーブルを操作して正しいルーティングができるのか試しているのですが、結局はダメだったのであります。

Linux 方面では ip route+ip rule でのポリシールーティングの運用となりますが、カーネルのバージョン 4.4 から VRF が利用できる。というので setfib と比較してどれくらい効果的に機能するのか試してみました。
Linux カーネルが 4.4 以上なディストリビューションには何があるのか調べてみると ubuntu-17.04 が対応しているようなので ISO イメージをダウンロードしてインストールし、実際に設定までしてみます。

 
僕自身 ubuntu はあまり使ったことが無いディストリビューションで Raspberry Pi の Volumio に続き二個目のインストール環境です。仕事でもデスクトップでも使ったことがありません;-)。

それにしても ubuntu のネットワーク設定である /etc/network/interfaces の記述方法が相変わらず解らないので、いつものように /etc/rc.local でやってしまえ。などと思っても ubuntu にはこのファイルが無いし、起動時に利用できないのですねぇ。

以下の URL を参照させて頂き /etc/rc.local を動くようにしました;-)。

http://qiita.com/msrks/items/5201ae15d0e1f8de5946

簡単に書いておくと

o. /etc/systemd/system/rc-local.service を作成

[Unit]
Description=/etc/rc.local compatibility

[Service]
Type=oneshot
ExecStart=/etc/rc.local
# disable timeout logic
TimeoutSec=0
#StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99

[Install]
WantedBy=multi-user.target

 
o. enable する

systemctl enable rc-local.service

 
これで /etc/network/interfaces と /etc/rc.local にコマンドを書いて、起動時に実行されるようになりました。

と、いうことで、以降は VRF を利用するネットワークの設定を行います。

 
まず、ネットワーク構成ですが、この前のエントリ「FreeBSD でポリシールーティング。」で書いた CentOS 6.9 を ubuntu-17.04 にリプレイスして ip route+ip rule をやめて VRF を利用してみます。

Server1 が Linux (CentOS 6.9) だったので、これを設定します。以下はネットワークの情報です。

・Server-Zone の IPv4 Gateway: 192.168.22.1
・Server-Zone のサーバ IPv4 アドレス: 192.168.22.10
・Server-Zone の IPv6 Gateway: 2001:470:fe36:beef::1
・Server-Zone のサーバ IPv6 アドレス: 2001:470:fe36:beef::2:1
・LAN-Zone の IPv4 Gateway: 192.168.1.1
・LAN-Zone のサーバ IPv4 アドレス: 192.168.1.10
・LAN-Zone の IPv6 Gateway: 3ffe:6580:aa40::ffff:1
・LAN-Zone のサーバ IPv6 アドレス: 3ffe:6580:aa40::2:1

これを VRF を利用するように設定します。が、その前に注意点を。

NIC が二個あるのでそれぞれの NIC を VRF にしてルーティングテーブルを二つ別々に持たせよう。などと思ってはいけません。
NIC が二個の場合、一個は default のルーティングテーブル(ip [-6] route list で表示されるルーティングテーブル)を参照するようにして、もう一個の NIC は別のルーティングテーブルを持ち、かつ参照する構成が良いです。ここ、ハマリ道というか思い違いの点ですね。
この点については下のほうに詳しく書きます。

 
では、設定を上から順に見ていきます。

0). /etc/network/interfaces にネットワークの設定のみ書く
lo の他にインターフェース二つ分を書き gateway の設定は書かない

auto ens160
iface ens160 inet static
address 192.168.22.10
netmask 255.255.255.0
iface ens160 inet6 static
address 2001:470:fe36:beef::2:1
netmask 64

auto ens32
iface ens32 inet static
address 192.168.1.10
netmask 255.255.255.0
iface ens32 inet6 static
address 3ffe:6580:aa40::2:1
netmask 64

 
多分、/etc/resolv.conf が作られないので、以下のコマンドを /etc/rc.local に書いておくと良いかもしれんです。

cp -pr /etc/resolv.conf.SV /etc/resolv.conf

 
/etc/resolv.conf.SV は好きに書いてください;-)。
しかし、ディストリビューションの正しい設定方法を無視しているなぁ;-P。

 
1). IP アドレスの付加
僕の場合、/etc/network/interfaces に書いた IPv6 アドレスが自動的に付加されなかったので /etc/rc.local に書きました。
以降の設定は全て /etc/rc.local に書くと楽ちんです;-)。

ip addr add dev ens160 2001:470:fe36:beef::2:1/64
ip addr add dev ens32 3ffe:6580:aa40::2:1/64

 

2).ルーティング情報の付加
今回は Server-Zone 側を default のルーティングテーブルとして利用します。

route add default gw 192.168.22.1
route add -A inet6 default gw 2001:470:fe36:beef::1

 

3). VRF の設定
いよいよ、VRF の設定です。VRF は LAN-Zone 側に設定します。
ip [-6] route list コマンドで表示される default gateway は上でコマンドを打っています。 グローバル側の設定ですね。
VRF はマネージメントポート側で利用する。と、いう意味合いを込めて Cisco 風に mgmt という名にします;-)。

ip link add dev mgmt type vrf table 10
ip link set dev mgmt up

 
type は vrf で table 番号は 10 を利用しました。複数個の VRF を生成する場合はこの番号を増やしていけば良いです。

 
4). VRF と NIC の結びつけ
作成した VRF インターフェースと NIC を結びつけます。つまりは、マネージメントポート用の VRF は mgmt として LAN-Zone の NIC と結びつける。と、いうことですね。

ip link set dev ens32  master mgmt up

 
リモートから ssh で作業していて dev で指定する NIC からアクセスしていた場合、このコマンドを投入した段階でネットワークが切れます。なので反対側の NIC からアクセスして作業するか、コンソールからコマンドを叩く必要があります。
起動時の /etc/rc.local 読み込み時には問題はないんですけどね。

 
5). VRF に default gateway を設定
Server-Zone は default のルーティングテーブルを参照しますが、 LAN-Zone は個別の VRF のルーティングテーブルを参照します。なので別途 default gateway を設定します。 VRF の table 10 に対して route add します。

ip route add default via 192.168.1.1 table 10
ip route add default via 3ffe:6580:aa40::ffff:1 table 10

 

6). 外部からのアクセスを可能にする
最後に sysctl で以下の MIB 値を変更し、外部から VRF 側のネットワークアクセスを可能にします。これをしないと ssh などで接続することができません。

sysctl -w net.ipv4.tcp_l3mdev_accept=1

 
以上で VRF の設定は完了です。

 
確認方法は以下になります。

  • ip route list もしくは ip -6 route list
    default のルーティングテーブルを確認すときに利用
  • ip route list vrf mgmt もしくは ip -6 route list vrf mgmt
    設定した VRF の mgmt のルーティングテーブルを確認

その他、インターフェースの確認として ip link や ip addr を利用します。

 
さて。最初のほうで『二個の NIC に VRF を二個用意してはいけません。』と書いていますが、例えば二個の NIC それぞれで VRF を利用した場合 /etc/resolv.conf を参照しないなど、問題点も多いです。
そりゃそうでしょうなぁ。どっちの NIC から出ていくかわからないですし、リゾルバは正しく動作してくれないんでしょうな。

例えば NIC が ens160 と ens32 の二つがあった場合以下のコマンドを打ったとします。

ip link set dev ens160 master vrf0
ip link set dev ens32  master vrf1

 
この場合、二つの NIC でそれぞれ個別のルーティングテーブルを持つことになるんですが、

  • ping -I vrf0 IP アドレス もしくは ping -I vrf1 IP アドレス

では到達性があります。しかし、以下のように pingすると到達性がありません。

  • ping -I vrf1 FQDN

ルーティングテーブルが VRF のみになると DNS を引きに行ってくれないんですね。なので、 NIC が二個の場合は一個の VRF を設定するのみで、もう一個の NIC は default な ip [-6] route list で表示してくれる経路が必要になります。

二個の NIC で二個の VRF を設定すると netstat -nr や ip route list では何も表示してくれなくなります。

ループバックに IP アドレスとか記載できるのかな? lo:1 とか書けるのかな?そこまで試していませんが。

 
さてと。ここまで来て VPF の環境設定が終わりましたが、実際に利用してみるとやはり中々楽しいですね。
Cisco ルータの場合、 VRF は interface mgmt で動作することが多々あるんですが、今回は L3 ルータを作る。と、いう目的ではなく、サーバのポリシールーティングのかわりに VRF を利用してみた。と、いう感じですね。

ip [-6] route list で表示されるルーティングテーブルは、サービス側で利用し、マネジメントポート (今回はそれを LAN-Zone と呼んでます) で VRF を利用し、サービスセグメントのルーティング情報とは混在させないで通信を行う。こんな時に必要な機能だと思われます。

 
僕はこのあと VRF を利用しつつ、ウェブサーバを起動して CentOS 6.9 を引退させようと考えています;-)。

FreeBSD の setfib もここまで動いてくれると嬉しいのですが、そこまで到達していないのと、そもそも setfib は IPv6 が動かないので、今の所、僕の環境ではまるで使い道が無い・・。orz

7月 182017
 

最近 Asahi-Net で PoE じゃなかった。 IPoE で IPv6 が利用可能になった。僕は他にも hi.net で IPv6 を /48 ほど借りているので二つのセグメントが利用可能なのであります。贅沢だぁ;-)。

と、いうことで自宅のネットワーク環境を見直してみました。

IPv4/IPv6 のセグメントをそれぞれ表側・裏側と二つ用意したんですね。

構成図はこんな感じ。 (多少、端折っているf(^^;;)

Server-Zone と LAN-Zone があり、管理用 PC2 は両方のセグメントに到達性があるわけなんですが、実際に運用してみると非常に厄介。

例えば管理用 PC2 には LAN-Zone の 192.168.1.100 が、 Server-Zone には 192.168.22.100 が付加されているとして Server1 の Server-Zone 側の IPv4 に ping を打つと元リは LAN-Zone 側から戻ってきてしまう。ぐるっと回ってしまうんですね。

パケットの流れ的には以下のような感じ。PC2 のソースアドレスは 192.168.1.100 で出て行きます。

管理用PC2 の NIC1 -> Server2 の Server-Zone -> Server2 の LAN-Zone -> 管理用 PC2 の NIC2

ぐるっと一周の旅です。これがグローバルアドレスだと、ISP 側では『自分の管理してないアドレスからバケットが届いた。』ということで破棄されます。

あぁ・・。サーバにポリシールーティングの設定入れないと・・。 orz

FreeBSD の場合、 ipfw の fwd でも pf でも、バケットが届いた NIC から出ていく。って設定ができないんですね。
パケットが届いた NIC のゲートウェイアドレスに返す。って設定はできるようなんですけど、その場合はゲートウェイ経由で届いたパケットは送信元に戻っていくけど、同一セグメント上のコネクテッドな送信元には戻っていかない。まいったなぁ・・。

 
上記の構成図のうち Server1 が Linux (CentOS 6.9) の場合、以下のように /etc/rc.local に書くと良いです。

ip route add 192.168.22.0/24         dev eth0 tab 100
ip route add 2001:470:fe36:beef::/64 dev eth0 tab 110
ip route add 192.168.1.0/24          dev eth1 tab 120
ip route add 3ffe:6580:aa40::/64     dev eth1 tab 130

ip route add default via 192.168.22.1           dev eth0 tab 100
ip route add default via 2001:470:fe36:beef::1  dev eth0 tab 110
ip route add default via 192.168.1.1            dev eth1 tab 120
ip route add default via 3ffe:6580:aa40::ffff:1 dev eth1 tab 130

ip    rule add from 192.168.22.10/32           tab 100 priority 1000
ip -6 rule add from 2001:470:fe36:beef::2:1/64 tab 110 priority 1100
ip    rule add from 192.168.1.10/32            tab 120 priority 1200
ip -6 rule add from 3ffe:6580:aa40::2:1/64     tab 130 priority 1300
ip route flush cache

 
・Server-Zone の IPv4 Gateway: 192.168.22.1
・Server-Zone のサーバ IPv4 アドレス: 192.168.22.10
・Server-Zone の IPv6 Gateway: 2001:470:fe36:beef::1
・Server-Zone のサーバ IPv6 アドレス: 2001:470:fe36:beef::2:1
・LAN-Zone の IPv4 Gateway: 192.168.1.1
・LAN-Zone のサーバ IPv4 アドレス: 192.168.1.10
・LAN-Zone の IPv6 Gateway: 3ffe:6580:aa40::ffff:1
・LAN-Zone のサーバ IPv6 アドレス: 3ffe:6580:aa40::2:1

route add と rule add を利用してポリシールーティングしてあげるとサクっと動作します。

最近の Linux のシステム管理者は default Gateway の設定はせず、ほとんど上記のようなポリシールーティングで設定を行い、セキュリティを強化しているようですねぇ。

 
FreeBSD の場合 ipfw の fwd では無理でした・・。僕にその知識が無いのかもしれないです・・。
なので、ファイアーウォールは ipfw だけど、ポリシールーティングの設定は pf でやるとこにしました。
以下が pf の設定です。 Server2 のは FreeBSD/amd64 10.3-RELEASE です。
/etc/pf.conf に記載します。記載したあとは service pf onestart したあとに pfctl -sa で確認できます。

pass quick on lo0  all
pass quick on vmx0 all
pass quick on em0  all
#
# NIC vmx0 -> vmx0 (IPv4)
pass out quick on vmx0 from 192.168.22.20 to 192.168.22.1/24
pass in quick on vmx0 reply-to (vmx0 192.168.22.1) from any to 192.168.22.20
pass out on vmx0 route-to vmx0 from 192.168.22.20 to any
#pass  out on vmx0 route-to (vmx0 192.168.22.1) from 192.168.22.20 to any
# NIC vmx0 -> vmx0 (IPv6)
pass out quick on vmx0 from 2001:470:fe36:beef::3:1 to 2001:470:fe36:beef::1/64
pass in quick on vmx0 reply-to (vmx0 2001:470:fe36:beef::1) from any to 2001:470:fe36:beef::3:1
#pass out on vmx0 route-to vmx0 from 2001:470:fe36:beef::3:1 to any
pass out on vmx0 route-to (vmx0 2001:470:fe36:beef::1) from 2001:470:fe36:beef::3:1 to any
#
# NIC em0 -> em0 (IPv4)
pass out quick on em0 from 192.168.1.20 to 192.168.1.1/24
pass in quick on em0 reply-to (em0 192.168.1.1) from any to 192.168.1.20
pass out on em0 route-to em0 from 192.168.1.20 to any
#pass out on em0 route-to (em0 192.168.1.1) from 192.168.1.20 to any
# NIC em0 -> em0 (IPv6)
pass out quick on em0 from 3ffe:6580:aa40::3:1 to 3ffe:6580:aa40::ffff:1/64
pass in quick on em0 reply-to (em0 3ffe:6580:aa40::/64) from any to 3ffe:6580:aa40::3:1
pass out on em0 route-to em0 from 3ffe:6580:aa40::3:1 to any
#pass out on em0 route-to (em0 3ffe:6580:aa40::ffff:1) from 3ffe:6580:aa40::3:1 to any

 
・Server-Zone の IPv4 Gateway: 192.168.22.1
・Server-Zone のサーバ IPv4 アドレス: 192.168.22.20
・Server-Zone の IPv6 Gateway: 2001:470:fe36:beef::1
・Server-Zone のサーバ IPv6 アドレス: 2001:470:fe36:beef::3:1
・LAN-Zone の IPv4 Gateway: 192.168.1.1
・LAN-Zone のサーバ IPv4 アドレス: 192.168.1.20
・LAN-Zone の IPv6 Gateway: 3ffe:6580:aa40::ffff:1
・LAN-Zone のサーバ IPv6 アドレス: 3ffe:6580:aa40::3:1

これで FreeBSD の場合は IPv4/IPv6 共にパケットが届いた NIC と出ていく NIC が一緒になるかと思います。グルっと回って反対側の NIC から出ていくことはなくなります。

僕は pf についていまいち解ってないのですが、 pass out on vmx0 route-to のオプションで (NIC Gateway) の設定があるのですが、この場合は vmx0 の 192.168.22.1 なゲートウェイアドレスに転送するよ。って設定ぽいですね。その場合、同一セグメント上の送信元、俗に言う、コネクテッドなホストには届かないんでないの? って気がするので (NIC Gateway) の記述ではなく () をはずして NIC のみを記載しています。

1).コネクテッドなホストと通信ができて、ゲートウェイの先のホストと通信ができない設定

pass out on em0 route-to em0 from 192.168.1.10 to any
pass out on em0 route-to em0 from 2405:6580:aa40::2:1 to any

 

2).ゲートウェイの先のホストと通信ができて、コネクテッドなホストと通信ができない設定

pass out on em0 route-to (em0 192.168.1.1) from 192.168.1.10 to any
pass out on em0 route-to (em0 3ffe:6580:aa40::ffff:1) from 3ffe:6580:aa40::2:1 to any

 
IPv4 の LAN-Zone なアドレスは外と通信することが無いので 1). の設定で十分な気がします。
IPv6 アドレスの場合、LAN-Zone は守りたいので 1). のほうが良いかな。

こーいうのを意識せずに、ゲートウェイの先のホストとコネクテッドなホストの両方と通信できる設定ってできるのかしら? その点 Linux は良い感じに動作していると思うんですけども。

ポリシールーティングの設定の場合、入ってきた NIC の先の Gateway に返す。ってのはウェブでまぁ、ほどほど見かけるのですが、僕から言わせてもらうと『入って来た NIC から出ていってくれてるだけで良いよ。』ってのが素直な感想なのだけど、そーは行かないのかな?

 
設定が完了したら pfctl -sa してみたり tcpdump -i vmx0 で確認してみると、パケットは入って来たポートから出ていくし、コネクテッドなホストとも無事に通信ができています。まぁ、この設定でヨシとしておきましょう。

 
あと、今回の検証のために FreeBSD の VRF の技術でもある setfib を試しましたが IPv6 が使えないのね・・。

そして、fib ごとにルーティングテーブルが個別になると思うんだけど、どうして別の fib のルーティング情報も見えるんだろう? fib はインターフェースとリンクしなくて良いのかな? 不思議だ・・。

$ setfib 0 netstat -nr -f inet
Routing tables
Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.22.1       UGS         ue0
127.0.0.1          link#1             UH          lo0
192.168.1.0/24     link#3             U         wlan0
192.168.1.33       link#3             UHS         lo0
192.168.22.0/24    link#2             U           ue0
192.168.22.33      link#2             UHS         lo0

$ setfib 1 netstat -nr -f inet
Routing tables (fib: 1)
Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.1.1        UGS       wlan0
127.0.0.1          link#1             UH          lo0
192.168.1.0/24     link#3             U         wlan0
192.168.22.0/24    link#2             U           ue0

 
(fib: 0) 側に 192.168.1.0/24 のルーティング情報が乗っていたら意味ないし、 (fib: 1) に 192.168.22.0/24 の情報があったら、ダメなような気がするんだけど・・。 ue0 から入ってきたパケットは wlan0 に抜けていってしまうと思われる・・。
setfib って、二つ (fib の数だけ) のルーティングテーブルを持つことができる。って機能ではないのかしら?

 
ルーティングテーブルがこんな具合になってくれていると多分 pf によるポリシールーティングは必要ないのではないか。と思われます。

$ setfib 0 netstat -nr -f inet
Routing tables (fib: 0)
Destination        Gateway            Flags     Netif Expire
default            192.168.22.1       UGS         ue0
127.0.0.1          link#1             UH          lo0
192.168.22.0/24    link#2             U           ue0
192.168.22.33      link#3             UHS         lo0

$ setfib 1 netstat -nr -f inet
Routing tables (fib: 1)
Destination        Gateway            Flags     Netif Expire
default            192.168.1.1        UGS       wlan0
127.0.0.1          link#1             UH          lo0
192.168.1.0/24     link#2             U         wlan0
192.168.1.33       link#3             UHS         lo0

 

7月 132017
 

systemctl ってのは Linux の新しいシステムの systemd 由来のコマンドですね(この辺りの言い回し、正しくないかも;-)。
つい最近になって CentOS7 を利用し始めたので /etc/init.d/hoge restart とかできなくなって驚いていたんですけども。

じゃぁ、/etc/init.d/ の下にあったのはどこに行ったのだ? と思い調べてみると /usr/lib/systemd/system/*.service というのがそのようですね。このファイルを利用して systemctl が start/stop をやってくれる。と、いうことのようです。

Linux のシェルは基本的に bash なので以下のファイルをダウンロードしてきて /etc/bash_completion.d/ の中に入れてあげると TAB キーで補完してくれるので幸せになれるようです。 bash 用の systemctl 補完用スクリプトですね。

https://raw.githubusercontent.com/terralinux/systemd/master/src/systemctl-bash-completion.sh

では、普段から tcsh を利用している人 (それはつまりは Linux が流行る前から UNIX をいじっていた人。と、いうことになるのかや?;-) や Linux でも tcsh をメインで利用している人はどうしたらえーねん? て、ことになるのですが、せっかくなので ~/.tcshrc に以下の設定を書いてみましょう。 (ウェブ上では多分切れているね・・orz。フル HD の全画面で表示してぇ・・。)

complete systemctl 'p/1/(start stop restart status reload enable disable kill ..etc..)/' 'n@*@`/bin/ls /usr/lib/systemd/system | grep service | sed -e "/:/d"`@'

 
tcsh には complete というコマンド(?)があるので、それで TAB の補完の設定ができます。

上記を ~/.tcshrc に書いて systemctl と打ったあと TAB を打つとまず start/stop などの文字列が表示され、その後 *.service をドドドと表示してくれることでしょう。途中の sshd.s で TAB キーを押しても補完してくれます。

これで tcsh をメインのシェルとして利用している人は幸せになれるのではないかと思われます;-)。

 
ところで、 FreeBSD の service も似たように TAB で表示したい。と、いう場合はどうするのか? 以下の設定をやはり ~/.tcshrc もしくは /root/.cshrc に書くと幸せになれます。

complete service 'n@*@`/bin/ls /etc/rc.d /usr/local/etc/rc.d | sed -e "/:/d"`@' 'p/2/(start stop restart onestart onestop onerestart)/'

 
FreeBSD の起動スクリプトは /etc/rc.d/ や /usr/local/etc/rc.d/ の中に入っているのでその中をごっそりと ls している。と、いうことになります。

bash の場合は専用のスクリプトを用意したりしますが tcsh の場合は強引に /bin/ls で実装している。と、いうことですなぁ。

 
tcsh が好きで好きで手放せない。もしくは bash なんて使ってらんねーぜ。けっ。はたまた zsh なんて遅くて使い物にならん。と、いう方は今後も多分ずっと tcsh を使い続けるかと思いますが、その場合 systemctl や service で TAB キーを使いたい方は是非お試しください;-)。
また、他のコマンドでも TAB を利用して補完したい場合には complete コマンド(?)で定義することができます。

 
2017/07/27 加筆
もう 20 年くらい tcsh 使っているけど、 tcsh を利用するときに complete な一覧が書かれているファイルがあるのね。知らなんだぁ。

o. FreeBSD の場合
/usr/share/examples/tcsh/complete.tcsh
/usr/src/contrib/tcsh/complete.tcsh

o. ubuntu の場合
/etc/complete.tcsh

これを ~/.tcshrc の中で source /usr/share/examples/tcsh/complete.tcsh とかすると色々なコマンドで TAB で補完してくれるので幸せになれます。
僕のは場合は mv cp ln など、二個目のパラメータを TAB キーで抽出できなかったので、一部変更して $HOME に置きました。

ubuntu の人が作ってくれたファイルのようです。感謝。 m(_ _)m。
加筆ここまで

5月 022017
 

ゴールデンウィークのお楽しみ用に Raspberry Pi を二個購入しました。一個は Raspberry Pi 3 Model B で、もう一個は Raspberry Pi ZERO です。二個合わせて 5,000yenちょっと出た程度。

正規代理店の 株式会社 ケイエスワイで購入しました。
5,000yen 以上だと送料無料だというので二個買ってしまった。と、いう話なんですけども。

これで Raspberry Pi は 2,3,ZERO と三つになりました。

左から RPi2 -> RPi3 (ハイレゾ音源ボード装着) -> RPi ZERO と並んでいます;-)。

Raspberry Pi 3 Model B は volumio2 で利用予定です。 オンボードの Wifi チップは FreeBSD では利用できませんが、Linux では利用できるので。ちなみに volumio2 でも利用可能です。おかげで USB な Wi-Fi が余ったので他の RPi に回せます。

今まで利用していた Raspberry Pi 2 Model B は 自宅で FreeBSD マシンとして動作させるべく FreeBSD/arm 11.0-RELEASE をインストールしました。以前このブログでもエントリを書いているのでサクっと動作します;-)。

ports のコンパイル環境も母艦側を FreeBSD/amd64 10.1-R から 11.1-R にバージョンアップして、 qemu 側も新たに FreeBSD/arm 11.0-R 用のを作成したのでコツコツと最新の ports-CURRENT を更新して行きたいと思います。

最近の FreeBSD/arm 11.0-R は pkg install が利用できるのでずいぶんと楽にはなりましたね。ただ、ちょっと古い。そんな場合は以下の URL を覗いてみてください;-)。

http://distfiles.icmpv6.org/freebsd:11:armv6:32/latest/All/

と、いうことで、今回のネタは Raspberry Pi ZERO についてです。

 
Raspberry Pi ZERO は値段が 600yen で非常に手頃な値段です。外部接続には電源供給用の MicroUSB と、USB 機器接続用の MicroUSB のポートがあります。ディスプレーは MiniHDMI ポート、これはちょっと痛かった・・。 MicroHDMI ポートだと Diginnos DG-D08IWBと互換があるので嬉しかったのですが・・。

今回は HDMI への出力を諦め、シリアルコンソールを利用しました。

そもそも RPi ZERO には GPIO ピンがなくて穴が空いているだけです。なのでシリアルコンソール用のピンをハンダで付けてあげる必要があります。

まず、ピンの手配ですが、昔利用していた PC のサウンドカードから 3 本ほど調達しました。下の写真のような感じ。

うまく固定もしたのでこれを穴の中に通します。ハンダ付けはしません。ちょっとななめにすると接触するのでハンダ付けしなくとも利用できました。

OS は FreeBSD/arm 11.0-RELEASE をチョイス。イメージは以下を利用しました。

FreeBSD-11.0-RELEASE-arm-armv6-RPI-B.img.xz

ちなみに RPi2 では以下のイメージを利用します。

FreeBSD-11.0-RELEASE-arm-armv6-RPI2.img.xz

RPI2 のイメージも RPi ZERO で試しまたがブートしませんでした。

RPI-B なイメージを MicroSD に dd し SD カードを差し込んで電源オンっ!! 無事に起動したのであります。

起動時の情報は以下になります。

dmesg
sysctl -a

僕は MIcroUSB -> USB 変換ケーブルで USB Wi-Fi や USB NIC を付けてネットワークリーチャブルにしたあとリモートからの SSH と NFS で作業を実施。環境構築が完了したのでありました。

そーそー。 RPi ZERO の ports/packages は FreeBSD/arm 11.0-RELEASE RPI2 の環境で作成したものがそのまま動作しました。 RPi2 と ZERO ではブート用イメージファイルが違うので ports/packages も違うのかな?などと思ったのですが、どちらも 32bit なバイナリで、同一のものが動作します。幸せなことです;-)。

と、いうことで特に問題もなく RPi ZERO は FreeBSD/arm が動作しました。

 
値段が 600yen で、約 5cm ほどの最小の FreeBSD 環境が整った。と、いうことですね。ゴールデンウィークの暇つぶしにピッタリなおもちゃです;-)。

4月 192016
 

Raspberry Pi 2 に Volumio をインストールしてハイレゾ楽曲を再生して楽しんでいる環境が整ったのですが、そのために Raspberry Pi 2 の 40PIN には「サインスマート HIFI DAC サウンドカード モジュール I2S インターフェース」を挿しました。これでコンソールは使えなくなるんですね。

せっかく Raspberry Pi 2 用に USB シリアルコンソールケーブルを購入しているので、これを Volumio で利用できれば嬉しいです。

IMG_3997_RPI2_Volumio_csl_1

しかし「サインスマート HIFI DAC サウンドカード モジュール I2S インターフェース」 にはピンが出っ張ってないので USB シリアルコンソールケーブルを接続することができない。

それならば。と、いうことでハンダでピンを取り付けてみました。 40PIN スロットの 6,8,10 番にピンを立てて、ここにシリアルコンソールを接続できるように改造です。電子工作だぁ。非常に簡単だけど;-)。

IMG_3990_RPI2_Volumio_csl_2

完了後はこんな感じになりました。これでサウンドカードモジュールと USB シリアルコンソールケーブルの両方が利用可能になりました。ぱちぱちぱち。

と、いうことで、早速 Volumio を起動しましょう。もう HDMI とかディスプレーとか必要ないしぃー。みたいな。まぁ、 Volumio は zeroconf が動作しているのでアクセスに関しては楽なんだけどね。

FreeBSD から以下のコマンドでシリアルコンソールを利用します。

$ cu -l /dev/cuaU0 -s 115200

 
オプションに指定する速度に注意でしょうかね。そして Raspberry Pi 2 に電源を投入するとコンソールが流れ始めます。おぉ。無事に使えるねぇ。良かった良かった。なんてのはつかの間。表示されるだけで入力できないじゃーん。 orz
Volumio はシリアルコンソールの設定が完結してないのかい?などと思い、ここから先は、起動した Volumio のシリアルコンソールを有効化していきます。

Volumio は OS に Ubuntu を利用しているので /etc/default/grub 辺りか? などと思い眺めますが x86 アーキテクチャではないのでそんなファイルは無いようです。

ふむ。

コンソールを使うなら /etc/inittab に何かしらの設定が必要だべ。とか思い眺めると『あ。多分のこの辺りを有効にすると行けそうだね。』という行が現れます。この辺りは FreeBSD とかやっていると知らない OS (『そこはかとなく、良く解らない OS』と言ったほうが良いか;-) でもなんとかなります。

# Example how to put a getty on a serial line (for a terminal)
#
#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
#T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100

 
上記の上の行をとりあえず 115200 にして設定してみした。

# Example how to put a getty on a serial line (for a terminal)
#
T0:23:respawn:/sbin/getty -L ttyS0 115200 vt100
#T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100

 
変更後は kill -HUP 1 で反映させます。間違っても kill -9 1 とかしないように;-)。 その後 ps で確認すると getty のプロセスが起動するので設定は有効になったようです。

しかし、相変わらずキーボードからの入力は受け付けてくれない状態。うむー。
多分 -L ttyS0 の部分が合っていないのだろうというのは容易に想像が付くのですが、では何を設定したら良いの? ってことになります。 Ubuntu で利用できる tty の種類は /etc/securetty の中に色々書いてあります。ただ、色々たくさん書いて有り過ぎますf(^^;;。

一応 dmesg | grep uart や dmesg | grep tty などのコマンドを打って確認。情報を色々仕入れます。あぁ。なるほどー。
dmesg | grep tty すると表示される Kernel command line: の行にどの tty を利用したら良いか書いてありますね。これを指定してみましょう。

# Example how to put a getty on a serial line (for a terminal)
#
#T0:23:respawn:/sbin/getty -L ttyS0 115200 vt100
T0:23:respawn:/sbin/getty  -L ttyAMA0 115200 vt100
#T1:23:respawn:/sbin/getty -L ttyS1   9600 vt100

 
設定完了。今度は kill -HUP 1 してもダメだったので再起動してしてみましょう。

お。コンソールに文字が表示され、おぉ。ログインプロンプトが出てきましたっ!! やった;-)。

これで Volumio でもシリアルコンソールが使えるようになりました。ハンダ当てて改造した甲斐が有りました。
今後はディスプレーも USB キーボードも必要なくなります。一件落着です;-)。

あ。最後にですが、今回利用した Volumio は 1.55 になります。

4月 092016
 

なんか、いろんな人が書いているようなタイトルだなぁf(^^;;。

本当は前回の「ハイレゾ楽曲を作ってみました。」のエントリでネタは完了する予定でしたが、プレーヤーについて色々調べていたらハイレゾ携帯プレーヤーや USB DAC を購入するより Raspberry Pi 2 でハイレゾ音源を再生するほうがずっと安上がりだ。と、いうことが解り、早速試してみました。

手元には去年購入した Raspberry Pi 2 があり今でも FreeBSD/arm CURRENT が動作していますが、そいつを利用することにしました。
Raspberry Pi 2 に接続するハイレゾ対応のチップを購入し 40PIN にサクっと刺すとハイレゾ再生が可能になる。と、いうので amazon で「サインスマート HIFI DAC サウンドカード モジュール I2S インターフェース」と、いうのを購入しました。

Raspberry Pi 2 に接続すると、こんな感じになります。

RPI2_I2S_volmio_1

購入したモノが届いたときには本体のみでマニュアルやネジ類は一切ついていません。
僕は PC を自作していた時期があったので、マザーボードと ATX ケースを固定するネジをたくさん持っていて、それを利用し I2S ボードの 40PIN の反対側に取り付けて安定性を確保しました。
そして、40PIN をグイグイと押しこみます。

以上で準備は完了です。

 
MicroSD に OS を準備しますが、今回は Volumio を利用しました。

あ。Volumio は 1.55 を利用していますが、最新版の Volumio2 が出るようです。最新版が出たらそっちに乗り換えるかもしれません。
Volumio2 RC1 を試してみたところ、僕の環境では見事にカーネルパニックしたので、今回は Volumio1.55 がターゲットです。

実は Raspberry Pi 2 を購入したあとに FreeBSD/arm と一緒に Volumio も試していたんです。このときはハイレゾに染まっていなかったのでフツーの音楽プレーヤーとして利用していたのですが、 USB の無線 LAN と Bluetooth ドングルが利用できなかったのでお蔵入りしていんですけどもね。

さてと。 Raspberry Pi 2 に I2S ボードを接続し MicroSD にも Volumio が入ったので早速起動します。

他のサイトを眺めていると System メニューの「I2S driver」と、いうメニューを “Hifiderry+” にすると音が出るよ。と、書かれていますが、それだけでは情報がかなり足りないですね。

RPI2_I2S_volmio_4

他にもう 1,2 ヶ所設定を変更する必要がありました。と、いうことで、まずは PlayBack メニューの「Audio Output」を指定します。

RPI2_I2S_volmio_3

default では “ALSA” になっていると思いますが I2S を利用する場合には “sndrpihifiberry” に変更する必要がありました。

その次にその下にある「Volume eontrol mixer」 の設定をしますが “Hardware” を指定すると、Main メニューのボリュームサークルからから音量が変更できないので “Software” を選択します。

RPI2_I2S_volmio_2

以上三つを設定すると音が出て、ボリューム調整もできるようになります。

ふぅ。最初音が出なかったので、壊れているのか? と思ってしまったのですが、これで一安心;-)。

しかし、これでも音が出ない場合には UNIX 系な解決方法を試みます(僕は FreeBSD ユーザなので『Linux 的な』とは書かないです;-)。まずは Volumio に ssh でログインして dmesg で確認してみてください。
以下の行が出力されていればデバイス的には OS から認識されていて利用可能な状態なので、じっくりと設定とかメニューを見なおしてみてください。

snd-rpi-hifiberry-dacplus sound: pcm512x-hifi <-> 3f203000.i2s mapping ok

 
このメッセージが出力されていてもなお音が出ない場合は Ubuntu のコマンドで確認してみる手もあります。
僕は Lunix のマルチメディア系のコマンドはいまいち解らないんですけどねf(^^;;。

 # aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sndrpihifiberry [snd_rpi_hifiberry_dacplus], device 0: HiFiBerry DAC+ HiFi pcm512x-hifi-0 []
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 1: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
        : (中略)
card 1: ALSA [bcm2835 ALSA], device 1: bcm2835 ALSA [bcm2835 IEC958/HDMI]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
# lsmod | grep pcm
snd_soc_pcm512x_i2c     1689  1 
snd_soc_pcm512x         6340  1 snd_soc_pcm512x_i2c
snd_soc_core          140253  4 snd_soc_pcm512x,snd_soc_hifiberry_dac,snd_soc_hifiberry_dacplus,snd_soc_bcm2708_i2s
snd_pcm_dmaengine       3359  1 snd_soc_core
regmap_i2c              2354  1 snd_soc_pcm512x_i2c
        : (以下略)

 
Volumio では Network メニューから Wi-Fi の設定もできるのですが、僕の持っている USB Wi-Fi インターフェースでは設定してもまともに動きませんでした。なので、こちらも実機に ssh して wpa_supplicant の設定を直接手でしてしまいました。基本的に wpa_supplicant は Linux も FreeBSD も一緒なので使い回しの設定で OK でした;-)。

ネットワークの設定は結局 Volumio からではなく /etc/network/interfaces を直接 vi で編集してしまいました;-)。

あと、 I2S インターフェースを付けたのでオンボードのサウンドチップは要らないので削除します。 /etc/modules の中に書かれている snd_bcm2835 の行をコメントアウトすれば OK です。とは言っても /etc/modules には snd_bcm2835 しか書かれていないと思いますけども。

音楽系の話だけでなく、こーいう、UNIX 系技術者向けな話も中々良いですね;-)。

 
さてと。話をもとにもどします;-)。

今回購入した「サインスマート HIFI DAC サウンドカード モジュール I2S インターフェース」と、いう製品は PCM5122 というチップで 384kHz/32bit に対応しているそうで、もうバッチリとハイレゾ対応ですね;-)。

ここにヘッドホンを接続したりスピーカーを接続して mora の楽曲を再生してみました。

最近は通勤の往復の電車の中では ZTE Blade Vec 4G にイヤホンを利用して音を聞いているのですが、その時には 256bit/44.1KHz/16bit な m4a も mora のハイレゾ楽曲も聞きます。なので耳には慣れている音なのですが、このモジュールを利用して音を試聴すると、音質豊かで驚きます。

『人間の耳は 20kHz 以上は聞こえないんだからハイレゾは意味ねんじゃね?』とか言われていますが、聞こえる周波数・聞こえない周波数なんて関係無いですね。耳に入ってくる情報量がうんと多いのには唖然とします。ボーカルのうしろにはこんなに色々な音が隠れていたのかーっ!! って、音が耳に飛び込んでくる感じ。

ハイレゾな楽曲をハイレゾな環境で聞くとすごい音がする。ってことがよぉーく解りました。

 
それにしても Raspberry Pi 2 ってすげーなー。とか、思うんですが、結局のところ、行き着くところは Linux で PCM5122 のチップのドライバが書かれていて、ちゃんと音が出る。ってのがすごいねぇ。などと思えるんですけどもね。
FreeBSD では PCM5122 のデバイスドライバは無いようだしなぁ・・。

と、いうことで Raspberry Pi 2 + PCM5122 + Volumio でハイレゾ再生が可能になり、楽曲(五曲しかないけど、更に二曲追加されました;-)とプレーヤーとスピーカー・イヤホンの全てが揃いました。

CD から flac にリッピングする環境もできたのでハイレゾ環境はこれで一通り揃った感じになります。ただ、 CD -> wav -> flac 変換の楽曲が “なんちゃってハイレゾ” 以下の楽曲データであるとは多分思うのですけどね・・:-|。

さてと。これからは、楽曲をどうして行くか? と、いう点のみが残るな・・。やはり泥沼からは抜け出せないかな? orz

 
ちなみに、今回のハイレゾ環境整えるのにかかった費用ですが、今のところはイヤホン・スピーカー・I2S インターフェースのみなので 23,000yen 弱でしょうかね。 Raspberry Pi 2 は最初から持っていたのでカウントされていません。

これだけの金額でハイレゾ環境が整って一安心。と、いうのが素直な気持ちですが、自分的には

ハイレゾを楽しむならまずはイヤホン・その次にスピーカ、楽曲は色々試して、最後にプレーヤーを揃える

って感じかなぁ。と、思っております。最初にプレーヤーを買っても、ハイレゾで音が聞こえないので。最初にイヤホン買うと Windows10 で試せるし。みたいな感じでしょうか。

 
と、いうことで、今回のハイレゾに関するエントリは全て終了です;-)。

ふぅ。

 

6月 192014
 

GNOME 方面の人にはまるで興味が無いとは思うのですが、 KDE というか Qt を利用している人にとっては、ご存知な方もいるのではないかなぁ?

世の中には超軽量ブラウザというのが存在しています。 rekonq も konqueror に比べると軽量かなぁ。arora も軽量ですね。 rekonq よりも軽量なのが QtWeb というブラウザです。 arora と同じくらい軽量かなぁ。

以下が QtWeb のサイトですね。

http://qtweb.net/

ここを見ると Windows・OS X・Linux と世界の三大ウィンドを制覇しているんですけどもね;-)。で、それぞれバイナリがあるのですが、ソースコードもあるので、それを FreeBSD に持ってきてコンパイルすると FreeBSD 上でも動作するんですけども。

キャプチャはこんな感じです。

Qtweb_1

で、せっかくなので今回は QtWeb の ports を作ってみました。 arora が ports になっているのに QtWeb が ports になってないのは悲しいことですし;-)。
以下の URL にあるのでもしも「僕も私もちょっと FreeBSD 上で QtWeb を使ってみようかなぁ。」などと思った人は試してみてください。

http://icmpv6.org/Prog/FreeBSD_ports/ports-qtweb-20140619.tgz

あ。コミットするつもりはありません。あくまでノラ ports ということで;-)。

QtWeb の ports の仕様やインストール方法などをちょっと書いてみます。

o. QtWeb をコンパイルするには Qt 4.8.6 のソースコードが必要
FreeBSD の ports 的には qt4-* で色々インストールされているのですが、 QtWeb は Qt ライブラリを static link するので FreeBSD の ports 的な Qt ライブラリは必要としません。
GNOME や xfce4 な人も Qt や KDE のコンポーネントをインストールすることなく Qt コテコテなブラウザを楽しむことがてできます。

しかし、裏を返すと Qt ライブラリ部分もコンパイルするのでコンパイル時間が随分と長いです。orz

僕が作成した ports では /usr/ports/distfiles/KDE/ に Qt 4.8.6 のソースがあればそれを利用し、なければとある日本のサイトからダウンロードしてきます。詳細は files/patch-qt-src.sh を見てください。

o. ports がインストールするもの
QtWeb のサイトからバイナリをダウンロードすると、本当に QtWeb 本体のみしかパッケージングされてないのですが、僕の作った ports では QtWeb バイナリの他に icon として QtWeb.png と QtWeb.desktop をインストールするようにしています。インストール直後から KDE のインターネットメニューに表示されるようにしました。

o. QtWeb の起動
ports からインストールすると /usr/local/bin/QtWeb ができるのでそれを実行するのですが、実行後にできるディレクトリが美しくないです。以下の三つのディレクトリができます。

・$HOME/.QtWeb Internet Browser/
・QtWebCache/
・QtWebSettings/

一番上の .QtWeb Internet Browser/ は $HOME にできるので良いのですが、 QtWebCache/ と QtWebSettings/ はどこにできるかわかりません。実行したときにいるカレントディレクトリにできたりとか、ヘタするとあちこちに QtWebCache/ と QtWebSettings/ ができてしまうような感じです。orz
なお、メニューから QtWeb の設定を変更するとその内容は QtWebSettings/ に保存されます。

が、しかし、それにしてもこの二つのファイルはどこにできるのか解らない・・。orz
ソースコードを書き換えてやろうかと思ったほどですが・・。
なのでしょうがない。起動用にスクリプトを一個書きました。

#!/bin/sh

cd $HOME/.QtWeb\ Internet\ Browser
QtWeb > /dev/null 2>&1
#/usr/local/bin/QtWeb > /dev/null 2>&1
#cd  $HOME

 
$HOME/.QtWeb Internet Browser/ 配下に QtWebCache/ と QtWebSettings/ が作成されるようにするためのスクリプトです。
不便やのぉ・・。って感じなのですが、ソースコード的には browserapplication.cpp の数カ所を直せばちゃんとコントロールできるんじゃね? って感じはします。

 
こんな感じの QtWeb というブラウザなのですが、もしよければ皆さんもコンパイルして使ってみてください;-)。

 
あ。最後にですが、 Qt-Webkit は x-sjis と x-euc-jp には対応してないので文字化けします。 rekonq も konqueror も Qt-WebKit を利用しているのでやはり x-* な文字コードは表示できません。最近は少なくなってきましたが、今では僕が知っている有名ドコロは VECTOR が x-sjis を利用しているので表示できません。

この件については以前 KDE 方面で(その昔は) Nokia の Qt のコードを書いている人に聞いたことがあるのですが、非対応だそうです。するっていと同じ KHTML から派生の Apple-WebKit は独自に x-* な文字コードに対応した。と、いうことなのでしょうなぁ。

 
PC に色々ブラウザが入っていると楽しいですよ;-)。 是非、試してみてください。;-)

5月 242012
 

最近というか、かなり前から秋葉原の色々なショップでジャンク扱いで販売している PLANEX の MZK-W300NH2 という BB ルータがあります。

今回はこれが 500yen で売っていたので買って来ました。実は一年くらい前に 1,000yen で一個購入しているので今回が二個目の購入。ということになります。

個人的には二個目のヤツに OpenWRT をインストールして、その上で OpenFLOW などを動かしてみようかなぁ。などと思った次第です。

で、今回はその手順を見ていくことにしましょう。とは言いつつも一回では到底終わりそうにないので多分数回に分けて書いていくことになります;-)。

まず、 MZK-W300NH2 で OpenWRT が動作するか確認する必要があります。 OpenWRT のサポートしている機器の一覧を確認します。ふむ。 MZK-W300NH2 はリストアップされていませんね。と、いうことで MZK-W300NH2 の機器の情報を取得します。

・アーキテクチャは ramips
・CPU は RT3052
・FLASH は 4MB

これだけ解れば大丈夫か。似たような機器としては Allnet の ALL0239-3G などが掲載されているのでトライです。以下の URL からそれらしいファームを拾ってきます。

http://downloads.openwrt.org/snapshots/trunk/ramips/

で、ウェブインターフェースからファームウェアを更新しようとするんですが、チェックではじかれますね。アタタタタ。と、いうことでしゅーりょー。orz。

何か手段は無いものか? などと調べていたら MZK-W300NH2 にはマザーボード上にシリアルのコネクタというか、結線できるものはあるようですね。ウェブで調べてみると以下のようです。右から順に以下のようになっています。

・3.3V
・TXD
・GND
・RXD

では、ここに RS232C のチップと D-SUB 9pin オスを付けてしまいましょう。こんな感じになりました;-)。写真を 2,3 枚。

こっちがアップの図。

IMG_2318_mzk-w300nh2_1.jpg

でもって、こっちが D-SUB 9pin がニョキっと生えた図。

IMG_2304_mzk-w300nh2_2.jpg

今回利用したチップは ADM3202 です。ただし、僕が付けられるわけもなく、会社の同僚で仕事が電子工作という人に付けてもらいましたf(^^;;。ありがとうございました。

さてと。今回の話はようやっとここから;-)。シリアルコンソールが付くと、もう何でもできるような気分になります。まずは電源投入してプロンプトなどを表示してみます。

U-Boot 1.1.3 (Nov 25 2008 - 16:46:30)
Board: Ralink APSoC DRAM: 16 MB relocate_code Pointer at: 80fa8000
Please choose the operation: 0: Load ucos code to SDRAM via TFTP Client. 1: Load system code to SDRAM via TFTP. 2: Load system code then write to Flash via TFTP. 3: Boot system code via Flash (default). 4: Entr boot command line interface. 9: Load Boot Loader code then write to Flash via TFTP.

 
最初にメニューが出力され選択できるようになっています。メニュー画面の表示時間は一秒なので二秒後には 3: が動作し BB ルータとしての OS が起動してしまいます。なので、電源投入後はすかさず 4 を押します。

するとコマンドプロンプトが出てきます。

RT3052 # ?
?       - alias for 'help'
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootm   - boot application image from memory
bootp   - boot image via network using BootP/TFTP protocol
cp      - memory copy
echo    - echo args to console
erase   - erase FLASH memory
help    - print online help
loopback   - Ralink eth loopback test !!
md      - memory display
mdio   - Ralink PHY register R/W command !!
mm      - memory modify (auto-incrementing)
mw      - memory write (fill)
nm      - memory modify (constant address)
printenv- print environment variables
protect - enable or disable FLASH write protection
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
spicmd  - read/write data from/to eeprom or vtss
tftpboot- boot image via network using TFTP protocol
version - print monitor version

 
なるほど。こんなコマンドがサポートされているのね。で、プロンプトから操作するときのの情報を知るには printenv コマンドを実行します。

RT3052 # printenv
bootcmd=tftp
bootdelay=2
baudrate=57600
ethaddr="00:AA:BB:CC:DD:10"
ipaddr=10.10.10.123
serverip=10.10.10.3
preboot=echo;echo
ramargs=setenv bootargs root=/dev/ram rw
addip=setenv bootargs $(bootargs) ip=$(ipaddr):$(serverip):\
$(gatewayip):$(netmask):$(hostname):$(netdev):off
addmisc=setenv bootargs $(bootargs) console=ttyS0,$(baudrate)\
ethaddr=$(ethaddr) panic=1
flash_self=run ramargs addip addmisc;bootm $(kernel_addr)¥
$(ramdisk_addr)
kernel_addr=BFC40000
u-boot=u-boot.bin
load=tftp 8A100000 $(u-boot)
u_b=protect off 1:0-1;era 1:0-1;cp.b 8A100000 BC400000¥
$(filesize)
loadfs=tftp 8A100000 root.cramfs
u_fs=era bc540000 bc83ffff;cp.b 8A100000 BC540000 $(filesize)
test_tftp=tftp 8A100000 root.cramfs;run test_tftp
stdin=serial
stdout=serial
stderr=serial
ethact=Eth0 (10/100-M)
Environment size: 783/65532 bytes RT3052 #

 
なるほど。tftp の設定とか、FLASH の扱い方とか設定できますね。ウェブインターフェースでイリーガルなファームウェアを更新するとガードがかかってできませんが、 tftp サーバから持ってきてブートするともしかしたら OpenWRT がブートするかもしれないですね。

と、いうことで第一回目は終了です;-)。 MZK-W300NH2 にシリアルポート付けたぜーっ。ってのが第一回目だったりします。それにしても RS232C のチップ埋め込んでハンダ当てて色々やるのは随分と敷居が高いですよね。

で、こーいうのを見つけました。

UART(3.3V)-RS232C変換モジュール内蔵コネクタケーブル

D-SUB 9pin コネクタの中に RS232C チップが最初から埋め込まれていて、伸びたケーブルをマザーボードの ピンに何らかの手段で接続すれば良いだけ。と、いう非常に簡単なモノです。ただ、これをどうやってマザーボードに固定もしくは接触させるかを考える必要はあるかと思いますけどね。

それにしてもシリアルコンソールがあるといきなりワクワクしてしまいますね。後は tftp サーバからファームウェアをダウンロードしてブートできれは良いだけになりました。とは言いつつ、ファームウェアを作らなければならないわけでして。それについては上にも書きましたが次回以降で;-)。

次回 があるか分かりませんがf(^^;;。