ASUS VivoBook E203NAにWindows10とChromeOSを入れた

秋葉原のMLcomputerにいったら整理中の箱の中にASUSの薄いノートが入っていた。

電源ボタンおしてみたけど、電源は入らない、という状態だったけど、「これいくら?」と聞いて見た。

すると、「ASUS E203MA(あとで調べたらCPUがN4000とちょっとスペックが上)でキーボードが使えないジャンク品を3千円としている」ということだったので、3千円で購入した。

裏面みるとネジが1つなく、1つがセロテープで無理矢理とめられていた。

んー、と思いつつ電源ON

F2キーでBIOS/UEFI画面に入ることができた。

スペックを確認するとASUS VivoBook E203NA の下位モデルでCPU N3350、RAM 2GB、eMMC 32GBというものだった。

メインストレージが64GB未満なのは現状Windows10で使うにはキツイものでした。

Windows 10 21H1をインストールして一通りWindows Updateをかけるとデバイスは全て正常に認識しましたが、問題が・・・

そう、OSだけでほぼ全て使ってしまうのです。

あと、注意点として、Windows 10インストール直後のQualcomm Atheros QCA9377ドライバだとバッファローWSR-1800AX4の802.11ax Wi-Fi EasyMesh対応版に接続出来ないという不具合が・・・

Windows Updateを行って下記のv12.0.0.919にアップデートすると接続出来るようになります。

このほかWebブラウザでサイトを見たりしていたら空き容量が2GBを切っているという・・・

裏面のネジがおかしいのもあるので中を確認

増設の余地は全くない構造でした。

基板がどうなっているかは下記の動画をみてもらうと良さそうです。

なお、ネジがちゃんとついていなかったのは、ネジの長さが2種類あって、2本だけ長いものがあるんですが、その2本の使いどころを誤っていたせいでした。

正しくは下記の画像の赤丸の2箇所なんですが、分解した人は下側左右両サイドに使っていました。

さて、ストレージ増設なんてことはできそうにないので、ChromeOS+brunchで起動してみます。

まずはBIOSでSecurebootをdisableにかえてから、Boot ManagerからUSBメモリを選択して起動します。(電源ON後にいきなりBoot Managerを出す手法は分からなかった)

ChromeOSリカバリイメージはrammus、grubで設定するoptionsは「options=enable_updates,pwa」だけでいけるというなかなか素直な状態でした。

Ctrl+Alt+Tからshellを開いて「sudo chromeos-install -dst /dev/mmcblk0」で内蔵ストレージにChromeOSを書き込んで、本体のみでのChromeOS起動を確認しました。

興味深かったのは、いままでbrunchでrammusイメージを元にしてChrome OSで起動したノートパソコンでGoogleアカウントログインを行うと「お使いの Chome OSで~」というメールが来てたのですが、ASUS VivoBook E203NAにChromeOSを入れたやつでは「お使いの ASUS Chromebook Flip C434で~」と、機種名が書かれたメールになっていた。

ベースとしているrammusは「ASUS Chromebook C425, ASUS Chromebook Flip C433, ASUS Chromebook Flip C434」向けイメージなので、わからなくもないんですが

ASUS Chromebook Flip C434 はCore m3-8100Y/RAM 4GB/ストレージ 32GB/14.0インチ1920*1080/タッチパネルあり、とだいぶスペックが違うのになぁ・・・といった感じです。


2022/05/06追記

Google純正となった「Chrome OS Flex」をASUS VivoBook E203NA上で試したところ、特に問題なく動作しました。


2022/07/20追記

ChromeOS Flexの正式版を入れてみましたが、引き続き特に問題無く動作しました。

入れ替え前は5月にインストールしたベータ版時代のものでしたが、そのときは「104.0.5087.0 (Official Build) dev (64ビット)」という状態で、チャンネルが固定となっており、devからstableへの移行ができませんでした。

正式版に入れ直したところ103.0.5060.114 とdev無しのバージョンとなりました。

Oracle CloudでARMインスタンスが開始されたのでIPv6アクセスできるサーバとして構築してみた

Oracle CloudでARMインスタンスの提供が開始された。

Arm-based cloud computing is the next big thing: Introducing Arm on Oracle Cloud Infrastructure

Ampere A1を使用したものらしい。

今日から使える、といってるけど、さすがに東京リージョンには来てないだろうと思いつつコンソールを開いてみる。

画像

え!?東京でも作成できんじゃん!と作成開始

まず、Always Freeアカウントではどういうスペックが作れるのか?を確認→「Always Free Resources

画像

なんとCPU 4個/RAM 24GBまでいけるらしい。

すでに、これまでのAlways Freeアカウントの上限である、VM.Standard.E2.1.Micro インスタンスで2個作っていても、それとは別カウントでARMのVM.Standard.A1.Flexが作れるようだ。

