2020年1月23日木曜日

WebUSBとEdge Chromium

2020年1月15日、Edge Chromiumの最初のリリースはChromium 80として公開された。なので当然WebUSBが入っているはず。

そう思ってEdge Chromium for Macで「MakeCode for micro:bit」を開いてみたところ、「デバイスの接続」メニューがあった。ファームウェアが0254のmicrobitを接続して、「デバイスの接続」ボタンに進むと、Chromeと同じようにデバイス名の確認があり、編集したプログラムの書き込みが、「ダウンロード」を押すだけで完了した。

Python Editor for micro:bit」でもペアリング、Flash、Serialコンソールどれも問題なくできた。

よって、少なくともmicro:bitに関して、Edge ChromiumのWebUSBは問題なく使えるようだ。

2019年4月24日水曜日

Samsung X5 Thunderbolt 3 SSDをAPFSでフォーマットする

Samsung X5はThunderbolt 3接続なのでPCIexpressデバイスとして、システム情報では内蔵のSSDと同じ並びに表示されるが、ディスクユーティリティで選べるフォーマットはHFS+とexFATだけだった。

一方、ベンチマーク記事ではAPFSの数値も出ているので、何がおかしいのかわからなかった。

検索してみたところ、Appleの英文フォーラムに、ディスクユーティリティでGUIDパーティションにすることで自己解決したとあった。説明がわからなかったので他をいくつか読んでみると、スクリーンショット付きの解説があり、解決できた。

How to Format a Drive with GUID for macOS High Sierra, Mojave Installation - the Mac Observer by Jeff Gamet

X5は出荷時状態はexFATでフォーマットされていたが、パーティションテーブルがMBRのようだ。APFSはGPTであることが必要なので、ボリュームでなく、ドライブ全体を選べばパーティションのボタンが有効になり、そこでGUIDを選択すれば、APFSでフォーマットできる、ということらしい。

ドライブ全体を選ぶために、ディスクユーティリティのウインドウ左上の「表示」メニューで、「ボリュームのみの表示」から「すべてのデバイスを表示」に切り替え、現れたドライブ全体を選択するのがポイントだった。デバイス名では、例えばdisk3s1はボリューム、disk3がドライブ全体にあたる。

結果は、とにかく快適のひとことに尽きる。SATA3のSSDをUSB 3.0接続して、ファイルのコピーに45MB/s程度までしか出ない経験をして(カタログ上の数値の上限ではあるが)残念に思ったことがあるが、Thunderbolt 3接続では内蔵SSDと遜色ない反応をしている、と思う。

なお、何も考えずにフォーマットしたので、添付のアプリケーションを消してしまったが、Samsung Portable SSDのダウンロードページから「Activation Software for MacOS」として入手できた。ドライブの暗号化がメイン機能のようだが、ファームウェア更新ができたので、入れておくことにした。Cmd-Qで終了できないしメニューに項目がないのでどうやって終了するのかと思ったが、よく見ると右上に大きなバツが描かれていて、それをクリックする仕様だった。Appleのデザインガイドラインは気にしないらしい。

ちなみに、Thunderbolt Displayを使っている旧Mac mini Mid 2010に、Apple Thunderbolt 3 to Thunderbolt 2 Adapter経由でつないでみたが、認識しなかった。直結すればいいのかもしれないが、よくわからない。

macOSでホームディレクトリを外付けディスクに移動(owner問題の解決)

macOS Mojaveで動いているメインマシンは、Mac mini Mid 2011。最初のIntel Core(Sandy Bridge)な機種。実は昨年、2018年版が出る前にお亡くなりになり、急遽中古で入手したもの(松竹梅の竹から梅へダウングレードしたけれどしかたない)。店によっては2014年モデルも置いていたけれど、予算的に無理だった。

ところがそれも間もなく死亡のサインが現れてきた。経年劣化は避けられない。

そこでやむなく、積立てを崩すことにして、Mac mini 2018の梅モデルを購入。SSDはThunderbolt 3接続のSamsung X5にして補うことにした。500GB×2で運用していたけれど予算上500GBが限界だったので空きが足りず、まず現行のホームディレクトリをUSB 3.0(AkitoのThunderbolt 2 - USB 3.0変換ボックスを使っていたので)の外付けHDDに移すことにした。こうすれば、少なくともホームディレクトリの移行はスムーズになる。

移動にはdittoでコピーすればいいよ、-rsrcForkオプション忘れないでね、という記事は結構見かける(例えばこちらの記事など)。

