この記事は「Android 7.0/EMUI 5.0のNova lite（PRA-LX2）」用に書かれています。他のHUAWEIの端末でも似たような方法で大丈夫だと思いますが、Android 8.0(Oreo)は色々と違います。ご注意ください。
なお「nova lite」は日本国内での販売名で、海外では「P8 lite 2017」「Honor 8 Lite」という名称で売られています。また開発コード（？）の「PRAGUE」やチップセットを示す「Hi6250」も併記されることがあります。海外情報を探すときはこれらの名称で検索しましょう。
この操作は最悪スマホが起動しなくなりますので必ず自己責任で。
HUAWEI nova liteをうっかり文鎮化してしまったので、復旧方法（復旧手段）のまとめメモ。ちなみに海外では文鎮化のことを「Brick」（レンガ化）と言うようです。
fastboot oem relock 0421234567897012
ルーティングテーブル書き換え（route）によるアクセス制御から、unboundによるDNSの一部書き換えに移行したメモ。
LAN内のLinuxマシンを、家庭用ルータのポートマッピングを使って外部公開している状況を想定しています。小規模の会社とかでも、こういう設定をされていることがありますね。
この場合、内側のPCから外部公開時のホスト名である「global.my.ip」にアクセスするとグローバルIPを引いてしまいます。そして、PCからルーターの外側IPにアクセスすることになるのですが、NEC等のルータではこの際ポートマッピングが有効にならずアクセス不能となります。*1
ルータのルーティングテーブルを書き換えることができれば色々と解決策はあるのですが、そんな機能を持った機種はまずありません……。*2
どうにもならないので、PCを起動するたびに、外部IPを確認して、外部IPにアクセスするときはLinuxサーバ（192.168.1.8）にルーティングするような設定をしていました。
@echo off ' route-add.bat for /f "usebackq tokens=2 skip=1" %%i in (`nslookup global.my.ip 192.168.1.1 ^| findstr "[0-9]\.[0-9]"`) do set IP=%%i route add %IP% 192.168.1.8
これで、PCから外部IP向けのパケットがLinuxサーバに向かうので、Linuxサーバ側でNAT処理をします。
MY_LOCAL="192.168.1.2"
MY_GLOBAL=`dig +short global.my.ip`
#---------------------------------------------------------------------------
# Special forward for myself
#---------------------------------------------------------------------------
iptables -t nat -A OUTPUT -d $MY_GLOBAL -s $MY_LOCAL \
-j DNAT --to-destination $MY_LOCAL
#---------------------------------------------------------------------------
# Special forward for local network
#---------------------------------------------------------------------------
iptables -t nat -A PREROUTING -d $MY_GLOBAL -s $MY_LOCAL/24 \
-j DNAT --to-destination $MY_LOCAL
これで無事アクセスはできるのですが、スマホ等からのアクセスは断絶されたままでした。
unboundというDNSキャッシュサーバには、特定のホスト名やドメインだけ、DNSの結果を書き換える機能が付いています。
本当は外部IPでのアクセスがすべてLinuxサーバに転送されるのが理想なのですが、そうも言ってらもないので、この方法で解決を試みました。以下、Debianサーバでの設定例です。
sudo su apt-get install unbound
/etc/unbound/unbound.conf を編集して以下を追加します。
server:
interface: 0.0.0.0
access-control: 127.0.0.1 allow
access-control: 192.168.0.0/16 allow
続いて /etc/unbound/unbound.conf.d/global.my.ip.conf というファイルを新規作成します。
local-data: "global.my.ip A 192.168.1.8"
作成したら unbound にリロードさせます。
service unbound reload
$ dig @localhost global.my.ip ;; ANSWER SECTION: global.my.ip. 3600 IN A 192.168.1.8
ルータのDHCPの設定を書き換えて、DNSのプライマリサーバに 192.168.1.8 を指定します。セカンダリは 192.168.1.1 を指定しておくと良いでしょう。
NECのルータは性能は悪くないけど、細かい設定ができないのでちょっと面倒ですね。
UPnPタイムアウトを設定できないし（高級機のみ可）。Buffaloのほうがいいのかもしれない。ポート転送が内側に対しても効いた気がするし。
そしてdd-wrt対応のルータ使ってみたい。
さていつものラズパイ用DACですが、最新のVolumio2をちょっと入れて試してみました。
昔（といっても2年ぐらい前）は、オーディオ用ディストリビューションと言ってもVolumioぐらいしか認知されてなくて、事実上他に選択肢はありませんでした。
まあ色々と使いにくい点もあったのですが、カスタマイズして使っているうちにちょうどよくなってそのまま使い続けたという。
他のディストリビューションはどうにも肌に合わず、当時Volumio2のβ版は使い勝手が悪くて結局そのままという状況でしたので、一念発起して使ってみることにしました。*1
入れてみるとさすがに完成度が高く、これなら完全に乗り換えても良いですね。
msBerryDACはHiFiBerry DAC+ PRO互換ですが、このPRO付きとPROなしはドライバが共通になっています。
| HiFiBerry DAC+ | 外部クロックなし |
| HiFiBerry DAC+ PRO | 外部クロックあり |
この判別はドライバ側で行っていて、音が鳴っていても外部クロックが正しく使われているかはソフトからでは分かりません。ドライバ側で認識方法が狂っていたりすると、外部クロックが使われずに音が再生されたり、狂ったクロック（速度）で音が再生されてしまいます。
これを確実に確認するには、発振器（やクロック）の端子にテスター等を当ててクロックがきちんと動作しているか確認するしかありません。
というわけで、最新のVolumio2で外部クロックの動作を確認しました。ついでに分かったことですが、リサンプリングをオフにしておいても、リサンプルされて48k系列のクロックで再生されているようです。
β版当時には存在しなかったアップサンプリングを設定して、384KHz/32bitで再生できているのか確認しました。
まずは96KHz/32bit再生から。
BCLK（ビットクロック）端子を観測しています。BCLKとは音楽データを1bit送るためのクロック信号です。96KHz/32bit再生では、
96KHz × 32bit × 2ch(L/R) = 6.144Mbit/sec
つまり 6.144MHz のBCLKが必要になります。オシロの観測画像を見ると6.144MHzの信号が出ているので、きちんと96KHz/32bitで動作していることが分かります。
続いて192KHz/32bit。
192KHz × 32bit × 2ch(L/R) = 12.288Mbit/sec
そして384KHz/32bit。
192KHz × 32bit × 2ch(L/R) = 24.576Mbit/sec
ということで、24.576MHzのBCLKが出ています。
Volumio Ver1では、msBerryDACで384再生はソフトに手を入れない限り無理だったので確認していなかったのですが、Volumio2により無事384KHz/32bit再生されていることを確認できました。
Volumio2のアップサンプリングって「768KHz再生」も設定できるのです。興味そそられますよね！
もちろん試して見しまたが、無理でした（笑）。設定自体はできるし、その状態で再生もできるのですが、768KHzに設定してもBCLK=24.576MHzだったので384/32で再生されてるだけでした。
よく考えたら、載ってるクロックが24.576MHzなのでこれ以上のBCLKはどうやっても無理に決まってた（笑）*2
ちなみに、波形が鈍っているのはプローブの設定間違えたせい……。