画像
画像
画像

標準ではOracle Linux 7.9が選択されている。他の選択肢を見てみる。

画像

「イメージビルド」に記載がないものは選べないようだ。このため、Oracle Autonomous Linux は選択できなかった。

Oracle Linux 8 にすることはできるようだ。

インスタンスのshapreは変更可能

その他の項目はいままでのインスタンス作成となんら変わらず。

完成するとこんな感じ

画像

「Always Free」というマークがついてない・・・

不安になったのでいろいろ試行錯誤

画像

既存のVM.Standard.E2.1.Microインスタンスを1個けして作り直してもA1.FlexインスタンスにAlways Freeマークがつくわけではないようだ。

かといって、VM.Standard.E2.1.Microインスタンスが2個ある状態で3個目をつくろうとすると、有料アカウントへのアップグレードが必要と表示されるので、有料になっているわけではない模様。

画像

じゃあ、ARMインスタンスを複数個立てられるのかな?と実行してみると、作成は可能なものの直ちに終了して使えないという状態

既存インスタンスのシェイプの変更を選び

変更することは可能

変更が反映されました。

ほんとにこれで大丈夫なのかなぁ???と悩むところではありますが、ドキュメント通り、「VM.Standard.E2.1.Micro インスタンスを2個」と「ARMのVM.Standard.A1.Flexインスタンスを4CPU/メモリ24GBの範囲内」で作成することができる、ということのようです。

また、ARMインスタンスについては、作成後、CPU/メモリスペックを変更する事が可能でした。

2021/05/27訂正

ドキュメント上は「All tenancies get two public IPv4 addresses for Always Free compute instances」となっていますが、動作検証をしてみたところ、パブリックIPアドレスの上限個数が3となっているようです。

パブリックIPアドレスの割り当てをやめてみたところARMインスタンス(VM.Standard.A1.Flex)を4つ作ることができました。

画像

IPv6設定メモ

4月から使える様になったIPv6ですが「Oracle Cloudですでに作成済みのネットワークに対してIPv6を有効にする方法」に示した手順で有効化したところ、DHCPv6でのIPv6アドレス取得が失敗しました。

手動であれば設定できたので、ARMインスタンスが存在するネットワークへのDHCPv6が正常に動作していない模様です。

設定としては、Oracle Cloudコンソールの[インスタンスの詳細]-[アタッチされたVNIC]-[VNICの詳細]にある[リソース]-[IPv6アドレス]にて、インスタンスにIPv6アドレスを割り当てる。

また、2021/05/26時点でのOracle Linux 7提供イメージでは、IPv6アドレスが有効化されていないため、インスタンス内のOS設定を変更する必要があり、DHCPv6アドレス取得ができなかったので、disable-ipv6.confと01_ipv6を作成した。
Oracle Linux 8だとIPv6有効化されていたがDHCPv6アドレス取得ができなかったので01_ipv6を作成したfirewalldにdhcpv6-clientの設定がされていないのでDHCPv6アドレス取得に失敗していたので設定を変更した。
Ubuntu 20.04ではIPv6有効化されておりDHCPv6アドレス取得はできたものの起動時に自動取得はしなかったので01_ipv6を作成しdhclient -6の方を有効にした。

disable-ipv6.confの手順

/etc/sysctl.d/disable-ipv6.conf を作成し、下記を記載

net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0

01_ipv6の手順

/var/lib/cloud/scripts/per-boot/01_ipv6 を作成し、下記を記載

#/bin/bash
#dhclient -6
ip -6 addr add xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/128 dev enp0s3

DHCPv6が使える様になった場合は、ip行の先頭に#を入れ、dhclientの前の#を外すこと。

また/var/lib/cloud/scripts/per-boot/01_ipv6には下記の様に実行権限を与えること

# chmod a+x /var/lib/cloud/scripts/per-boot/01_ipv6 

firewalldにdhcpv6-clientを追加する手順

serviceとしてdhcpv6-clientを追加する、という手順。Oracle Linux 7だと標準で設定されていたが、2021/05/27時点でのOracle Linux 8 ARM環境だと設定されていなかった。

$ sudo firewall-cmd --permanent --add-service=dhcpv6-client
success
$ sudo firewall-cmd --reload
success
$ sudo firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp0s3
  sources:
  services: dhcpv6-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
$

簡易的なセキュリティ対策

インスタンスを稼働させておくとsshへのアタックが凄い数来ます。

標準設定では秘密鍵持ってないとログインできないので影響は少ないですが、アクセスができる状態だといつまでもリトライを繰り返してきます。このため、fail2banを使って拒否することで、アタック側のブラックリストに載せて攻撃者数を減らしてみよう、という試みです。