再起動して同じようにログインできることまでは確認したのだけれど、Finderでフォルダに通行禁止マークがついていることに気がついた。開けないし、では、とchownしても全く変わらない。ls -lすると、owner:groupが_unknown:_unknown。あれ?

別の記事で、Cmd-iして「このボリューム上の所有権を無視」チェックボックスを外してからchownしてね(例えばこちらの記事)、というのがあり、これでようやく解決した。記事が分散している理由がmacOSのバージョン依存なのかどうか、ちょっと調べがつかなかったので、ここに両者をまとめた記事を置くことにした。

Samsung X5をAPFSでフォーマットするにはひと手間かかったのだけれど、日本語の記事が見当たらなったので次のエントリへ続く。

2019年3月2日土曜日

Parallels 14上のWindows 10でBluetooth LEを使うには

Bluetooth LEで通信するデバイスが、Parallels 14上のWindows 10で接続できないことに困っていた。
Windowsの設定からは、デバイスの名前は見えて、ペアリングもできるのに、アプリケーションからはデバイスに接続できないという状態。

ヒントは思いがけずParallelsのKnowledge Baseにあった。Parallels 12までのようだが、「Bluetooth端末をWindowsと共有する」のチェックを外せばデバイスとして現れるので、そこにAppleのデバイスドライバを与えてやればよいという話。ところがParallels 14では、このチェックを外しても「デバイス」→「USBとBluetooth」に「Apple Built-in Bluetooth」は現れない。チェックした場合、Windows 10の設定には「Virtual Bluetooth Controller」が現れて、Microsoftの標準デバイスがインストールされる。

そしてこのとき、デバイスマネージャの「Bluetooth」の項目をみて、おや、と思った。
ParallelsでBluetoothを共有したとき
BLE非対応となっている
BLEデバイスがいない。別の、BootcampでネイティブのWindows 10を動かしたMacBook Proでは、「Microsoft Bluetooth LE Emulator」というデバイスがいたのに、ここにいるのは「Microsoft Bluetooth Emulator」。Parallelsが用意する仮想コントローラは、Windows10にはBLE対応だと思ってもらえないもののようだ。

現在うまくいっているのは、MacBook Pro内蔵のBluetoothを使わずに、ドングルを使う方法。負けた気分だけれど、しかたがない。戦える時間のある方にお任せしたい。

以下は手順。
まず、「Bluetooth端末をWindowsと共有する」のチェックを外して、内蔵BluetoothモジュールをParallelsの管理対象外にする。
内蔵BluetoothをParallelsから使わないようにする
そして、適当なBluetooth 4.0対応のUSBドングルを接続。USB-Cの方はアダプタ経由で。Parallelsの選択画面でWindows 10を選ぶ。
Bluetooth 4.0対応のUSBドングルを接続してWindows 10に接続
 デバイスマネージャを開いて、「Microsoft Bluetoorh LE Emulator」が生えていれば成功。
Microsoft Bluetooth LE Emulatorが生えた
アプリケーションによっては実行途中で固まることがあるけれど(BootcampのMBPでも不具合があるので、なにか別の理由があるんだと思う)、普通のWindowsマシンと同様に使えるようになった。

ご参考になれば。

2018年5月19日土曜日

Windows 10上でNW.jsを使ったシリアル通信する

NW.jsで外部機器との通信をするとき、LinuxやMacは実績があるのだがWindowsではだめ、ということがとても多いようだ。

いくつか試して、とりあえずシリアル通信について、なんとか動かすことができたので手順を記録しておく。

NW.jsはNode.js + Chromiumなアプリ開発プラットフォーム。JavaScriptで書くところがミソだが世の中はElectronのほうが多いような気がしている。それはともかく。

通信に限らないとはいえ、C++によるネイテイブコードを含むNode.jsのモジュールはWindowsではやっかいだ。UNIXとWindowsで挙動の違う関数、Windows側にバグがある関数などがあって動かない、というのが多く見受けられるパターン。

また、ビルドにはnode-gypを使うようだが、 この環境作りにPython2.7とVisual Studio 2015が必要という、そこそこのハードルがある。VSもまともにインストールするとおおごとだし、node-gyp開発者側にPython3対応にする気が全くないようなので(GitHubのIssueのつれない感じからの類推)、node-gypだけの小さな閉鎖環境が望ましいことになる。というわけで、そんなパッケージが用意されたようだ。以下のコマンドを「管理者権限つきの」コマンドプロンプトに
npm install --global --production windows-build-tools
と入力して実行すると、ユーザのホームディレクトリ直下に、.windows-build-toolsというディレクトリができて、そこにPython2.7とVS2015のコマンドラインと必要なライブラリが一式入って、とてもありがたい。

