カテゴリー: ノウハウ

コンピュータ関連の問題と対処などノウハウを紹介します

WordPress 5.3 Betaリリース、 旧版へのセキュリティパッチは？

2019年9月23日にWordPress5.3Beta1がリリースされていますが、旧版へのセキュリティパッチの情報は特にありません。WordPressは新版をリリースするときは１か月くらいかけて毎週のように更新版を出してきます。開発のほうに力を入れていて、セキュリティへの対処へ使うパワーがあまりない感じがします。
セキュリティ対処は外部の人の力に頼っていて、自己対処ができていないのではないかと思われます。このような状態では、新規開発部分に作りこまれる脆弱性は減らず、脆弱性がどんどん増えていく状態になるのではないでしょうか？

さて、追加でWordPress 5.2.3 で対処された脆弱性について確認します。 影響度と影響範囲の情報について追加情報が出ていますが、あまり詳しくありません。 CVE-2019-16220 （JVNDB-2019-009141）の場合、影響バージョンは WordPress 5.2.3 未満 となっています。該当機能が、初期バージョンから存在するのか疑問ですが、該当機能はかなり以前からあるので事実上すべてのバージョンに影響があるといってもよいのかもしれません。それから9/12の午後以降にJVNの情報公開がされていました。今後のセキュリティパッチはWordPress5.3に対して提供されることになると思われるので、どのタイミングでWordPress5.3に上げるのか、検証計画を立てておくなど検討しておいたほうがよさそうです。

ネットワーク障害発生、色々調べたが原因特定できないまま解消。

昨日、原因不明のネットワーク障害が発生し原因調査と対処をしていましたが、原因不明のまま解消しています。NTT側の障害の可能性もありリアルタイム障害情報などを確認し、「障害があるかも」の情報があり注視しながら進めていましたが実質的に何もしないまま解消しています。以下状況と対処内容、今後の障害に対するメモです。

1.　2019/9/19 15:00ころネットワークが使えなくなる障害が発生。
復旧のため、PC再起動、ルータの再起動を行ったが復旧せず。
　状況を確認したところ、LAN内で同一セグメントの別マシンにPingも通らない。
　→ 自マシンのIPが想定外のアドレスに変わっている。→ DHCPが機能していないとおもわれた。
2. 自マシンを固定IPに変更した。
　→ これでもLAN内で同一セグメントの別マシンにPingも通らない。ルータにもPingが通らない。
＃なんか変だ、発想を変えて、使えるものを確認してみる。
３． 別のWiFi回線を使ってインターネット上の情報を見てみる。特に情報がないためNTTの回線の問題ではないかもしれない。事象発生から10分くらいしかたっていないのでまだ情報が出ていないだけかもしれない。携帯電話から光電話に電話をかけてみると問題なく電話がかかってきた。
＃ますますオカシイ、外部回線の問題ではなさそうなので自前で対処するしかなさそうだ。
4. よくあるインターネット接続できない場合のPCやルータの再起動では回復しなかった。
＃これは自分で地道に原因調査して、回復させるしかなさそうだ。
5. まず最小限の範囲から回復させていくことにする。
　自マシンと同一セグメントの別マシンの通信を復旧させることにした。この隣のマシンにPINGが通らないは異常な事態だ。単純に手元のHUBが故障したのかと仮説を立てて確認をしようとしていたところで、別系統の無線LANで接続している機器から次々とインターネットに接続できない旨のメッセージが報告された。
＃おや、これは単一障害ならやはりルータの問題か？と問題原因の仮説を見直すことにした。
6.いったん、電源を切ってみる。
　→これでも、 自マシンと同一セグメントの別マシンの通信ができない。固定IPなのにPingも通らない。
＃これは、かなり異常な状態である。使える機器を狭い範囲で確認して順番にひろげていくことにした。
7. 一度、HUBにつながったケーブルをすべて外して、 自マシンと別マシンだけにして、Pingしてみる。問題なくPingが通った。
#当たり前だが久しぶりにようやく動いた。
8. 1本ずつ、ケーブルをつないで動作確認してみる。ある1本のケーブルをつないだところで、そこまで通っていた 自マシンから別マシン へのPingが通らなくなった。ネーブルを外すと、Pingが通るようになる。このケーブルの先に問題がありそうなことが判明した。ただ、このケーブルの先にルータがあり、このケーブルを接続しないと、インターネットには接続できない。
＃このパターンの場合、ループしている可能性が一番高い。しかし、その後の調査でもループは見つかっていない。長引きそうだが、インターネットの接続を早く復旧したいので、メインルートから復旧を試みることにする。
9.問題のケーブルの先のHUBに接続されたケーブルをすべて外してルータのみ接続した。→ これによりインターネットへの接続が復旧した。
10.　先に外したケーブルを接続しなおし、動作確認を行った。→ 障害発生前の状態に復旧した。
＃結局、障害の原因は不明であり、ケーブルの挿抜だけで復旧したことになる。今度同様の事象が発生したときは、パケットキャプチャも行うことにする。