$ sudo yum install fail2ban
$ sudo vi /etc/fail2ban/jail.local
$ sudo cat /etc/fail2ban/jail.local
[DEFAULT]
# 86400秒=24時間以内に5回不審なアクセスがあったら24時間BAN
bantime  = 86400
findtime  = 86400
maxretry = 5
# 259200秒=3日以内に5回不審なアクセスがあったら3日間BAN
#bantime  = 259200
#findtime  = 259200
#maxretry = 5

# 除外IP
ignoreip = 127.0.0.1 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16

[sshd]
enabled = true
banaction = firewallcmd-ipset

$ sudo systemctl enable fail2ban
$ sudo systemctl start fail2ban
$

おまけ情報

インスタンス内でlscpuを実行した結果

Oracle Linux 7の場合

$ sudo lscpu
Architecture:          aarch64
Byte Order:            Little Endian
CPU(s):                1
On-line CPU(s) list:   0
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             1
NUMA node(s):          1
Model:                 1
BogoMIPS:              50.00
NUMA node0 CPU(s):     0
Flags:                 fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs
$

Oracle Linux 8 (Oracle-Linux-8.3-aarch64-2021.05.12-0) 初期状態の場合

$ lscpu
Architecture:        aarch64
Byte Order:          Little Endian
CPU(s):              1
On-line CPU(s) list: 0
Thread(s) per core:  1
Core(s) per socket:  1
Socket(s):           1
NUMA node(s):        1
Vendor ID:           ARM
Model:               1
Stepping:            r3p1
BogoMIPS:            50.00
NUMA node0 CPU(s):   0
Flags:               fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs
$

Oracle Linux 8 (Oracle-Linux-8.3-aarch64-2021.05.12-0) でdnf updateした後の場合

$ sudo lscpu
Architecture:        aarch64
Byte Order:          Little Endian
CPU(s):              1
On-line CPU(s) list: 0
Thread(s) per core:  1
Core(s) per cluster: 1
Socket(s):           1
Cluster(s):          1
NUMA node(s):        1
Vendor ID:           ARM
BIOS Vendor ID:      QEMU
Model:               1
Model name:          Neoverse-N1
BIOS Model name:     virt-4.2
Stepping:            r3p1
BogoMIPS:            50.00
NUMA node0 CPU(s):   0
Flags:               fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs
$

Oracle Linux 8で4CPU/24GBにした場合

$ sudo lscpu
Architecture:        aarch64
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per cluster: 4
Socket(s):           1
Cluster(s):          1
NUMA node(s):        1
Vendor ID:           ARM
BIOS Vendor ID:      QEMU
Model:               1
Model name:          Neoverse-N1
BIOS Model name:     virt-4.2
Stepping:            r3p1
BogoMIPS:            50.00
NUMA node0 CPU(s):   0-3
Flags:               fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs
$

Ubuntu 20.04の場合

$ sudo lscpu
Architecture:                    aarch64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
CPU(s):                          1
On-line CPU(s) list:             0
Thread(s) per core:              1
Core(s) per socket:              1
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       ARM
Model:                           1
Model name:                      Neoverse-N1
Stepping:                        r3p1
BogoMIPS:                        50.00
NUMA node0 CPU(s):               0
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled v
                                 ia prctl
Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
Vulnerability Spectre v2:        Not affected
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fp asimd evtstrm aes pmull sha1 sha2 crc32 atom
                                 ics fphp asimdhp cpuid asimdrdm lrcpc dcpop asi
                                 mddp ssbs
$

NanoPi R2S+openWRT 21.02.0RCでBIGLOBEのMAP-E接続

2021/09/14追記

OpenWRT 21.02.0リリース版にてだいぶ手順が変わってしまったので、あたらしく「NanoPi R2S+OpenWRT 21.02.0でBIGLOBEのMAP-E接続」として修正しています。

この記事は古い内容となります。


GL.iNET GL-MV1000を使っていたわけですが2020年8月以降IPv6が無効化、そのまま放置され、2021年4月になって再度有効化されたものの、GL.iNETが提供する機能以外の部分はほぼ切り捨てられてしまいました。

GL.iNET firmwareの駄目なところ
・GL.iNET UIで提供されている機能はGL.iNET側で有効化しないとluci側で行った設定が有効にならない(DynamicDNSやIPv6など)
・追加したパッケージはfirmwareバージョンアップ時に削除される(GUI上はパッケージを追加する、とか表示されるけど追加されたことはない)
・GL.iNet ver 3.201だとluci パッケージがインストールされていないため詳細設定が出来ない
・パッケージを追加するにはネットワーク接続が必須だがGL.iNET UIだと詳細設定ができないのでネットワーク接続ができない場合がある