ただし、すでにVS2015が入っていると、node-gypは一通り動くものの、NW.js対応にするときにやっかいなことになった(普段VSをC++の開発環境に使っているなら問題はないんだろうと思う)。詳しくはhttps://github.com/nodejs/node-gyp#installationのWindowsの注意書きを参照していただきたいが、「Common Tools fot C++」としてまとめられたツールやライブラリ群をVS2015を起動し、C++のプロジェクトを作る作業をすることでインストール開始させなければならない。

準備ができたところで、いきなりNW.js対応を作る前に、通常のNode.js用インストールをして動作テストをするのがよいと思う。これはnpmを使うなら、プロジェクトのディレクトリを作り、そのなかでnpm initしてpackage.jsonを作成したあと、、
npm install serialport
とする。node_modules以下に、大量の依存関係のあるモジュールとともに一式が入る。このあと適当に、サンプルプログラムなどを動かせばよいのだが、シリアルポートのデバイス名がLinuxやMacでは '/dev/tty.なんとか'のファイル名になっているところを、Windowsでは'COM3'などのように置き換える必要がある。もしシリアルポートがなくても、examples\mockings.js は仮想ポートデバイスを作って送受信のようなシミュレーションができるので、これで動作確認としてもいいかもしれない。

動作確認ができたあとは、NW.js用にリビルドが必要となる。Node.js用のままNW.jsで読み込もうとしても、はDLLエラーのようなことが生じて動かない。

NW.js用には、nw-gypという、node-gypのフォークモジュールがあって、それを入れておく必要があるらしい。また、node-pre-gypモジュールも入っていたほうが無難なようだ。

nw-gypの実行には、binding.gyp(C++のオブジェクトをJavaScriptのオブジェクトに結びつける設定ファイル)のある場所でなければならないようだ。そこで、node_modulesの下の、serialportの下にcdする。(cd node_modues\serialport)

このあたりになってくると、UNIXの操作に近くなってくるので、Gitをインストールし、その際に、コマンドプロンプトでMingWin由来のUNIX互換コマンドが動くよう設定しておくと気持ちが楽になると思う。GIt Bash上でやってもよいのかもしれないけれど、試してはいない。

リビルドのコマンドを実行する前に、NW.jsのバージョン(Node.jsやChromiumのバージョンではない)を確認しておく必要がある。NW.EXEを実行すれば、右下のいちばん上に、「nw.js v0.30.5」などのような表示が見えるので、それを控えておく。あるいは、ZIPを展開したフォルダ名が配布されたままならば、フォルダ名にバージョン番号が入っているので、それをみてもよい。

