ping, dhcp

『サイン・署名のつくり方』(スモール出版)なんて本を読んだ。

別にオイラーが、ピコ太郎みたいに中年アイドルを目指して、マイサインを持とうと思った訳ではない。単に面白そうだったから。

日本は今まで印鑑が中心。（殿様は、花押と言うサインを持ってたけど）それが近頃はサインも勢力を伸ばしているとか。宅配便の受け取りは、大体サインでOKになったし、クレジットカードは元々サインだったし。頑なに印鑑文化を守っているのは、お役所と銀行の類ですかね。

著者は、印鑑なんて盗まれたら、それで終わりじゃん。それに対しサインは、本人の筆致が他人に真似るのが極めて難しいとの事。そう言えば、サイン認証なんてのも有ったような無かったような。。。どうでっしゃろか？インターフェースの街角の人。

署名は、アルファベットにするか漢字にするか？日本名をアルファベットにすると長くなるので、名を１文字にしちゃうとかの工夫が必要。そうしないと書くのにえらく苦労してしまい、サインの利便性がが落ちる。

ならば漢字か、氏名は、平均して４文字ぐらいらしい。でも、漢字は画数が多いものもありからなあ。一一こういう氏名の人っているのかしら。いちはじめさん。これなら、２画だけど、逆に、サインをデザインするのは難しい？

こういう時は、連想を働かせて、新しいイメージを作るのだそうだ。サインは氏名が基本だけど、そうしなければならない決まりがあるわけではない。あくまで、本人を同定するシンボルなんだから。

画数を減らす為の第一歩は、草書体の省略方法を参考にするのが定番らしい。

Font Grage

あとは、それをデザインしていく。サインはアートだとも言うらしい。いよいよ困ったら

署名ドットコム

こちらにご相談。サインを練習するには、万年筆が良いらしい。ボールペンだと滑り過ぎて、難しいそうだ。

matzさんのサイン。どれぐらい練習されたんだろう？家にサイン本が６冊も有ったぞ。

問題提起

前からやってるOpenBSDの中に仮想PCを作って、そこにOpenBSDを入れるやつ。どうしてもネットワークインストールが前提になる。その為の足場作りで、NICに IPアドレスを振る必要がある。普通はdhcpサーバーからIPを貰ってくるんだけど、それが下記のように失敗するんだ。失敗するんで、ふて寝という暴挙ですよ。

Available network interfaces are: vio0 vlan0.
Which network interface do you wish to configure? (or 'done') [vio0]
IPv4 address for vio0? (or 'dhcp' or 'none') [dhcp]
DHCPDISCOVER on vio0 - interval 1
DHCPDISCOVER on vio0 - interval 1
DHCPDISCOVER on vio0 - interval 1
DHCPDISCOVER on vio0 - interval 1
DHCPDISCOVER on vio0 - interval 1
No acceptable DHCPOFFERS received.
No working leases in persistent database - sleeping.

そこで、手動でIPを振る。 VMware Player の NAT ネットワークを極めるを見ながら、DHCPサーバーの管理外のアドレス、xxx.xxx.xxx.100/24 を振ってあげた。そして、親機にピン。

# ping -i 1 xxx.xxx.xxx.130
PING xxx.xxx.xxx.130 (xxx.xxx.xxx.130): 56 data bytes
64 bytes from xxx.xxx.xxx.130: icmp_seq=1 ttl=255 time=436.899 ms
64 bytes from xxx.xxx.xxx.130: icmp_seq=2 ttl=255 time=1573.782 ms
  :
64 bytes from xxx.xxx.xxx.130: icmp_seq=9 ttl=255 time=819.243 ms
64 bytes from xxx.xxx.xxx.130: icmp_seq=10 ttl=255 time=1031.985 ms
--- xxx.xxx.xxx.130 ping statistics ---
12 packets transmitted, 10 packets received, 16.7% packet loss
round-trip min/avg/max/std-dev = 187.726/1104.959/2231.708/703.837 ms

パケットが何処かをさ迷っているみたいだ。親機のHUBポートの所で、パケットをモニターしてみる。

bash-4.3# tcpdump -i bridge0 icmp
tcpdump: listening on bridge0, link-type EN10MB
15:51:19.133379 xxx.xxx.xxx.100 > xxx.xxx.xxx.130: icmp: echo request
15:51:19.133403 xxx.xxx.xxx.130 > xxx.xxx.xxx.100: icmp: echo reply
  :