そんな状況が約1年続いたわけなので、さすがに諦めました。

代替としてRockchip RK3328のNanoPi R2S と Rockchip RK3399のNanoPi R4S を候補にあげた。

Amazon日本の倉庫に在庫があるというのと、openWRTのページに「FriendlyARM NanoPi R2S」とデバイスに関する個別ページが作成されており、snapshotの提供がされていたので、NanoPi R2Sを買って設定を行った。

画像
画像

ちなみに置き換え対象となったGL-MV1000とのサイズ比較はこんな感じ

画像
画像

さて、openWRTの設定を行ったタイミングではopenWRT 21.02.0 rc1の提供が開始されていたのでそちらを使用した。(2021/07/12追記 openWRT 21.02.0 rc3は壊れているようでLANポートが稼働しないので使わないこと。やるのであればrc2)

friendlyarm_nanopi-r2s-squashfs-sysupgrade.img.gz を展開したものをmicroSDに書き込んでNanoPi R2Sを起動した。

設定手順1:パッケージの追加

mapパッケージと日本語UIパッケージ(luci-i18n-base-ja)をインストール

CLIでインストールする場合は以下を実行

# opkg update
# opkg install luci-i18n-base-ja
# opkg install map

インストール後は再起動を行うこと。

再起動しないとluciのネットワーク設定で「プロトコル:MAP / LW4over6」が選択肢に現れません。

設定手順2:WAN6インタフェースの作成

WAN6インタフェースがなければ「プロトコル: DHCPv6クライアント」で作成する

最初はそのまま設定して、有効化し、WAN6インタフェースに割り当てられるIPv6アドレスを確認すること。

↑の画像は使い回しなので、この段階では無いはずの「MAP」インタフェースが入ってます

上記のように「IPv6」アドレスが確認できたら、そのアドレスをコピーして、[詳細設定]の「委任されたカスタムIPv6プレフィックス」に貼り付け「/56」とかつけます。

設定手順3:WAN6インタフェースにDHCPv6関連設定

openWRT 21.02の段階でもWAN6インタフェースではDHCPv6関連設定がGUIできない状態であるため、/etc/config/dhcpファイルを直接書き換えます。

必要な設定は「option dhcpv6 ‘relay」「option ra ‘relay’」「option ndp ‘relay’」「option master ‘1’」です。

変更したあとは、以下の様な感じになるかと思います。

config dhcp 'wan6'
        option dhcpv6 'relay'
        option ra 'relay'
        option ndp 'relay'
        option master '1'
        option interface 'wan6'
        option start '100'
        option limit '150'
        option leasetime '12h'

ファイル変更後は下記を実行して変更を反映します。

# uci commit dhcp
# /etc/init.d/odhcpd restart
# /etc/init.d/network restart

設定手順4:LANインタフェースにDHCPv6関連設定

LANインタフェースの[DHCPサーバー]-[IPv6設定]で以下の設定を行います。

RA-Service:リレーモード
DHCPv6-サービス: リレーモード
NDP-Proxy: リレーモード

(マスターにチェックは入れません)

設定手順5: MAP-E接続設定

インタフェースの新規作成で「プロトコル:AP / LW4over6」を作成して、必要な値を入れていきます。

[一般設定]では下記の様にしました。

プロトコル:MAP/LW4over6
タイプ:MAP-E
以後は環境に合わせた値

[詳細設定]では下記の2つを設定します。

「トンネルリンク: WAN6」
「従来のMAPを使用」にチェックを入れる

設定完了

ひとまずこれで設定完了です。

うまく接続が始まらない場合は、再起動してみてください。

設定:ニチバン対策

2chの「v6プラス関連 Part21」に下記のような書き込みがある。

757名無しさんに接続中… (ブーイモ MM0e-wDGU)2020/09/27(日) 12:54:30.84ID:cYRzN3kgM>>758
openwrtでMAP-Eされてる方で、
https://gist.github.com/anonymous/0fdec75fa20a7f1ce4806391d6b0429b
このgitのコメントにあるように、
json_add_boolean connlimit_ports 1を
json_add_string connlimit_ports “1”
に変えるor最新のfirewallパッケージを入れるで安定して通信出来てる人いますか?

これをする事でopenwrtで当たり前となってるmap.sh編集してMARKターゲット作ってstatisticで分散してって事をせずとも、
connlimitでポートセット使い切ったら次のポートセット移ってってfirewallがちゃんと出来上がるようになるけど、
ルール通りロールアウトしてる気配が全く無い。
ロールアウトせずパケ詰まりしてしまう。

