Yasuoka's hack log (2018年)

2018-11-29: ダメな画像を、拙作 gyazo コマンド でまちがって upload してしまい、困ったので削除方法を考えた。

• https://github.com/yasuoka/gyazo/commit/9b448f6683c6eb8ea951037f641347ac4cfca334 で commit したように、セッショントークンを要求して、トークン付きでブラウザからアクセスすると、gyazo アカウントを作成して(既存のアカウントでもよい)、削除できるようになる。この操作で、~/.gyazo.id に保管された ID によって過去 upload したすべての画像が削除できる。(ただし、無料アカウントでは最新 10 個までに限定されている)

2018-11-23: vaio でカメラ動いたら便利だなと思って調べたが、前にも同じこと調べてた ようだ。しかも間違いがあったので訂正しておいた。USB の isochronous 転送の問題にあたってる。

2018-11-21: OpenBSD 6.4 amd64 用の chromium 70.0.3538.102 (野良ビルド) (2019-02-15 追記 古いので削除) 欲しい人いるかわかりませんが、ご自由にどうぞ

2018-11-19: ポートスキャンの件 もう来てた

Nov 15 15:35:41.472149 210.150.186.238.41626 > XXX.XXX.XXX.XXX.23: S 493133544:493133544(0) win 1024
Nov 15 15:35:41.472197 XXX.XXX.XXX.XXX.23 > 210.150.186.238.41626: R 0:0(0) ack 493133545 win 0 (DF)
Nov 15 15:35:41.488071 210.150.186.238.41626 > XXX.XXX.XXX.XXX.23: R 493133545:493133545(0) win 1200
Nov 16 01:35:53.603696 210.150.186.238.41626 > XXX.XXX.XXX.XXX.80: S 4291496132:4291496132(0) win 1024
Nov 16 01:35:53.603741 XXX.XXX.XXX.XXX.80 > 210.150.186.238.41626: R 0:0(0) ack 4291496133 win 0 (DF)
Nov 16 01:35:53.612259 210.150.186.238.41626 > XXX.XXX.XXX.XXX.80: R 4291496133:4291496133(0) win 1200
Nov 16 17:37:52.903438 210.150.186.238.46937 > XXX.XXX.XXX.XXX.23: S 3059455296:3059455296(0) win 1024
Nov 16 17:37:52.903484 XXX.XXX.XXX.XXX.23 > 210.150.186.238.46937: R 0:0(0) ack 3059455297 win 0 (DF)
Nov 16 17:37:52.918668 210.150.186.238.46937 > XXX.XXX.XXX.XXX.23: R 3059455297:3059455297(0) win 1200
Nov 16 18:51:41.583636 210.150.186.238.46885 > XXX.XXX.XXX.XXX.22: S 2105035420:2105035420(0) win 1024
Nov 16 18:51:41.583726 XXX.XXX.XXX.XXX.22 > 210.150.186.238.46885: S 2790708022:2790708022(0) ack 2105035421 win 16384 <mss 1414> (DF)
Nov 16 18:51:41.594741 210.150.186.238.46885 > XXX.XXX.XXX.XXX.22: R 2105035421:2105035421(0) win 1200
Nov 16 20:12:14.042106 210.150.186.238.46973 > XXX.XXX.XXX.XXX.80: S 3548182661:3548182661(0) win 1024
Nov 16 20:12:14.042152 XXX.XXX.XXX.XXX.80 > 210.150.186.238.46973: R 0:0(0) ack 3548182662 win 0 (DF)
Nov 16 20:12:14.067488 210.150.186.238.46973 > XXX.XXX.XXX.XXX.80: R 3548182662:3548182662(0) win 1200
Nov 19 14:04:06.839655 210.150.186.238.42093 > XXX.XXX.XXX.XXX.80: S 91926052:91926052(0) win 1024
Nov 19 14:04:06.839711 XXX.XXX.XXX.XXX.80 > 210.150.186.238.42093: R 0:0(0) ack 91926053 win 0 (DF)
Nov 19 14:04:06.850428 210.150.186.238.42093 > XXX.XXX.XXX.XXX.80: R 91926053:91926053(0) win 1200