WordPress セキュリティパッチのみ自動適用するには

　WordPressのセキュリティパッチに関して検討および対処してきましたが、多数のプラグインの利用とWordPressのパッチリリースのスタンスや情報公開の仕方を考慮してパッチリリース状況の監視と適用の手順を見直しました。
　セキュリティパッチのみを適用するということが、WordPressの場合は「セキュリティ修正が含まれているのにメンテナンスパッチ」となっていたり、「プラグインのセキュリティ問題の対処をセキュリティ修正としない」とされていたりする状況からあまり妥当でないとなっていると判断しました。

つまり、ポイントは次の2点です。
・WordPressがいうところのメンテナンスリリースとセキュリティリリースとを区別して別の取り扱いをする意味はあまりない。メンテナンスリリースとされていてもセキュリティの対処が含まれている場合がある。
・ メンテナンスリリースとセキュリティリリースのどちらも適用しないと問題があるかどうかを確認できない場合がある。

以上の状況から、つぎのようにします。

「テスト用サイトを立ち上げておいて、テスト用のサイトについてはパッチを自動適用する設定にしておく、パッチ適用のメールが来たら動作確認を行い、本番環境に適用するかどうかを吟味し適用手順を確立したうえで適用作業を行う。」

WordPress 5.2.3 セキュリティパッチの適用

2019年9月5日にリリースされたセキュリティ＆メンテナンスパッチWordPress5.2.3について書きます。 wp-config-sample.phpが更新されていましたが、動作に影響がある変更はなく実質的には気にする必要はありませんでした。5.2.1のように白画面になることもありませんでした。
　しかし、” Page Visit Counter ”がエラー（具体的に何のエラーなのか情報がない）で止まっていました。この停止問題はプラグインを設定ページで有効化することで解決しています。

WordPress 5.2.3 で対処された脆弱性について確認します。 WordPressのサイトの情報では1件ごとに明確にされるべき影響度とか影響範囲の情報がなく、問題検出者への感謝？の公開の場でしかありません。何とかしてほしいが、他のサイトで確認してみましょう。 9/12時点でJVNのほうにはまだ登録されていないように見えます。NVDの情報では、つぎの7件がWordPress5.2.3で対処されたことが分かります。

CVE-2019-16223WordPress before 5.2.3 allows XSS in post previews by authenticated users.
CVE-2019-16222WordPress before 5.2.3 has an issue with URL sanitization in wp_kses_bad_protocol_once in wp-includes/kses.php that can lead to cross-site scripting (XSS) attacks.
CVE-2019-16221WordPress before 5.2.3 allows reflected XSS in the dashboard.
CVE-2019-16220In WordPress before 5.2.3, validation and sanitization of a URL in wp_validate_redirect in wp-includes/pluggable.php could lead to an open redirect.
CVE-2019-16219WordPress before 5.2.3 allows XSS in shortcode previews.
CVE-2019-16218WordPress before 5.2.3 allows XSS in stored comments.
CVE-2019-16217WordPress before 5.2.3 allows XSS in media uploads because wp_ajax_upload_attachment is mishandled.

9/11にDBに登録されたばかりで影響範囲など詳しい情報はまだありませんでした。

想像ですが、9/12時点で過去バージョンに対してセキュリティ修正のみ（WordPress5.1.2?）を提供しようと準備しているように見えます。5.2.3のリリースには「In addition to the above changes, we are also updating jQuery on older versions of WordPress. This change was added in 5.2.1 and is now being brought to older versions. 」の記述があります。しかし明示的には5.1.2について特にアナウンスしているようには見えないので、本当にリリースされるかはわかりません。どうしても欲しければチームに入って推進すればよいかもしれません。