795 757 (ブーイモ MMe7-PIvK)2020/09/30(水) 20:53:39.27ID:1mR0IohpM>>802
最終的にこのようなcunstom rulesになりました。
https://pastebin.pl/view/raw/06212cd8
多分ですが、map.shで自動生成されるiptablesだと、
–connlimit-maskの指定がなく32になるので、
それだとdestinationが0.0.0.0/0なのでマッチせずロールアウトされないんだと思います。
0にしてあげたらロールアウトしました。(間違ってたらご指摘下さい。)
TCPもnf_conntrack調整したらconnlimitでも大丈夫な感じでしたが、
statisticでかなり安定してるのでTCPのみstatisticにしました。
map.shはlegacy=1をコメントアウトするか、snapshotsから最新のmapをインストールした場合は、
option legacymap ‘1’をnetworkのmapインターフェイスに追記するだけで動くと思います。
markターゲット追加する改変は不要です。
custom rulesに書いただけだと、リブート時、custom rulesの後にmap.shがiptablesを書いてしまうので、
local startupに
sleep 30
sh /etc/firewall.ser
を書けばmap.shで自動生成されたNATテーブルを削除して改めて書いてくれます。

これで、ニチバンベンチ回してもTCPは詰まらないですし、
MAP-EでUDP hole puch使うアプリケーションが使えるので、PS系ゲーム機でNATタイプ2になりましたし、
SoftEtherでUDP高速化機能が使るようになりました。

アドバイス下さった>>758様や、スクリプト考案の先駆者様等、
有難うございます。

GL-MV1000時代にも試した「OpenWrt map-e (JPNE v6plus) において、割当ポート240個をちゃんと使わせるための設定。」はここでもうまく動作していなかった模様。

代替としてhttps://pastebin.pl/view/raw/06212cd8にある設定に置き換えるとある。

しかし「OpenWrt map-e (JPNE v6plus) において、割当ポート240個をちゃんと使わせるための設定。」のコメント欄を見ると、誤植があるようだった。

また、誤植修正後も接続状況が不安定なので出力されるiptablesの確認したところ、範囲外のポートを指定していることが判明

(2021/05/21追記: この差異はV6プラス/BIGLOBEとOCN バーチャルコネクトとの仕様の違いとのこと)

修正版として https://gist.github.com/osakanataro/a9ba5ded340070b8e6abc28969d7ae4f を作成した。

修正点
「units=63」→「units=15」
「portl=expr $rule \* 1024 + $PSID \* 16」→「portl=expr $rule \* 4096 + $PSID \* 16

IP4,PSID, LANDEV,WAN6DEV,TUNDEVは自分の環境に合わせて変更すること
IP4, PSIDがわからない場合は http://ipv4.web.fc2.com/map-e.html で確認すること

#units=63
units=15

IP4='xxx.xxx.xxx.xxx'
PSID=110
LANDEV='br-lan'
WAN6DEV='eth0'
TUNDEV='map-MAP'

iptables -t nat -F PREROUTING
iptables -t nat -F OUTPUT
iptables -t nat -F POSTROUTING

rule=1
while [ $rule -le $units  ] ; do
  mark=`expr $rule + 16`
  pn=`expr $rule - 1`
  portl=`expr $rule \* 4096 + $PSID \* 16`
  portr=`expr $portl + 15`

  echo iptables -t nat -A PREROUTING -p tcp -m statistic --mode nth --every $units --packet $pn -j MARK --set-mark $mark
  iptables -t nat -A PREROUTING -p tcp -m statistic --mode nth --every $units --packet $pn -j MARK --set-mark $mark
  echo iptables -t nat -A OUTPUT -p tcp -m statistic --mode nth --every $units --packet $pn -j MARK --set-mark $mark
  iptables -t nat -A OUTPUT -p tcp -m statistic --mode nth --every $units --packet $pn -j MARK --set-mark $mark

  echo iptables -t nat -A POSTROUTING -p icmp -m connlimit --connlimit-daddr --connlimit-upto 16 --connlimit-mask 0 -o $TUNDEV -j SNAT --to $IP4:$portl-$portr
  iptables -t nat -A POSTROUTING -p icmp -m connlimit --connlimit-daddr --connlimit-upto 16 --connlimit-mask 0 -o $TUNDEV -j SNAT --to $IP4:$portl-$portr
  echo iptables -t nat -A POSTROUTING -p tcp -o $TUNDEV -m mark --mark $mark -j SNAT --to $IP4:$portl-$portr
  iptables -t nat -A POSTROUTING -p tcp -o $TUNDEV -m mark --mark $mark -j SNAT --to $IP4:$portl-$portr
  echo iptables -t nat -A POSTROUTING -p udp -m connlimit --connlimit-daddr --connlimit-upto 16 --connlimit-mask 0 -o $TUNDEV -j SNAT --to $IP4:$portl-$portr
  iptables -t nat -A POSTROUTING -p udp -m connlimit --connlimit-daddr --connlimit-upto 16 --connlimit-mask 0 -o $TUNDEV -j SNAT --to $IP4:$portl-$portr

  rule=`expr $rule + 1`