2018-11-19: pdf -> png の変換で、背景が透明になってしまうのを避けるのは -flatten オプション

2018-11-13: 行政がポートスキャンするらしい ので、tcpdump 仕込んでみた

2018-11-13: Pyhton の list と tuple の違い、https://stackoverflow.com/questions/1708510/python-list-vs-tuple-when-to-use-each

2018-11-12: guess コマンドを足してみた

• mailest の機能として、Reference ヘッダ等とがないメッセージの親メッセージを推測する機能 guess-parid があるが、 親メッセージが index される前に推測しようとしたものは当然失敗し、 その後親が index されても救われない、という問題があった。 guess コマンドはそのようなメッセージを再度推測しなおすことで、 (今度は親を見つけられるから) 救おうというコマンド。実際に実行してみると、 推測が失敗したものが 2250 メッセージぐらいあったが、このコマンドで 75 通救うことができた。

2018-11-08: https://medium.com/asecuritysite-when-bob-met-alice/doh-what-my-encrypted-drive-can-be-unlocked-by-anyone-a495f6653581 オレ VAIO Z は Samsung MZHPV512 だけどどうなんだろ。

2018-11-08: witness が検出する問題。X 起動時に再現性 100% ぽい

lock order reversal:
 1st 0xffffffff81e1b630 &sched_lock (&sched_lock) @ /source/yasuoka/openbsd/head/git/src/sys/kern/kern_synch.c:444
 2nd 0xffff800000195270 &dev_priv->irq_lock (&dev_priv->irq_lock) @ /source/yasuoka/openbsd/head/git/src/sys/dev/pci/drm/i915/intel_lrc.c:1645
lock order "&dev_priv->irq_lock"(mutex) -> "&sched_lock"(sched_lock) first seen at:
#0  witness_checkorder+0x4c0
#1  ___mp_lock+0x70
#2  wakeup_n+0x39
#3  task_add+0x93
#4  gen6_rps_boost+0x129
#5  __i915_wait_request+0x155
#6  i915_gem_object_wait_rendering__nonblocking+0x1d6
#7  i915_gem_set_domain_ioctl+0xdb
#8  drm_do_ioctl+0x221
#9  drmioctl+0xf9
#10 VOP_IOCTL+0x5a
#11 vn_ioctl+0x6b
#12 sys_ioctl+0x404
#13 syscall+0x32a
#14 Xsyscall+0x128
lock order "&sched_lock"(sched_lock) -> "&dev_priv->irq_lock"(mutex) first seen at:
#0  witness_checkorder+0x4c0
#1  _mtx_enter+0x31
#2  gen8_logical_ring_put_irq+0x36
#3  __i915_wait_request+0x367
#4  i915_gem_object_wait_rendering__nonblocking+0x1d6
#5  i915_gem_set_domain_ioctl+0xdb
#6  drm_do_ioctl+0x221
#7  drmioctl+0xf9
#8  VOP_IOCTL+0x5a
#9  vn_ioctl+0x6b
#10 sys_ioctl+0x404
#11 syscall+0x32a
#12 Xsyscall+0x128

2018-09-27: https://favicon.io/favicon-generator/ で生成した favicon.ico を置いてみた

2018-09-26: yasuoka.net をアップグレード中

2018-09-26: 現在の relayd(8) は SNI だけをみて、TLS は終端せずに振り分けるということはできない

2018-09-26: acme-client(8) を使って Let's encrypt してみた。HSTS はやめといた

2018-09-19: 特定ライブラリだけを静的にリンクするには -l:libXXX.a というのが使えるらしい * 。が binutil 2.18 以降なので、OpenBSD では使えない