Linuxホットスポット検証のため USB WiFiデバイスをいくつか動作検証してみました

・ホットスポットの動作確認した環境はつぎのとおりです。これはLinuxで最初に動作確認できたLenovoのノートPC G570での操作をベースにしたGUI操作のみのチェック手順です。
HW:
・ Intel(R)　　 USB 3.1
・USB2.0
OS:
・ Windows10 バージョン 1903 OSビルド 18362.295
・ Linux Ubuntu 19.04

以下にそれぞれの仕様と各OSでの動作状況をまとめました。動作確認はインストール
[表中の記号の意味]
〇：上記OS で ドライバ等の追加インストールなしで利用可能
×： 上記OS で ドライバ等の追加インストールなしで利用不可
△： 上記OS で ドライバ等の追加インストールで利用可能。ドライバ無は×
▼： 上記OS で ドライバ等の追加インストールしても利用不可。 ドライバ無は×

型番TL-WN725NWDC-433DU2HBK802.IINPT-N330multibyte
写真写真
メーカTP-LINKELECOM Cangad Saikogoods
pinTOP
参考AmazonAmazonAmazonAmazonAmazon 写真と違う
金額700円
(送料630円)		 2,389 円
(送料 0)		299円
(送料300円)＊6		480円
(送料0)		￥398
(送料0)＊6
インターフェイスUSB2.0USB2.0USB2.0USB2.0
周波数2.4GHｚ2.4GHｚ
5.2,5.3,5.6GHｚ		2.4GHｚ2.4GHｚ2.4GHｚ
伝送方式11b/g/n11ac,11a,
11b/g/n		11b/g/n11n？ 11b/g/n
送信出力？10mW/MHz以下？
Win10 子機〇〇 〇 *7× *3 〇
Win10 HotSpot〇*b〇*b 〇 *7*b× 〇 *b
Ubuntu 子機〇△ ＊2〇〇〇
Ubuntu HotSpot× ＊1▼ ＊2 *5〇*bx *4〇*b
Ubuntu hostapd×？ *8×？ ＊８
Ubuntu
使用ドライバ（チップ）		RTL8188euRTL8812au(RTL8188CU) Ralink MT7601U(RTL8188CU)

＊1：HotSpot起動時にエラーが発生し、正常にHotSpotを起動できない。
＊2： USBデバイスとは認識するが、WiFi機器と認識しない。（メーカサイトではLinux未対応） ドライバをmake インストールすることで認識
*３： mini-CDつき、インストールすれば使えるかもしれないが、保留。
*4： WiFiのHotSpotのメニューがグレーアウトされている。
＊5：HotSpot起動操作で WARNログ（ device (デバイス名): Activation: (wifi) Ad-Hoc network creation took too long, failing activation）を出して、起動に失敗する。
＊6：配送に非常に時間（2、3週間）がかかった。発送元は台湾。
＊7： mini-CDつきだが、使用しなくてもWin10で動作した。
*8：ドライバが未対応？

参考：以下はUSBモジュールではありませんが、参考のため動作確認した結果です。

型番G570
写真
メーカLenovo
周波数2.4GHｚ
伝送方式11b/g/n
送信出力？ （比較的弱い）
Win10 子機〇
Win10 HotSpot〇 ※b
Ubuntu 子機〇
Ubuntu HotSpot〇 ※a
Ubuntu hostapd〇 ※b
Ubuntu
使用ドライバ		AR9285

※a：Ad-Hocモードで動作する。
※b:Infraモードで動作する。

アプリに関係なく（ラなんとかも、なんとかgoにも）使える位置偽装

ここまでに書いた内容を読み返せばどのような手法で位置偽装するのかITエンジニアには理解できるでしょう。実現のためにはいくつかの条件はあるが、比較的簡単に実現することができた。
　要するに「 会社引っ越し後、WIFIで位置情報を検索すると前の住所が表示されます。 」や「 GoogleChrome・マップの位置情報 」などで起きているWiFiの情報に基づく位置情報の誤認識を利用するということです。これは意図せずおきれば誤認識なのですが、誤認識を誘発し一定の制御のもとにおけば、それは位置偽装といえるでしょう。この位置偽装の特徴はモバイル機器に追加アプリをインストールする必要がないことと、アプリに関係なく利用できることです。追加検証と有効性については別の場所で行うことにします。