done

上記を

openwrtの[ネットワーク]-[ファイヤーウォール]-[Custom Rules] (/etc/firewall.user) に記載する。

また、[システム]-[スタートアップ]-[ローカルスタートアップ] (/etc/rc.local)の exit 0よりも前に下記2行を追加する

sleep 30
sh /etc/firewall.user

また、iptablesのstatisticモジュールはiptables-mod-ipoptに入っているが、標準では導入されていないため、下記のようにインストールする。

root@nanopi:~# opkg install iptables-mod-ipopt
Installing iptables-mod-ipopt (1.8.7-1) to root...
Downloading https://downloads.openwrt.org/releases/21.02.0-rc1/targets/rockchip/armv8/packages/iptables-mod-ipopt_1.8.7-1_aarch64_generic.ipk
Installing kmod-ipt-ipopt (5.4.111-1) to root...
Downloading https://downloads.openwrt.org/releases/21.02.0-rc1/targets/rockchip/armv8/packages/kmod-ipt-ipopt_5.4.111-1_aarch64_generic.ipk
Configuring kmod-ipt-ipopt.
Configuring iptables-mod-ipopt.
root@nanopi:~#

これで、とりあえずニチバンもスムースに開けるようになった。


失敗例コレクション

「プロトコル:MAP / LW4over6」が選択肢にない

画像

mapパッケージインストール後、openWRTを再起動するまで、このプロトコル一覧は更新されませんでした。

再起動すると表示されるようになりました。

「MAP rule is invalidError: MAP rule is invalid」になる

「MAP rule is invalidError: MAP rule is invalid」はWAN6インタフェースの詳細設定で「委任されたカスタムIPv6プレフィックス」(ip6prefix)を設定していない場合に出力されました。

invalidと表示された時のWAN6インタフェースの「IPv6-PD」に表示されている値を突っ込んだら、invalidが解消されました。

設定ファイル的には/etc/config/networkのWAN6に関する記述に「list ip6prefix」を追加する感じです。

LAN内にDHCPv6アドレスが配布されない

nanoPi上は特に問題無くIPv6アドレスが割り当てられており動作もしているが、LAN内のクライアントにDHCPv6アドレスが配布されていないという状態になった。

これは、LANインタフェースの[DHCPサーバ]-[IPv6設定]にある「マスター」にチェックを一度でも入れてしまうと発生する事象だった。

一度チェックを入れて保存すると、/etc/config/dhcp に以下の様な設定が行われる。

<略>
config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'
        option ra_slaac '1'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'
        option ra_maxinterval '600'
        option ra_mininterval '200'
        option ra_lifetime '1800'
        option ra_mtu '0'
        option ra_hoplimit '0'
        option ra 'relay'
        option dhcpv6 'relay'
        option ndp 'relay'
        option master '1'
<略>

この後、マスターのチェックを外すと、以下の様になる

<略>
config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'
        option ra_slaac '1'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'
        option ra_maxinterval '600'
        option ra_mininterval '200'
        option ra_lifetime '1800'
        option ra_mtu '0'
        option ra_hoplimit '0'
        option ra 'relay'
        option dhcpv6 'relay'
        option ndp 'relay'
<略>

ここで問題となったのは以下の値でした。

        option ra_slaac '1'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'
        option ra_maxinterval '600'
        option ra_mininterval '200'
        option ra_lifetime '1800'
        option ra_mtu '0'
        option ra_hoplimit '0'

これらの値が存在しているとDHCPv6アドレスのLAN内への配布がうまくいきませんでした。

/etc/config/networkを編集したあと、下記で反映することで動作するようになりました。

# uci commit dhcp
# /etc/init.d/odhcpd restart
# /etc/init.d/network restart

参考: IPv6 working on router but not on clients

MAP-E接続が開始されない

GL-MV1000からnanoPi R2Sに置き換えてすぐは、IPv6接続はできているが、MAP-E接続が開始されない、という状態になった。

ONUの電源を切り、5分ぐらいしてから電源を入れnanoPiも起動するとMAP-E接続が可能となった。

おそらく、接続先でのセッション認識が消えないと別のデバイスでの接続が行うことができないようだ。(エラーにもならないので詳細は不明)


参考資料

/etc/config/network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd23:66f8:d98f::/48'

config interface 'lan'
        option type 'bridge'
        option ifname 'eth1'
        option proto 'static'
        option netmask '255.255.255.0'
        option ipaddr '192.168.1.1'
        option ip6assign '60'