2018-09-19: chromium 69 は libc++ を更新しないと compile 通すことができず、純粋な 6.3 への移植はあきらめ、libc++ を更新した 6.3 で使うことにした...

2018-09-18: chromium 69 を 6.3 に移植中 libc++ も更新しないとしんどいっぽい

2018-09-15: https://github.com/zserge/jsmn/pull/102 タイトル変更してみた。

2018-09-15: https://github.com/yasuoka/gyazo 新作。

2018-09-15: gyazo 使わなくても自前で作れるような気がしたので、サクッと作ってみた。http://yasuoka.net/~yasuoka/images/ca262ebc8882d42f99ea062442ff1c92.png

2018-09-07: VAIO-Z の Windows 10 を 1703 に upgrade したら、起動時のディスクチェック (autochk) が毎回始まるようになってしまった

• https://twitter.com/yasuoka_m/status/1037511373452804097

• チェックしているのは OpenBSD のパーティションで、チェックが進むと OpenBSD のパーティションを壊している。いろいろとデバッグした結果、OpenBSD パーティションの最初のセクタに、パーティションが FAT32 だった時代のゴミが残っていて、autochk が FAT32 のパーティションと勘違いしていることがわかった:

  $ doas dd if=/dev/zero of=/dev/rsd0a bs=512 count=1
  

  で復旧

2018-09-05: emacs での unicode の code 入力 (ucs-insert) のキーバインドは C-x 8<RET>

2018-08-29: 248日問題。この commit https://github.com/openbsd/src/commit/d0b51642ac65fc549021b57e7692e1b0513937af
以前は、起動後 (2^31*hz)/86400 = 248(日) 経過するとパケットを受信できなくなる不具合があった。アップグレードをサボっているホスト群が、本日同時に発症。

2018-08-16: MS Mobile Mouse 3500。異常に動きが悪くなることがあるの耐えられないのでデバッグ開始

2018-08-15: axen(4) がエラー吐いてフリーズする問題は依然として発生した

2018-08-01: axen(4) が以下のエラーを吐き、その後フリーズする