　ここで扱う位置情報は本来の目的ではない情報を別の個人情報として扱うべき情報を組み合わせて実現した便利な機能により得られた情報です。情報提供者にほぼ無断で別の目的で利用していると言ってしまってもよいかもしれません。それはさておき、上の方法での位置偽装はいわゆる偽装アプリをインストールするわけではないので、偽装を検出することは困難というか、ほぼガードすることはできないでしょう。なんとかgo++のように利用できなくなったり復活したりというイタチごっこは発生しません。　さらにアプリに関係なく利用できるのも特徴です。

USB Linux（Ununtu）を一度起動すると、Windows10の時刻が変わる。対処できたが、このWin10の挙動は？

事象；USB Linux（Ubuntu）を起動して使用した後、Windows10を起動すると時刻がずれている。９時間遅い時刻つまり、GMT？ UTCの時刻に変わっている。

暫定対処；暫定対処というよりも、事象発生時に「設定」→「時刻と言語」で、一度”時刻を自動的に設定する”もしくは”タイムゾーンを自動的に設定する”のチェックを外してもう一度”オン”に戻すと、正しい時刻にもどる。

原因調査；　推測：USB Linuxが、時計のタイムゾーンを設定していない状態になっており、Linuxを起動するとその状態がハードウェアに記録される。Windows10は起動しただけではハードウェアの設定を更新しないので時刻表示が変わると推測した。
Ubuntuを起動しtimezoneを確認した
$ timedatectl
Local time: Wed 2019-08-28 00:40:19 UTC
Universal time: Wed 2019-08-28 00:40:19 UTC
RTC time: Wed 2019-08-28 00:40:19
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
上の結果から、推測は当たっていると判断した。

根本対処、対処；
　上の確認結果から USB Linuxがハードウェア設定を変更しないようにすれば問題を発生させないと推測する。設定ベースでは、timezoneにAsia/Tokyoを設定することで解決すると推測される。

$ timedatectl set-timezone Asia/Tokyo
$ timedatectl
Local time: Wed 2019-08-28 09:44:03 JST
Universal time: Wed 2019-08-28 00:44:03 UTC
RTC time: Wed 2019-08-28 00:44:03
Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

対処結果、結論：
　上の対処の結果は、USB Linux上にも記録される。また、一度Ubuntuを起動した後、Windows10を起動すると右下の時計の日時は何も設定変更しなくても正しい時刻を示すようになった。これで、問題解決であるが、Windowsの妙な挙動を検出した。Windows起動時に表示されるきれいな写真「 Windows スポットライト」 の左下に表示される時刻が9時間前の時刻になっている。気になる挙動だが、次回Windowsを起動するときには日本時間で表示される。どんな仕組みで9時間ずれが覚えられるのか、そしてWindowsを一度起動したら解消するのか。　上のメッセージの「 RTC in local TZ: no 」というのが怪しい。これを変えてみる。
$ timedatectl set-local-rtc true で解決できた。

スマートスピーカーがあればいらなくなるもの

一気に普及が進みそうな気がしていたスマ―トスピーカーだが、あまり普及が進んでいない感じがする。利用方法や活用方法がまだまだ整備できていないことが原因かもしれないが、なんといっても使い方があまり知られていないことが原因ではないだろうか。

今回は、スマートスピーカー単体で既存製品の機能を代替できるものについて書きます。つまり、スマートスピーカーさえあれば必要でなくなる既存製品のことです。そしてそれぞれのメリット・デメリットと既存製品が生き残るために取りうる選択肢を考えてみます。

　まず、スマートスピーカーが代替可能な領域です。最近はディスプレイ （タッチパネル） 付きのものも出てきているのでそれも対象にします。スマートスピーカーのインターフェイスの出力は音のみです。ディスプレイ付きのものは映像出力も可能です。入力は、音、タッチパネル操作、そしてインターネット上の情報です。インターネット上の情報はあまりにも広く絞り切れないので、入力側は考慮しないことにします。それから出力先としてインターネットが可能と考えることもできます。これは、あとで考慮することにします。
　出力が、音か、音と映像のみの既存製品とは何があるでしょうか？それらが、スマートスピーカーによって置き換えられる可能性がある既存製品です。ざっと上げると、タイマー、時計、ラジオ、などです。