config device 'lan_eth1_dev'
        option name 'eth1'
        option macaddr '1a:e4:a4:xx:xx:xx'

config interface 'wan'
        option ifname 'eth0'
        option proto 'dhcp'
        option auto '0'

config device 'wan_eth0_dev'
        option name 'eth0'
        option macaddr '1a:e4:a4:xx:xx:xx'

config interface 'wan6'
        option ifname 'eth0'
        option proto 'dhcpv6'
        option reqaddress 'try'
        option reqprefix 'auto'
        list ip6prefix 'xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/56'

config interface 'MAP'
        option proto 'map'
        option maptype 'map-e'
        option peeraddr 'xxxx:xxxx:xxxx:xxxx::64'
        option ipaddr 'xxx.xxx.xxx.xxx'
        option ip4prefixlen '15'
        option ip6prefix '240b:10::'
        option ip6prefixlen '31'
        option ealen '25'
        option psidlen '8'
        option offset '4'
        option tunlink 'wan6'
        option legacymap '1'

/etc/config/dhcp

config dnsmasq
        option domainneeded '1'
        option boguspriv '1'
        option filterwin2k '0'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option nonegcache '0'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option nonwildcard '1'
        option localservice '1'
        option ednspacket_max '1232'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'
        option ra 'relay'
        option dhcpv6 'relay'
        option ndp 'relay'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'

config dhcp 'wan6'
        option dhcpv6 'relay'
        option ra 'relay'
        option ndp 'relay'
        option master '1'
        option interface 'wan6'
        option start '100'
        option limit '150'
        option leasetime '12h'

AMD B450チップセット+Ryzen 3 2200G環境でWSL2が 0x80370102で使えない

AMD B450チップセットを使っているASUS TUF B450M-PLUS GAMING にRyzen 3 2200Gを載せている環境で、WSL2を試そうとした。

BIOSのCPU設定にて「SVM Mode」を「Enabled」に変更して、

画像

Windows 10 用 Windows Subsystem for Linux のインストール ガイドの手順に従ってWSL2をセットアップしていく・・・

画像

Ubuntu が0x80370102 のエラーで起動しない。

画像

冒頭に写真に出したように仮想化は有効にしている。

タスクマネージャのパフォーマンスのCPUでも「仮想化:有効」表示を確認

画像

msinfo32でも仮想化の有効を確認

画像

万策尽きたか・・・というところで、AMD Radeon Softwareパッケージを再インストールすることで解決するかも?という話を聞いて、AMD Ryzen™ 3 2200G Previous Drivers からRadeon Softwareをダウンロード/インストール/再起動してみたところ、今度はWSL2が正常に起動することが確認出来た。

次はWSLgだな・・・

タッチパネル一体型業務向けPC MSI-R104I8BD1を入手したのでWindows/Ubuntu/ChromeOSで起動してみた

sueboさんがうっかり落札してしまった14台のタッチパネル一体型PCを2台譲ってもらった。

現状は全台はけた、ということですが、この機種およびマザーボードについてぐぐっても情報がほとんど出てこないので、ここにメモとして残しておきます。

目次
 スペックについて
 中をあける方法
 USBメモリからの起動について
 Windows 10の起動状況
 Ubuntu 20.04の起動状況
 ChromeOSの起動状況
 BIOSアップデートについて

スペックについて

マザーボードはMSI MS-98I8 で、この一体型PCは下記の様なスペックになっている。

Celeron N3160
DDR3x1 / Mini-PCIex1 / mSATAx1 / SATAx1 / DPx1 / HDMIx1 / GbEx2
10インチ SVGA(800×600)+タッチパネル
Windows 10 IoT Enterprise 2016 LTSB ライセンスシール
メモリ/ディスクは搭載なしだが、CF/SATA変換ボードと2.5インチHDD接続用ケーブルが残存
電源は12V単一。一般的なコネクタではなく電線を直接入力するタイプ
ただ、マザーボード自体の仕様としては9V~36Vと書いてある

中をあける方法

抜けたりするのを防ぐため中のケーブルのコネクタ部分が固められています。

とりあえず中身を確認するためには、下記のような感じで開けてみてから、その次をどうしていくかを考えた方がいいと思います。

画像

このような感じであけるには以下の赤い丸印のネジを外します。

画像
画像
画像

中をあけたらメモリとディスクなどをいれて単体で動作できるようにしましょう。

USBメモリからの起動について

BIOSメニューからUSBメモリを選んでもなんか普通のマザーボードと同様にUSBメモリからの起動になりません。(後述のWindows, Ubuntu, ChromeOSで同じ)

起動順序を「UEFI: Built-IN EFI Shell」を一番最初にして起動します。

画像

EFI Shellが起動してくるので、何かキーを押してEFI Shellプロンプトで止めます。