15:52:49.977165 xxx.xxx.xxx.100 > xxx.xxx.xxx.130: icmp: echo request
15:52:49.977187 xxx.xxx.xxx.130 > xxx.xxx.xxx.100: icmp: echo reply

親機は、要求が来れば、速やかに返答してる。でも、リクエストの間隔が随分とばらついているな。仮想PCの計時機能が壊れているの？初期時刻は、CMOS時計から得るけど、一旦カーネルが動き出せば、OSが管理するタイマー類で時間管理が行われるはず。どうも解せないな。

軽くpingのコードを眺めておく。iオプションで指定される時間間隔でpingする。それに対するpongの時間を測っているのだな。ピンポンとは書いてないので、コードした人は、卓球を知らない人だな。

pingerがパケットの送出ルーチン。現在時刻を埋め込んでいる。そして、 pr_packが受信した結果を表示するルーチン。

受信したサイズやらシーケンス番号とか、送出時刻を取り出し、現在時刻からの差を取って、パケットが往復するにかかった時間を表示してる。

パケットの最大待ち時間は、デフォで10秒に設定されてた。いやー、コードを読むと色々な事が分かって楽しいな。例えば、洪水を発生させるとか。これをやるには、巨大な権力が必要。権力者は迷惑な存在ですよ。

これ以上深入りも出来そうも無いので、dhcpのおさらいでもして、お茶を濁してみるかな。

オイラーのつたない記憶では、IPをプールしてるDHCPサーバーからIPをリースするのが dhclientの役目。

最初は、IPが振られていないので、普通の通信は出来ない。そこで、パケットに自分のMACアドレスを入れて、誰がDHCPサーバーさん？答えて頂戴とやるはずだったな。それから先の事は、すっかり失念してる。再勉強するか。

図解で学ぶネットワークの基礎

DHCPプロトコル

DHCP を深く知る

使う道具も復習しておく。

tcpdumpコマンドで覚えておきたい使い方4個

tcpdump コマンドの使いかたをまとめてみた

dhcpサーバーとのやり取りを盗みみる

早い話が、盗聴ですな。

先ずは、dhcpサーバーとのやり取りがどんな風に行われるか、同一サブネットに属する別のマシン（アドレス自動取得）を起動して調べてみる事にした。

tcpdumpでモニターしつつ、別マシンを起動。起動したら、パケットのやり取りは終了してるはずなんで、CTRL-Cでtcpdumpを停止する。

bash-4.3# tcpdump -s 1024 -w LOGether
tcpdump: listening on em0, link-type EN10MB
^C
166 packets received by filter
0 packets dropped by kernel

余計なパケットも拾っているので、DHCPに属するパケットだけフィルターしよう。そのパケットはどういう名前で呼ばれているのかな？

bash-4.3# grep dhcp /etc/services
dhcpv6-client   546/udp                         # DHCPv6 client
dhcpv6-server   547/udp                         # DHCPv6 server
dhcpd-sync      8067/udp                        # dhcpd(8) synchronisation
bash-4.3# grep boot /etc/services
bootps          67/tcp                          # BOOTP server
bootps          67/udp
bootpc          68/tcp                          # BOOTP client
bootpc          68/udp

IPv4とIPv6では違うポートを使うのね。そんなの知らなかったぞ。