■タイマー、時計
　・ スマートスピーカー のほうは複数同時にタイマーが設定できるとか、スケジュールに連携とか可能です。
　・「タイマー」については特にメリットが思いつきません。電源がなくても使えるというくらいです。スマートスピーカーの「ｘｘ分タイマー」の使い方を体験すると、時間を指定したうえでスタートボタンを押すなど操作が煩雑と感じるでしょう。

■ラジオ
　・電波状態を気にすることなく明瞭な音で聞くことができます。録音に相当するタイムフリー機能が提供されていないことと、他の都道府県の局は受信制限がかかっている点は何とかしたいところですが、ラジオでも他県の電波を良質な音で聞けることはあまりないことを考えると不便とまでは言えないでしょう。

■以下にざっと挙げて、色分けしました。
青：すでにスマートスピーカー単体で代替できているもの。
黒：すでにスマートスピーカーと外部機器が連携して機能提供しているもの
赤：形を変えて対応しているもの

●楽器
●ウォークマン
●テレビ
●オーディオ製品、音響機器
●温度計、湿度計
●鏡
●カレンダー
●写真立て、フォトフレーム
●ゲーム、将棋盤
●新聞
●血圧計、体温計
●図鑑、本、辞書、電話帳、地図
●スキャナ
●ストップウォッチ
●スピーカ
●双眼鏡、望遠鏡
●そろばん
●体脂肪計、体重計
●タイプライター
●カメラ
●アルバム
●手帳
●電卓
●電話機
●投影機
●トランシーバー、無線機
●ノート、紙
●メガホン
●ラジオ、ラジカセ

上でざっと洗い出してみましたが、つぎのように漏れているものを見つけました。とくにスマートスピーカーで置き換えできそうなものです。まだまだピックアップし漏れたものがたくさんありそうです。電気製品の中に多いと思います。
・インターホン
ちなみに、インターホン相当の機能は私がグーグルに機能強化提案し2週間後くらいに密かにリリースされていました。私は、そのまえに「google home→googleアシスタント→IFTTT→node.js→google home」の流れでインターホン機能を実装できていました。

まだ十分とは言えませんが、スマートスピーカー単体で代替可能そうな機能はほぼ実装されています。使いにくいところは改善依頼をだして強化していけば、スマートスピーカーだけでのシンプルライフを送れそうです。

本格的なスマートホームへの移行までの対応例、SwitchBotでテレビをリセット

今回、紹介するのは取り付け作業に電気工事士などの資格が不要な製品です。物理的にスイッチ操作を行います。接着テープで貼り付けて、小さなサーボ機構でスイッチ部分を上下するので、 電灯のスイッチをON,OFFくらいならできます。コンセントなどにある電源スイッチの操作は厳しいでしょう。 しかし、資格が必要な作業が不要なので誰でも手軽に利用できます。まだまだ国内メーカ製のスマートスイッチは機種が少ないので、現状はSwitchBotを活用するシーンは多いでしょう。今後スマーススイッチが一般化していくことを考えれば、SwitchBotは過渡期の製品といえるでしょう。

SwitchBotは１回の操作で押すだけの操作、ONとOFFの動作、つまりワイドハンドルのスイッチの動作と、波型スイッチ（トグル）のON/OFFの動作の２つの動作モードがあります。工夫次第で、いろんな使い方ができそうです。

　テレビがハングアップしてしまいリモコン操作を受け付けなくなる事象が頻繁に発生して、そのたびにリセット操作をしていたので、SwitchBotにリセットボタンを押させるようにしてみました。下の写真がその取り付け例です。

SwitchBotのスイッチ部分にグルーガンで5mmほどの突起を作成して、リセットボタンを押せるように位置調整して取り付けました。
これに加えて、IFTTT連携、Google home連携も行いました。これにより、「ねぇ グーグル テレビをリセットして」というと、リセットボタンを押してくれます。

　SwitchBot自体はBluetoothで通信するので、SwitchBot単体ではスマートホンとかタブレットがないとうごきません。そこで、下のSwitchBotハブと組み合わせて使用します。

次のような構成で動作します

SwitchBot
　 ↓ Bluetoothで通信
SwitchBotハブ
↓ WiFiで通信
無線LAN ルータ
↓ 光ケーブルや有線LANなど
インターネット
↓
SwitchBotのサーバ ←→ IFTTTのサーバなど

最近は、SwicthBotハブプラスなども提供されているのでIFTTTの他のサービスと組み合わせるなどの工夫でもっと色々使えます。