画像

今回はUSBメモリが「fs1」で認識されていたので「fs1:」でドライブを移動したあと、

「efi\boot\bootx64.efi」を実行するとUSBメモリからの起動が開始されます。

下記の写真では「cd efi」「cd boot」でディレクトリ移動してから「bootx64.efi」を実行しています。

画像

なお、このEFI Shellはタブキー補完が効くのでefiを指定する際に「e」を入力したあとにタブキーを押すと「efi」と変換されます。

また、fs1:で移動した後にそこにどんなディレクトリ/ファイルがあるかを確認するには「ls」を実行することで確認出来ます。

なお、USBメモリに startup.nsh というファイルを置いて、「.\efi\boot\bootx64.efi」とかかいておけば自動起動されるんじゃないかなぁとは思います。

参考:拡張ファームウェアインターフェイス (EFI) インテル®の基本手順サーバーボード

Windows 10の起動状況

Windows 10 IOT ENT 2016 LTSBのプロダクトキーがついていますが、このプロダクトキーが通るのは、「Windows 10 IOT ENT 2016 LTSBメディア」か「Windows 10 ENT 2016 LTSB」だけのようです。「Windows 10 Enterpriseメディア」や「Windows 10 Enterprise 2019 LTSCメディア」では通りませんでした。

「Windows 10 IOT ENT 2016 LTSBメディア」を含めて2016年頃のWindows 10メディアだとデバイスが2個△マークとなりますが、タッチパネル/イーサネット含めて動作しています。

2017年以降のWindows 10 メディアを使ったり、Windows Updateを実行すると、全デバイスが正常に認識されますので、問題はありません。

画像

なお、Windows 10 IOT ENT 2016 LTSBのプロダクトキーを入力してライセンス認証を行った場合、「Windows 10 Enterprise 2016 LTSB」として認識されています。

画像

なお、Windows 10 Enterprise 2016 LTSBのライフサイクル ポリシーはメインストリームが2021/10/12、延長が2026/10/13となっています。

画像

Ubuntu 20.04の起動状況

普通にインストールすると、タッチパネル用のドライバが認識されているもののX-Window上でタッチパネル動作を認識できていません。

画像
画像

この問題についてはxserver-xorg-input-evdevをインストールして、xserver-xorg-input-libinputを削除して対応できました。(xinput-calibratorはタッチパネルの位置調整用コマンドxinput_calibratorをインストールするために追加している)

$ sudo apt install xserver-xorg-input-evdev xinput-calibrator
$ sudo apt remove xserver-xorg-input-libinput

これを行った後、再起動するとタッチパネルが動作するようになっていると思います。

画像

Ubuntuのオンスクリーンキーボードは、「設定」の「アクセスビリティ」から設定できますが、最初のログイン画面では動いていないようです。

とりあえず、自動ログインさせてログイン画面をスキップする設定をGUIで行おうとしたところ画面が表示できていない・・・

画像

このため設定ファイル /etc/gdm3/custom.conf を直接編集し、下記の設定を行いました。

[daemon]
AutomaticLoginEnable=yes
AutomaticLogin =ユーザ名

ChromeOSの起動状況

純正ChromeOSのリカバリイメージを元に汎用ChromeOS起動ディスクを作成するbrunchを使ってUSBメモリを作成して起動したもの。

rammus用リカバリイメージを元に作成してあるUSBメモリがあったので起動してみたところ、標準状態でそのままタッチパネルもLineOUTからのオーディオ出力も普通に使える状態で起動してきました。

画像

ただ、Chrome OSは、800×600解像度で使うものではない感じですね・・・


BIOSアップデートについて

マザーボードの製品ページを開いて少しスクロールすると上側に「Download」リンクが現れ、そこにBIOSアップデートが提供されており、Version 170と書いてある。

ZIPファイルをダウンロードするとバージョンアップ履歴のテキストファイルがあり、Version 170とは、E98I8IMS V1.7ということのようだ

画像

届いたものを確認すると E98I8IMS V1.6となっているので、少し古いバージョンということになっている。

画像

BIOSアップデータはEFIで実行する形式なので、EFI Shellから実行する必要があります。

EFI ShellではFAT32領域しか見れず、NTFSやLinux ext4領域などは使えない、という制約があるので、FAT32でフォーマットしたUSBメモリにBIOSアップデート関連ファイルを展開して使用します。

USBメモリをさして、EFI Shellに入ってから下記のように入力してアップデートを実施します

Shell> fs1:
fs1:\> cd E98I8IMS170
fs1:\> EFUx64.EFI E98I8IMS.170
画像
画像

アップデートが終わったら再起動します。

バージョンを確認するとV1.7に変わったことが確認できます。

画像