bash-4.3# tcpdump -r LOGether | grep boot
tcpdump: WARNING: snaplen raised from 116 to 1024
05:07:36.926080 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x5bdebc25 vend-rfc1048 DHCP:DISCOVER RQ:xxx.xxx.xxx.128 PR:SM+BR+TZ+121+DN+NS+HN+YD+YS+NTP+MTU+119+DG+121+249+SR+252+NTP CID:255.41.31.148.26.0.4.115.102.88.86.179.253.77.49.133.155.191.12.106.119.48.111 [tos 0x10]
05:07:37.930022 xxx.xxx.xxx.254.bootps > xxx.xxx.xxx.128.bootpc: xid:0x5bdebc25 Y:xxx.xxx.xxx.128 S:xxx.xxx.xxx.254 vend-rfc1048 DHCP:OFFER SID:xxx.xxx.xxx.254 LT:1800 SM:255.255.255.0 BR:xxx.xxx.xxx.255 DN:"localdomain" NS:xxx.xxx.xxx.2 DG:xxx.xxx.xxx.2 [tos 0x10]
05:07:37.934095 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x5bdebc25 vend-rfc1048 DHCP:REQUEST SID:xxx.xxx.xxx.254 RQ:xxx.xxx.xxx.128 PR:SM+BR+TZ+121+DN+NS+HN+YD+YS+NTP+MTU+119+DG+121+249+SR+252+NTP CID:255.41.31.148.26.0.4.115.102.88.86.179.253.77.49.133.155.191.12.106.119.48.111 [tos 0x10]
05:07:37.934866 xxx.xxx.xxx.254.bootps > xxx.xxx.xxx.128.bootpc: xid:0x5bdebc25 Y:xxx.xxx.xxx.128 S:xxx.xxx.xxx.254 vend-rfc1048 DHCP:ACK SID:xxx.xxx.xxx.254 LT:1800 SM:255.255.255.0 BR:xxx.xxx.xxx.255 DN:"localdomain" NS:xxx.xxx.xxx.2 DG:xxx.xxx.xxx.2 [tos 0x10]

どうやら４パケットやり取りされてるようだけど、何の事やら？こういう時はGUIなツールの出番だろう。Wiresharkを入れたら、Qtの関係者までごっそり付いて来て、げんなりしましたよ。毎度々、GUIは舞台設定が大変ですなあ。

# wireshark LOGether

毎度、あちこち押す所が有って悩むんだけど、どうやらパケットの表示のすぐ右上に有る、矢印の右側のExpressionを押して、パケットを絞りこむようだ。押すと、フィールドネームがわんさか出てくるので、下のSearchからbootとでも入れると、 BOOTP/DHCPが出てくるので選ぶ。OKを押すと、bootpが緑色の背景で検索窓に表示される。背景が赤とかだと、お前アホかって事なんだろうな。

続いて、右矢印を押すと、grep相当が実行されて、パケットが絞り込まれる。おお、パケットの意味論を分かりやすく図解してくれたぞ。

大まかには、Discoverして、Offerがなされる。それに対するRequestが発しられてサーバーからACKを受けて、完了とな。

で、本番。仮想PC側からリクエストが行くんだけど、それが親hostからも発せられてる。オファーパケットが返ってくるんだけど、それを親が横取りして破棄しちゃうんだろうな。だから仮想PCにはいつまで経っても、オファーパケットが届かないという事になるんだな。

親が余計な事をしないようにしないと、いつまでたってもこの問題は解決しないわな。こういうのは、パケットを眺めてみなと分からん。測定器重要。

13:42:13.717265 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xbb8bbb0d vend-rfc1048 DHCP:DISCOVER HN:"vm" PR:SM+BR+TZ+121+DG+DN+119+NS+HN CID:1.254.225.186.208.230.35 [tos 0x10]
13:42:13.717348 xxx.xxx.xxx.130.56945 > 255.255.255.255.bootps: (request) xid:0xbb8bbb0d vend-rfc1048 DHCP:DISCOVER HN:"vm" PR:SM+BR+TZ+121+DG+DN+119+NS+HN CID:1.254.225.186.208.230.35 [tos 0x10]
13:42:14.719270 xxx.xxx.xxx.254.bootps > xxx.xxx.xxx.144.bootpc: xid:0xbb8bbb0d Y:xxx.xxx.xxx.144 S:xxx.xxx.xxx.254 vend-rfc1048 DHCP:OFFER SID:xxx.xxx.xxx.254 LT:1800 SM:255.255.255.0 BR:xxx.xxx.xxx.255 DG:xxx.xxx.xxx.2 DN:"localdomain" NS:xxx.xxx.xxx.2 [tos 0x10]

Where is dhcp server

ふと気になって、dhcpなサーバーってどうやって探し出すか調べてみた。 dhcp-discover 本家にスクリプトが置いてあったぞ。でも、出来心なんで、そんな高級なものでなくても良い。簡易的には、下記のようにするみたい。

味噌は、UDPで探せですね。

[sakae@fb11 ~]$ sudo nmap -sU xxx.xxx.xxx.0-254 -p 67-68