　それから、気が付かないうちに録画機能だけハングアップしていて予約録画できていなかったこともありました。そこで、まず視聴や予約録画していなさそうな午前４時に毎日自動的にリセットするようにIFTTTのルールを作成しました。これにより、ハングアップ状態でずっと録画できないままという事象も回避できました。

話は、SwitchBot自体に戻りますが、 SwitchBot は内蔵の電池で動作します。最初は蓋の隙間から横に飛び出している絶縁ビニールを抜いて電源をいれます。電源を切る仕組みはありません。もちろん電池を抜けばよいのでしょうが普通に使うならそんなことはしないので入れっぱなしです。１日に１回か２回くらいの操作をして、１年くらいで電池が切れました。ちなみにほとんど使っていなくても１年くらいで電池が切れました。

中に入っている電池はつぎのようにCR2 Lithium Battery CR15H270 3Vです。電池が切れたときはこれを交換します。近くのホームセンターで1個 448円で交換用の電池を購入しました。

使うときは、電気交換のことも考えながら使ったほうがよさそうです。接着テープは一度剥がすと接着力が落ちるので、手が届きにくいとか、一度SwitchBotの本体をとりだす必要があるなど、いちど接着テープを剥がさないと電池交換できないような場所には不向きです。
　　ただ、そういう場所にこそ使いたいかもしれません。

Hyper-V上に Ubuntuで開発支援環境を整備する

方針：
　Windows10環境上にLinux（Ubuntu18.04）ベースで開発支援環境を整備する。開発環境のため長期間安定運用できる見込みの18.04を採用しています。

■１．Hyper-Vが使える状態にWindowsを構成しなおします。
PROとか上位エディションでないと使えません。
次を参考に設定する
「Hyper-Vの使い方 Windows 10にWindows 7インストール」
上の手順で特に補足はありません。

■2.Hyper-Vに UbuntuのVMを作成、インストールします。
「Hyper-V で無線 LAN のみの PC でもネットワーク接続できるようにする方法」
補足：上の手順の設定のままやるとメモリが不足する可能性が高い。起動メモリは自分のマシンのメモリサイズに合わせて決めてください。ホストOSにもメモリが必要なので半分程度を基準に、使い方に合わせて調整して割り当ててください。例えば全メモリサイズが8GBなら4GBを割り当てるといった具合に調整してください。

■おまけ：
ここで、VMから無線WiFiデバイスが使えるか確認してみました。
「Hyper-V で無線 LAN のみの PC でもネットワーク接続できるようにする方法」などの情報があります。そりゃそうだ、というか、デバイスはホストOSが管理しているのでゲストOSには直接見えませんよね。つまり、無線WiFiで通信することはできるが、それはブリッジを介して接続するのでUbuntuからはブリッジ接続が有線接続のように見えるということです。よって、やりたいホットスポットとして使用することはできない。 Windows10で起動したホットスポットに対してブリッジ接続することでそれらしい動きはできそうです。しかし、これも Ubuntuからは有線接続として見えるのでUbuntuからはWiFiデバイス操作はできず目的を果たせません。

■3.terminalから ツールを追加インストールする
・まずネットワークの状態を確認するためにnet-toolsをインストールする
sudo apt install net-tools
　　→ ifconfigで IPアドレスなどを確認する
・ホストOSから軽るーくsshで操作したいので、sshをインストールする。
sudo apt install ssh
　→ ここまでの設定で特に追加設定しなくてもホストOSから上で確認したIPに対してSSHで接続ができます。ここから下はsshからの操作でも作業できます。
・Ubuntuのメモリ消費量を削減するためにCUIで起動するように変更する
sudo systemctl set-default multi-user.target
　→VMを再起動すればCUIで起動する
・開発用のツールを導入する
sudo apt install build-essential
　　→これだけで大丈夫そう。さきに下の４つのインストールを実施し後述の問題が発生したので、上インストールも実施、build-essentialのみの動作は未確認
sudo apt install git
sudo apt install make
sudo apt install make-guile
sudo apt install gcc
　　→ここまでとりあえずは構築完了。　以下はビルド確認での問題。

■4.ビルドでの確認
つぎのページを参考にrtl8188eusのドライバをビルドしてみる。
https://ficus.myvnc.com/ja/blog/RTL8188%E3%81%AB%E3%82%88%E3%82%8BOrangePi%E3%81%AE%E3%83%AB%E3%83%BC%E3%82%BF%E5%8C%96Vol.2_b82