この先は、相性によって2つの方法を試してコンパイルが通るほうを選ぶようだ。また、python.exeが環境変数PATHに通っていなければいけないようなので(node-gypは%HOME%\.npmrcファイルの設定を読んでPython2.7の実行パスを決めてくれるが、nw-gypやnode-pre-gypは見ないようだ。Windowsでは、コマンドプロンプトに「set PATH=%PATH%;Python2.7のパス」のように、セミコロンで連結するのが流儀。%ではさんだ変数名は、変数参照を意味するので、既存のPATHに、Python2.7のパスを追加したことになる。

これでようやく実行。
nw-gyp rebuild --runtime=node-webkit --target=バージョン番号
または
node-pre-gyp rebuild --runtime=node-webkit --target=バージョン番号
のようだ。当方では今回は、nw-gypでコンパイルが通った。詳しくは、Qiitaの@sashimizakanaさんのエントリ「node-webkitでネイティブモジュールを使う」を参照。

バージョン番号を指定してリビルドしていることから、NW.jsのバージョンが変わるたびにリビルドが必要になるんだろうと思う。

動作チェックに使った、シリアルポートの一覧表示スクリプトを含むHTMLファイルを掲載しておく。ポートオブジェクトをJSONで、見えた数だけ列挙するというもの。console.log()も入れているのでデバッガのコンソールにも出る。元ネタはこちら。NW.js用ではないけれど、シンプルかつ丁寧に説明されていて、わかりやすいと思う。DOM操作は、VSCodeエディタの予測候補を見ながら適当に書いた。index.htmlのファイル名として、npm initしてpackage.jsonを作るときのmainに、デフォルトのindex.jsではなくindex.htmlと入力してある。

<!DOCTYPE html>
    <head>
        <title>Hello World!</title>
        <script>
            var SerialPort = require('serialport');
            // list serial ports:
            SerialPort.list(function (err, ports) {
                ports.forEach(function(port) {
                    portString = JSON.stringify(port);
                    console.log(portString);
                    title = document.getElementById('h1');
                    p = document.createElement('p');
                    text = document.createTextNode(portString);
                    document.body.appendChild(p).appendChild(text);
                });
            });
        </script>
    </head>
    <body>
        <h1 id="title">Hello World!</h1>
        <p id="port"></p>
    </body>
</html>
NW.jsからは、プロジェクトのディレクトリ名を引数に与えるのが簡単だと思う。

以上、ご参考まで。

2017年5月31日水曜日

ソフマップ秋葉原本店閉館に思うこと

変化の多い秋葉原に対していちいち感慨を持つほど若くもないのですが、ここだけは個人的に特別な意味があるので記しておきます。

それは2008年6月8日。

前日宿泊していて、この日は秋葉原で電子部品等を買う予定でした。ただ、まだ朝早かったため、秋月開店まで、まだ真新しいヨドバシAkibaに寄り道をして、書籍とCD等を物色することにした。まだ名古屋では書籍もCDも売れ筋は遅れがちで、また哲学や文芸評論など人文系を中心に教養の読書にはまっていたため、ヨドバシの有隣堂でも十分に魅力があり、秋葉原だけにコミックその他のディスプレイに惹かれ、立ち読みをして何をどこまで買えば予算内に収まるか、持って帰られれる重量になるか(どうせ新幹線に乗る前に丸善丸の内本店で大量に買うことはわかっていたから)、厳選をしているうちに、昼時になってしまった。

ついでなのでタワレコも若干ひやかし、上階のインド料理店(だったと思う)でカレーを食べ、それから大ガード下をくぐって電気街に出ようと、疲れた身体に気合を入れながら歩いていた。坂を上がり交差点まで行ったら左に折れ、ヒロセ横の路地から丹青通称の上林ビル方面に抜けるのだ。千石電商をひやかして、秋月へ向かうのだ。ヒロセ横の路地は人が少なく歩きやすい。もう2時をまわっていただろうか。

だが、なんだか様子が変だ。なぜ路肩に何台も消防車が停まっているのか。救急車も見える。人の流れが遅い。

やや人が少ないな、と思いながら坂を登ったところで空気が一変した。大量の人、人、人。路上でノートPCを開き、必死の形相で原稿を書いているスーツ姿の若い男女が縁石や生け垣の低いブロック塀を使っている。呆然と交差点方面を向いている人がその先に人垣を作っている。張り詰めた空気が一帯に漂っている。

何かが起きている。
当時はまだi-Mode携帯だった。でもニュース速報はわかる。

冒頭のたった1行を読んで、すべてを理解し、背筋が凍った。ここは無差別殺人現場だ。何人もの命がこの先で失われた。

動けなくなった。なにも考えられなくなり、気持ちを取り戻そうと、妻に一行、メールを送った。何の返信もなかった、と思う。思考は凍ったままだった。

人垣の向こうは非常線が張られていて、入ることはできない。ともかく手前で左に折れ、JR駅方向の路地から中央通りに出ようと思った。普段なら歩行者天国でどこでも渡れるはずだったが、非常線は中央線ガード下まで続いていたと思う。やっと出られたのは、結局ラジオセンターの前だった。

そこから北方面を覗くと、もう現場検証も終わろうかとしているところだったと思う。加藤智大氏はすでに取り押さえられ護送されたあとだったはず。交差点中央は空いていて、周辺に救急車何台かと警察車両はあったが、動き出す気配はなかった、と思う。

信号を渡ったのがどこか、その後の動きは記憶がない。もしかしたら、昌平橋方面にまわらざるを得ず、鈴商方面から入ったのかもしれない。

ただ、予定通りの動きをしたはずだ。千石で工具類をいくつか買い、秋月で大袋いっぱいに何かを買ってJR駅に戻ったのだと思う。その頃はもう夕方なので、もとの秋葉原の喧騒が、あのあたりの一帯には戻っていたはずだ。

後日、名古屋に戻って何ヶ月も経った頃、酒席で突然「(名古屋支店長だった頃は気安く接していただいていた、現在本社取締役)さんのお嬢さんのことは残念だった。就職も決まっていたけれど、ソフマップの店頭のいちばん目立つ場所でチラシを配っていたから狙われた」と、聞かされた。

それを聞き終えるまでの間に、すべてがフラッシュバックした。口がきけなくなった。

テレビも新聞も、ことあるごとに加藤智大氏の動きが詳細に繰り返され、そこにどのぐらいの人がいて、どこに何があるか、立体的に思い浮かべられるほどだったからだ。

その、鮮明な建物の並びと人混み以外は漠然とした脳内映像に、彼がダガーナイフを持って走り回るなか、大学4年生の女性に突撃し、刺しながら、次の相手に向かっていく映像が追加された。店頭の案内状の制服はわかる。背格好や容姿は似た人物が選ばれるので、顔だけが不鮮明な映像だが、多くの人混みが混乱するなか、下がることもできずにいる、一際華やかな容姿と制服に彼の目が注がれ、次の相手を探すように顔をそむけながらまっすぐ突入したのだろう。

その生々しい現場の情報は知らないし、知りたくもない。

2010年、伊坂幸太郎「ゴールデンスランバー」映画化作品を、名古屋のシネコンで観た。ビートルズはAbbey Roadのジャケットが幼い記憶にありリアルタイムはLet It Beだけなので伊坂小説作品にいまひとつ入り込めないのだが、映画は中村監督の手腕が発揮され素晴らしかったと思う。仙台旅行の記憶もあるので町並みにも見覚えがあり感情移入できた。

劇中、ゲームソフトを手に入れた小学生がクラスの仲間2人から奪われるシーンがヒロセ横の路地だった。周辺は人が多いにもかかわらず、ここはなぜか湿っぽく、暗くて人があまり通らない。路地にしては広いのに、両側が店の表でも裏口でもなく壁ばかりなので、人混みを避けるべきこのシーンにはうってつけのロケーションだ。観た瞬間にわかる。ああ、やっぱりここだよね。彼が逃げ込んだのもわかる。

秋葉原ラジオセンターの半畳の店で家業の手伝いをして育った、同じ年の知人も言う。あそこは特別だよね、と。

ソフマップAkiba本館に戻る。ここはなんだったけ。
1997年のアキバマップをarchive.orgで探ると、ヤマギワ本店とあった。なるほど、インテリア照明を中心としたショウルームだったっけ。本店は、上野方面の次ブロック手前角T-ZONE本店の中央通り反対側だ。いまはどうもじゃんぱららしい。トヨムラが元気だった頃。

ビックカメラに転換するのは合理的。立地の良さと秋葉原の客層に一般客が多いことを考えればそうすべきだろうと思う。開店10年を節目にしたのは何かを待っていたのか、それはわからない。

2017年4月19日水曜日

I-O DataのWN-AC433UAをArch Linuxで使いAPを立てる(2017年4月版)

概要:以前の投稿で、いくつかリンクをいただいておりましたが、最近のカーネルでは新しいv5のデバイスドライバのほうがよさそうでした。パッケージは「aur/rtl8812au-v5-dkms-git」です。

TL;DR;


2017年3月末頃のLinux Kernel 4.10になって、いままでWi-Fiルータとして使っていたIntel NCU NCU5CPYH内蔵のWi-Fiチップ「Wireless-AC 3165」では起動時に
kernel: iwlwifi 0000:02:00.0: L1 Disabled - LTR Disabled
のエラーがあったり、APに接続してくるデバイスが6か7台目を超えるとマイクロコードのエラーを発生してドライバの再起動を繰り返し、最後にはカーネルパニックで死ぬ、ということになっておりました。

ファームウェア27が現在の最新のようですが、考えられる手を尽くすもどうにもならないので、いったんお蔵入りしていたWN-AC433UAを復活させることにしました。

ただ、いままで使っていたRealtekドライバ4.3.20ベースの「aur/rtl8812au_rtl8821au-dkms-git」が認識されず、同じチップでより新しい、バージョン5.1.5ベースのドライバが最終更新日2017年4月17日でしたので、これに入れ替えることにしました。

以前のドライバのアンインストール


まず、いままでのドライバをdkms removeしておきます。
sudo dkms status
すると、「rtl8812au_rtl8821au, 4.3.22_beta.r9.928e27f, ...」云々と出てくると思いますので、
sudo dkms remove rtl8812au_rtl8821au/4.3.22_beta.r9.928e27f --all
のような感じで「モジュール名/モジュールのバージョン番号」を指定してください。バージョン番号ですが、AURのページをみると、この4.3.22ではなく4.3.20が最新のようですね(ただし2016年9月11日以後更新がない)。

その後、yaourt -Rでアンインストールします。
yaourt -R rtl8812au_rtl8821au-dkms-git

新ドライバのインストール

yaourt -S rtl8812au-v5-dkms-git
コンパイルしてインストールすると、dkms addまで自動でやってくれます。
$ dkms status
rtl8812au-v5, 5.1.5, 4.10.10-1-ARCH, x86_64: installed
うまくインストールできているようです。ip linkすると、wlp0s20u1というデバイスが見つかると思います。

hostapdの設定


その前に、ブリッジデバイスを作っておきます。systemd-networkdを使っているので、

/etc/systemd/network/br0.netdev
[NetDev]
Name=br0
Kind=bridge
/etc/systemd/network/br0.network
[Match]
Name=br0
[Network]
Address=192.168.0.1/24
IPForward=yes
などとしておきます。sudo systemctl restart systemd-networkdすると生えてくるんでしょうか、むかし作ったときには再起動してしまったので不明です。 あと、以前はwlp0s20u1をbr0につないでおくという話だったような気がしますが、いまhostapdの解説を読むと、それは「やってはいけない」らしいです。なので、適当にIPアドレスを振っておきます。

/etc/systemd/network/usbwifi.network
[Match]
Name=wlp0s20u1
[Network]
Address=192.168.0.2
こんな感じでしょうか。

それで、iw listした結果からこのチップでサポートされている機能を探り、いま当方で動いているhostapd.confは以下の通りです。

/etc/hostapd/hostapd.conf
interface=wlp0s20u1
driver=nl80211
bridge=br0
ieee80211d=1
country_code=JP
logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=2
ctrl_interface=/run/hostapd
ctrl_interface_group=0
ssid=設定するSSID
hw_mode=g
channel=7
beacon_int=100
dtim_period=2
max_num_sta=255
rts_threshold=2347
fragm_threshold=2346
macaddr_acl=0
auth_algs=3
ignore_broadcast_ssid=0
# IEEE 802.11n
ieee80211n=1
ht_capab=[HT40+][SHORT-GI-20][SHORT-GI-40][DSSS_CCK-40]
# IEEE 802.11ac
#ieee80211ac=1
#vht_capab=[HT40+][SHORT-GI-20][SHORT-GI-40][DSSS_CCK-40]
vht_oper_chwidth=0
wmm_enabled=1
wmm_ac_bk_cwmin=4
wmm_ac_bk_cwmax=10
wmm_ac_bk_aifs=7
wmm_ac_bk_txop_limit=0
wmm_ac_bk_acm=0
wmm_ac_be_aifs=3
wmm_ac_be_cwmin=4
wmm_ac_be_cwmax=10
wmm_ac_be_txop_limit=0
wmm_ac_be_acm=0
wmm_ac_vi_aifs=2
wmm_ac_vi_cwmin=3
wmm_ac_vi_cwmax=4
wmm_ac_vi_txop_limit=94
wmm_ac_vi_acm=0
wmm_ac_vo_aifs=2
wmm_ac_vo_cwmin=2
wmm_ac_vo_cwmax=3
wmm_ac_vo_txop_limit=47
wmm_ac_vo_acm=0
eap_server=0
own_ip_addr=127.0.0.1
wpa=2
#wpa_psk=暗号化されたパスフレーズ
wpa_passphrase=平文のパスフレーズ
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
ご武運を祈ります。

ひとつの設定ファイルでBand 1(2.4GHz帯)とBand 2(5GHz帯)両方を設定するのは面倒そうなので、Band 1のほう(802.11n)を生かしています。Band 2(802.11ac)の設定をする場合は、
hw_mode=a
channel=36
(チャンネル番号はWikipediaの項目を参照)のように置き換えることになると思います。

また、この設定でjournalctl -fのログをみているとちょっとうるさいので、logger_syslog_levelの値を34(大きいほど情報が減る)にしたほうがいいかもしれません。

このあと、iptablesでNATの設定したり、DHCP等の設定が必要ですね。「インターネット共有」のドキュメントを参照してください。

自宅用ではdnsmasqでDHCPサーバとDNSリレーを兼用するのが簡単だとは思いますが、多数の接続がある環境では不具合があるようなので、当方ではdhcpdunboundを設定しています。