Starting Nmap 7.31 ( https://nmap.org )
Nmap scan report for xxx.xxx.xxx.1
Host is up (-0.17s latency).
PORT   STATE         SERVICE
67/udp open|filtered dhcps
68/udp open|filtered dhcpc
MAC Address: 00:50:56:11:22:33 (VMware)

Nmap scan report for xxx.xxx.xxx.2
Host is up (0.00013s latency).
PORT   STATE         SERVICE
67/udp open|filtered dhcps
68/udp open|filtered dhcpc
MAC Address: 00:50:56:AA:BB:CC (VMware)

Nmap scan report for xxx.xxx.xxx.254
Host is up (0.00017s latency).
PORT   STATE         SERVICE
67/udp open|filtered dhcps
68/udp open|filtered dhcpc
MAC Address: 00:50:56:F6:4C:E0 (VMware)

Nmap scan report for xxx.xxx.xxx.131
Host is up (0.00027s latency).
PORT   STATE  SERVICE
67/udp closed dhcps
68/udp closed dhcpc

Nmap done: 255 IP addresses (4 hosts up) scanned in 9.46 seconds

VMWAREって、こんなにサーバーをちりばめているのか。びっくりしましただ。

大きな問題

それより、決定的に重要な事項が見つかった。親側から仮想PCにピンすると

bash-4.3# ping xxx.xxx.xxx.100
PING xxx.xxx.xxx.100 (xxx.xxx.xxx.100): 56 data bytes
ping: sendto: Host is down
ping: wrote xxx.xxx.xxx.100 64 chars, ret=-1
ping: sendto: Host is down
ping: wrote xxx.xxx.xxx.100 64 chars, ret=-1
ping: sendto: Host is down
ping: wrote xxx.xxx.xxx.100 64 chars, ret=-1
ping: sendto: Host is down
ping: wrote xxx.xxx.xxx.100 64 chars, ret=-1
--- xxx.xxx.xxx.100 ping statistics ---
10 packets transmitted, 0 packets received, 100.0% packet loss

まさかの一方通行状態です。pingって両方から実施して導通確認するのが大事だな。そんなの常識、昔テスターで盛んににやっただろう。もう忘れているのか。

with NAT

どうも、NICを２枚刺ししてNATするのが正解みたい。前例に倣ってやってみた。

けど、サーバーへファイルを取りに行ったきり、応答が無くなる。しょうがないので、shellに落ちて、ftpしてみた。

230-              *** JAIST Public Mirror Service ***
230-
230-  Welcome to JAIST Public Mirror Service (ftp.jaist.ac.jp).
230-
 :
250 Directory successfully changed.
Retrieving pub/OpenBSD/6.0/amd64/bsd
local: bsd remote: bsd
150 Opening BINARY mode data connection for bsd (10504752 bytes).
uid 0 on /: file system full

/: write failed, file system is full
ftp: local: bsd: No space left on device
500 OOPS: setsockopt: linger
416908 bytes received in 0.08 seconds (4.90 MB/s)

書き込むべき場所が無いので、エラーにはなるけど、ftpはちゃんと行われている事が判明。

NATはパケットフィルターで実現されているので、変換具合をモニターしてみた。

bash-4.3# pfctl -s state
all tcp xxx.xxx.xxx.130:29294 <- xxx.xxx.xxx.1:50977       ESTABLISHED:ESTABLISHED
all udp xxx.xxx.xxx.2:53 <- 10.0.0.2:44369       SINGLE:MULTIPLE
all udp xxx.xxx.xxx.130:55794 (10.0.0.2:44369) -> xxx.xxx.xxx.2:53       MULTIPLE:SINGLE
all tcp 150.65.7.130:21 <- 10.0.0.2:41014       FIN_WAIT_2:FIN_WAIT_2
all tcp xxx.xxx.xxx.130:51037 (10.0.0.2:41014) -> 150.65.7.130:21       FIN_WAIT_2:FIN_WAIT_2
all tcp 150.65.7.130:50392 <- 10.0.0.2:11990       TIME_WAIT:TIME_WAIT
all tcp xxx.xxx.xxx.130:50464 (10.0.0.2:11990) -> 150.65.7.130:50392       TIME_WAIT:TIME_WAIT

etc

openbsd　で　ｄｈｃｐｄ　＋　firewall

vether(4) use case

PF: OpenBSD パケットフィルタ

OpenBSD の PF でフィルタリングや NAPT, ポートフォワーディング