$ git clone –single-branch –branch v5.2.2.4 https://github.com/capitalfuse/rtl8188eus.git
$ cd rtl8188eus
$ make

次のようにビルドに失敗


hbox@hbox-Virtual-Machine:~$ git clone –single-branch –branch v5.2.2.4 https://github.com/capitalfuse/rtl8188eus.git
Cloning into ‘rtl8188eus’…
remote: Enumerating objects: 1173, done.
remote: Total 1173 (delta 0), reused 0 (delta 0), pack-reused 1173
Receiving objects: 100% (1173/1173), 3.71 MiB | 1.44 MiB/s, done.
Resolving deltas: 100% (693/693), done.
hbox@hbox-Virtual-Machine:~$ cd rtl8188eus
hbox@hbox-Virtual-Machine:~/rtl8188eus$ make
make ARCH=x86_64 CROSS_COMPILE= -C /lib/modules/5.0.0-25-generic/build M=/home/hbox/rtl8188eus modules
make[1]: ディレクトリ ‘/usr/src/linux-headers-5.0.0-25-generic’ に入ります
CC [M] /home/hbox/rtl8188eus/core/rtw_cmd.o
CC [M] /home/hbox/rtl8188eus/core/rtw_security.o
CC [M] /home/hbox/rtl8188eus/core/rtw_debug.o
CC [M] /home/hbox/rtl8188eus/core/rtw_io.o
CC [M] /home/hbox/rtl8188eus/core/rtw_ioctl_query.o
CC [M] /home/hbox/rtl8188eus/core/rtw_ioctl_set.o
CC [M] /home/hbox/rtl8188eus/core/rtw_ieee80211.o
CC [M] /home/hbox/rtl8188eus/core/rtw_mlme.o
CC [M] /home/hbox/rtl8188eus/core/rtw_mlme_ext.o
CC [M] /home/hbox/rtl8188eus/core/rtw_mi.o
CC [M] /home/hbox/rtl8188eus/core/rtw_wlan_util.o
CC [M] /home/hbox/rtl8188eus/core/rtw_vht.o
CC [M] /home/hbox/rtl8188eus/core/rtw_pwrctrl.o
CC [M] /home/hbox/rtl8188eus/core/rtw_rf.o
CC [M] /home/hbox/rtl8188eus/core/rtw_recv.o
CC [M] /home/hbox/rtl8188eus/core/rtw_sta_mgt.o
CC [M] /home/hbox/rtl8188eus/core/rtw_ap.o
CC [M] /home/hbox/rtl8188eus/core/rtw_xmit.o
CC [M] /home/hbox/rtl8188eus/core/rtw_p2p.o
CC [M] /home/hbox/rtl8188eus/core/rtw_tdls.o
CC [M] /home/hbox/rtl8188eus/core/rtw_br_ext.o
CC [M] /home/hbox/rtl8188eus/core/rtw_iol.o
CC [M] /home/hbox/rtl8188eus/core/rtw_sreset.o
CC [M] /home/hbox/rtl8188eus/core/rtw_btcoex_wifionly.o
CC [M] /home/hbox/rtl8188eus/core/rtw_btcoex.o
CC [M] /home/hbox/rtl8188eus/core/rtw_beamforming.o
CC [M] /home/hbox/rtl8188eus/core/rtw_odm.o
CC [M] /home/hbox/rtl8188eus/core/efuse/rtw_efuse.o
CC [M] /home/hbox/rtl8188eus/os_dep/osdep_service.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/os_intfs.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/usb_intf.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/usb_ops_linux.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/ioctl_linux.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/xmit_linux.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/mlme_linux.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/recv_linux.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/ioctl_cfg80211.o
/home/hbox/rtl8188eus/os_dep/linux/ioctl_cfg80211.c: In function ‘rtw_get_systime_us’:
/home/hbox/rtl8188eus/os_dep/linux/ioctl_cfg80211.c:354:2: error: implicit declaration of function ‘get_monotonic_boottime’; did you mean ‘getboottime’? [-Werror=implicit-function-declaration]
get_monotonic_boottime(&ts);
^~~~~~
getboottime
cc1: some warnings being treated as errors
scripts/Makefile.build:284: recipe for target ‘/home/hbox/rtl8188eus/os_dep/linux/ioctl_cfg80211.o’ failed
make[2]: *** [/home/hbox/rtl8188eus/os_dep/linux/ioctl_cfg80211.o] Error 1
Makefile:1606: recipe for target ‘module/home/hbox/rtl8188eus’ failed
make[1]: *** [module/home/hbox/rtl8188eus] Error 2
make[1]: ディレクトリ ‘/usr/src/linux-headers-5.0.0-25-generic’ から出ます
Makefile:1911: recipe for target ‘modules’ failed
make: *** [modules] Error 2
hbox@hbox-Virtual-Machine:~/rtl8188eus$