checksum err (pkt#0)
invalid buffer(pkt#65535), continue
invalid buffer(pkt#65535), continue
invalid buffer(pkt#65535), continue
invalid buffer(pkt#65535), continue
invalid buffer(pkt#65535), continue
invalid buffer(pkt#65535), continue

とりあえず、以下のデバッグコードを仕込む。

diff --git a/sys/dev/usb/if_axen.c b/sys/dev/usb/if_axen.c
index 325ae548e7f..7c2905c4fd1 100644
--- a/sys/dev/usb/if_axen.c
+++ b/sys/dev/usb/if_axen.c
@@ -926,6 +926,9 @@ axen_rxeof(struct usbd_xfer *xfer, void *priv, usbd_status status)
     hdr_offset = (u_int16_t)(rx_hdr >> 16);
     pkt_count  = (u_int16_t)(rx_hdr & 0xffff);

+if (pkt_count == 0)
+    printf("rx_hdr = %08x total_len = %d\n", rx_hdr, total_len);
+
     if (total_len > sc->axen_bufsz) {
             printf("rxeof: too large transfer\n");
             goto done;
@@ -992,6 +995,7 @@ axen_rxeof(struct usbd_xfer *xfer, void *priv, usbd_status status)
             if ((pkt_hdr & AXEN_RXHDR_L3CSUM_ERR) ||
                 (pkt_hdr & AXEN_RXHDR_L4CSUM_ERR)) {
                     printf("checksum err (pkt#%d)\n", pkt_count);
+                    m_freem(m);
                     goto nextpkt;
             } else {
                     m->m_pkthdr.csum_flags |= M_IPV4_CSUM_IN_OK;
@@ -1021,6 +1025,8 @@ nextpkt:
             buf = buf + temp;
             hdr_p++;
             pkt_count--;
+            if (pkt_count == 0)
+                    break;
     } while( pkt_count > 0);

 done:

2018-06-21: OpenBSD の make(1) で VPATH が使えるが、それはドキュメントになっていない。由来をたどってみたところ BSD に "release 2.1 of pmake" というコミットログで 1990 年 5 月に import されている https://github.com/weiss/original-bsd/commit/c120402917b3cd1440f1c8a2dad15bfa1c855824 pmake の history もたどりたいところだが、それは発見できず

2018-06-16: ports の mew を 6.8 にした

2018-06-16: ネットワークの性能、じわじわ向上してる

2018-06-14: https://marc.info/?l=openbsd-cvs&m=152893945707374&w=2 で

194          CTASSERT(sizeof(struct ip) + sizeof(struct tcphdr) <= MHLEN);
195          CTASSERT(sizeof(struct ip6_hdr) + sizeof(struct tcphdr) <= MHLEN);

struct ip6_hdr なのだから #ifdef INET6 でくくるべきかを考えた。 まず、CTASSERT なので compile time だけの問題を考えれば良い。 次に #include <netinet/inpcb.h> を include した時点で無条件で struct ip6_hdr は晒されるので、INET6 が undefined の場合にコンパイルが通らなくなる、という 問題はない。その他の問題、#ifdef INET6 で括ることで解決する問題は思いつかない ので、そのままで良いのではと考えた。細かい話だけど。

2018-06-04: karl な openbsd は、実行中の kernel は /bsd.booted だが、crashdump 後 savecore する前に /bsd.booted は上書きされてしまうため、savecore できない問題が発生している。

--- etc/rc.orig      Sun Mar 25 05:12:24 2018
+++ etc/rc   Mon Jun  4 12:10:42 2018
@@ -371,6 +371,7 @@ mount -a -t nonfs,vnd
 # others aren't hurt.)
 mount -uw /
 chmod og-rwx /bsd
+[ -f /bsd.booted ] && mv /bsd.booted /bsd.last
 ln -fh /bsd /bsd.booted

 rm -f /fastboot

とした上で savecore_flags="-N /bsd.last" を rc.conf.local に追加してみている

2018-05-13: TP-LINK RE200 という WiFi の中継器をゲット。純粋なブリッジじゃなく、MAC アドレスが変わってしまうのでちょっと厄介

2018-05-11: 昨年 11 月に /dev/arandom が消えた。6.3 ということか

2018-05-10: panic する問題が頻発する。panic 中に panic して core が残らない問題にもあたり調べにくい。6.3 まで戻り、core 吐けるように改造した kernel にするつもり

2018-05-10: iwm0 OACTIVE

% ifconfig iwm0
iwm0: flags=8c43<UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MULTICAST> mtu 1500
        lladdr 34:02:xx:xx:xx:xx
        index 1 priority 4 llprio 3
        groups: wlan egress
        media: IEEE802.11 autoselect (HT-MCS9 mode 11n)
        status: active
        ieee80211: nwid XXXXXX chan 11 bssid xx:xx:xx:xx:xx:xx 70% wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp
        inet xxx.xxx.xxx.xxx netmask 0xffffff00 broadcast xxx.xxx.xxx.xxx
%

2018-05-08: GNU Dia を使ってみている。印刷した場合のことを考えると UML やフローチャートのデフォルトはデカすぎる。気になって手でポチポチ変更していくのは大変で、どうしても気になるならシェープを自作する方法になるっぽい。印刷はしないので、論理的にデカいのは気にせずに使うのが良いと思った

2018-05-02: emacs の ctrl-s でインクリメンタルになっていると日本語入力ができない。その場合 Ctrl-M でインクリメンタルがオフになる。日本語入力起動 -> Ctrl-S -> Ctrl-M -> 検索ワード入力 -> Ctrl->M

2018-04-27: tmux で ssh のセッションを使いまわす
https://github.com/yudai/sshh というのがあるようだ。 おそらくやりたいことは似ているべつの話になるが、自分の場合

+---------------+         +-------------------+
| note pc       |         | workstation       |
| +-----------+ |         | +----------+      |
| | ssh-agent | |-------->| | tmux     |      |
| +-----------+ |         | | +------+ |      |     +--------+
+---------------+         | | | pane |-|------------| server |
                          | | +------+ |      |     +--------+
                          +-------------------+

手元の note pc はネットワークが頻繁に変わるので、 note pc からの ssh セッションはキープできない。 長時間の端末操作のためには、固定された workstation を使いそこで tmux が起動しっ放しにすることにしている。

このような場合、note pc から workstation にログインして tmux session に attach すると、以降の新しい pane には そのログインの ssh の認証エージェントが使われることになるが、 note pc と workstation 間の ssh セッションは使い捨てられるので、 使い捨てらた ssh セッションで作られた pane から別のホストに ssh しようとしても認証エージェントは使えなくなっていて、 別の認証が必要が必要になってしまう、という問題がある。

この事態を避けるために自分は、

                    +------------------------------+
                    | workstation                  |
+---------+         | +----------+   +-----------+ |
| note pc |-------->| | tmux     |   | ssh-agent | |
+---------+         | | +------+ |   +-----------+ |     +--------+
                    | | | pane |-|-----------------------| server |
                    | | +------+ | (ssh -A server) |     +--------+
                    | +----------+                 |
                    +------------------------------+

tmux は常にその workstation 上の ssh-agent を認証エージェントとして使うようにしている。 このようにしておけば、tmux の pane は安定した認証エージェントを参照しているので、その pane からはいつでも、 認証はこの ssh-agent が行ってくれることになる。やり方は以下のとおりである。

• 準備として workstation 上に、

  # Prefer inherit SSH_AUTH_SOCK from existing session
  set-option -g update-environment "DISPLAY SSH_ASKPASS SSH_AGENT_PID SSH_CONNECTION WINDOWID XAUTHORITY"
  

  という設定を仕込んでおく。tmux のデフォルトでは -g update-environment に SSH_AUTH_SOCK が含まれているので、それを除外している。つまり、 SSH_AUTH_SOCK 環境変数は、 session を作成した時のものをずっと使いつづけるように設定している。

• workstation 上で tmux セッションを開始する時には、note pc の ssh agent からの ssh session ではなく、workstation 上の ssh-agent を使う。 具体的には以下のようなコマンドを実行する

  note pc % ssh workstation
  
  workstation % eval `ssh-agent`
  Enter passphrase for /home/yasuoka/.ssh/id_rsa:
  workstation % tmux
  

もっと簡単な方法はあるかもしれない。

2018-04-19: https://marc.info/?l=openbsd-misc&m=152410726501840&w=2 Android を MTP でマウントできてるらしい。自分は全然ダメ。

2018-04-17: virtual box のシリアルのパイプとどうやって接続するのか、少し悩んでしまった。ボケが始まったか... 端末だから cu とか screen ? みたいなボケで、実際にはパイプ(ストリーム)なので nc(1) がストレートな解。

2018-04-11: 6.3 で X　でマウスのホイールが、ホイールはするがボタンとして動作しなくなった。X の問題じゃなく USB マウスのドライバの問題っぽい。 MS Wireless Mobile Mouse 3500 勘違いだったっぽい。全然発生しない...

2018-04-10: VAIO を OpenBSD 6.3 に。いつの間に Hybernate がちょっ早になっていた。2 分 => 15 秒

2018-04-06: VAIO 退院。キーボード、パームレスト、液晶カバー含めいろいろと交換となり、新品みたいになって帰ってきた。

2018-04-06: 外付けの 4 ポート hub が勝手に dettach される現象が続けて 3 回発生... axen(4) を使っていることが新たに行ってることなのだが。