同様に別のページを参考に他のドライバをビルドしてみたが別のエラーで失敗した。

$ make
make ARCH=x86_64 CROSS_COMPILE= -C /lib/modules/5.0.0-25-generic/build M=/home/hbox/rtl8188fu modules
make[1]: ディレクトリ ‘/usr/src/linux-headers-5.0.0-25-generic’ に入ります
CC [M] /home/hbox/rtl8188fu/core/rtw_cmd.o
In file included from /home/hbox/rtl8188fu/include/osdep_service.h:41:0,
from /home/hbox/rtl8188fu/include/drv_types.h:32,
from /home/hbox/rtl8188fu/core/rtw_cmd.c:22:
/home/hbox/rtl8188fu/include/osdep_service_linux.h: In function ‘_init_timer’:
/home/hbox/rtl8188fu/include/osdep_service_linux.h:273:8: error: ‘_timer {aka struct timer_list}’ has no member named ‘data’
ptimer->data = (unsigned long)cntx;
^~
/home/hbox/rtl8188fu/include/osdep_service_linux.h:274:2: error: implicit declaration of function ‘init_timer’; did you mean ‘_init_timer’? [-Werror=implicit-function-declaration]
init_timer(ptimer);
^~~~~~
_init_timer
In file included from /home/hbox/rtl8188fu/include/drv_types.h:35:0,
from /home/hbox/rtl8188fu/core/rtw_cmd.c:22:
/home/hbox/rtl8188fu/include/wifi.h: At top level:
/home/hbox/rtl8188fu/include/wifi.h:1009:0: warning: “IEEE80211_MAX_AMPDU_BUF” redefined
#define IEEE80211_MAX_AMPDU_BUF 0x40

In file included from /home/hbox/rtl8188fu/include/osdep_service_linux.h:84:0,
from /home/hbox/rtl8188fu/include/osdep_service.h:41,
from /home/hbox/rtl8188fu/include/drv_types.h:32,
from /home/hbox/rtl8188fu/core/rtw_cmd.c:22:
./include/linux/ieee80211.h:1444:0: note: this is the location of the previous definition
#define IEEE80211_MAX_AMPDU_BUF 0x100

cc1: some warnings being treated as errors
scripts/Makefile.build:284: recipe for target ‘/home/hbox/rtl8188fu/core/rtw_cmd.o’ failed
make[2]: *** [/home/hbox/rtl8188fu/core/rtw_cmd.o] Error 1
Makefile:1606: recipe for target ‘module/home/hbox/rtl8188fu’ failed
make[1]: *** [module/home/hbox/rtl8188fu] Error 2
make[1]: ディレクトリ ‘/usr/src/linux-headers-5.0.0-25-generic’ から出ます
Makefile:1679: recipe for target ‘modules’ failed
make: *** [modules] Error 2



エラー内容をもとに調べてみると、
https://forum.manjaro.org/t/solved-error-with-rtl8812au/24066/2
https://github.com/smlinux/rtl8723de/issues/13
ドライバーのソースとカーネルバージョンの不一致が原因と言っている。
そこで、カーネルバージョンを確認する。→「カーネルバージョンの確認方法」

$ uname -a
Linux hbox-Virtual-Machine 5.0.0-25-generic #26~18.04.1-Ubuntu SMP Thu Aug 1 13:51:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

対象のカーネルバージョン用のドライバソースをビルドしてみます。
https://github.com/FreedomBen/rtl8188ce-linux-driver
→このソースは4.20にも対応しているとコメントがあるのでこれで試します



$ git clone https://github.com/FreedomBen/rtl8188ce-linux-driver.git
$ cd rtl88188xce-linux-driver/
$ make

ビルドに成功しました。　やはり、ドライバーソースが対象のカーネルバージョンに対応していなかったことが原因でした。