それマグで!

知識はカップより、マグでゆっくり頂きます。 takuya_1stのブログ

習慣に早くから配慮した者は、 おそらく人生の実りも大きい。

netplan でDHCP設定すると metric がぶっ壊れた件。

netplan でDHCP設定すると metric ばぶっ壊れる件

表題のとおりです。

問題点

RaspberryPi4の、eth0 と wlan0 が接続されたUbuntuシステムで、netplan を設定するとmetric がおかしい。

パケットがすべてWif( wlan 0 ) 経由になってしまう。

原因

eth0 と wlan0 なら、wlan0のほうが接続が遅く、同一DHCPから割り当てると、あとから来たほうが優先されている。

netplan に metric を設定しても無駄。

再現方法

netplan で wifi を接続する

network:
  version: 2
  renderer: networkd
  wifis:
    wlan0:
      dhcp6: false
      dhcp4: false
      addresses: [192.168.1.249/24]
      gateway4: 192.168.1.1
      dhcp4-overrides:
        route-metric: 200
      routes:
        - to: 192.168.1.0/24
          via: 192.168.1.1
          metric: 200
        - to: default
          via: 192.168.1.1
          metric: 200
      access-points:
        "takuya.mywif.local":
          password: "***********"

networkd で、eth0 を設定する。

[Match]
Name=macvlan0

[Network]
DHCP=no
Address=192.168.1.240/24
Gateway=192.168.1.1
DNS=192.168.1.1
DNS=192.168.1.5
LinkLocalAddressing=no

[Route]
Destination=192.168.1.0/24
Metric=1

結果

default via 192.168.1.1 dev eth0 proto static
default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.2.249 metric 200
192.168.2.0/24 dev wlan0 proto kernel scope link src 192.168.1.249 ### ←おいおい、わたしmetricいれたよな
192.168.2.1 dev wlan0 proto dhcp scope link src 192.168.1.249 metric 200
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.1.240 
192.168.2.0/24 dev eth0 proto static metric 1

結論

netplan の metric はおかしい。

さらに、詳細に調べれば、原因が突き止められるかもしれないが、めんどくさいので netpaln すてて、 netowkrd + wpa_supplicant で Wifi 接続することにする。

netplan 怖いよ。renderer を network-managerに変えようかと思ったけど、もうしんどい。

経路が指定できないので、手動で ip route del / ip route add するのに疲れたのでもう諦める。

どっかで設定間違えたかなぁ。

個人的には、wlan0 とeth0 が共通サブネットとゲートウェイなら、eth0を優先してほしいんだけどなぁ

HTMLフォームのinputにイベントで文字列の値を突っ込む。スクレーパー用に使う。

課題:DOMを直接書き換えると反映されない

DOMでValueを書き換えても、反映されないJSのフレームワークが幾つかある。Angularとか。あのあたりをつかったログインフォームをかんたんに入力したい。

方法1 html のイベントをトリガーして文字列を突っ込む

最近は、domを直接書き換えないでJSでオブジェクトをObserveしていることが多いので、イベントを発火させて文字列を入力する。

inputElement = document.querySelector('input[name=nationalId]')
var event = new Event('input', {
    'bubbles': true,
    'cancelable': true
});

inputElement.value = '12345678'
inputElement.dispatchEvent(event);

めっちゃ単純ですね。通常通りDOMを書き換えたあとに、dispatchEvent で new Event('input') を発行してやるだけです。 これで、擬似的にフォームの入力をprogrammatically に試行できます。

方法2 execCommand

いにしえの手法 focus/ execCommand を使うともっと楽ちん。

document.querySelector('#tel001').focus()
document.execCommand('insertText', false, "090123456");

こちらは、focus したうえで、 execCommand を発行する。

focus したうえでイベントを発行するなら、他イベントも行けそうです。ただイベントを調べたりサポート状況が曖昧なので、execCommandという枯れた物を使います。

昔のやつ

https://takuya-1st.hatenablog.jp/entry/2014/11/12/162008

AngularJSのやつ

https://takuya-1st.hatenablog.jp/entry/2021/12/15/015820

Angular/AngularJSの場合は、スコープを取り出せば入力ができますが、フレームワークに特化すると後々が面倒そうなのでイベントを発火するほうが無難だと思う。

追記:パスワード自動入力ソフトの場合。

パスワード入力をするChrome のExtensionではどういう実装になっているのかというと、Bitwardenのソースコードを覗いてみました。

しつこくイベントを発行してました。

var event1 = el.ownerDocument.createEvent('HTMLEvents'),
                    event2 = el.ownerDocument.createEvent('HTMLEvents');
                el.dispatchEvent(doEventOnElement(el, 'keydown'));
                el.dispatchEvent(doEventOnElement(el, 'keypress'));
                el.dispatchEvent(doEventOnElement(el, 'keyup'));
                event2.initEvent('input', true, true);
                el.dispatchEvent(event2);
                event1.initEvent('change', true, true);
                el.dispatchEvent(event1);

https://github.com/bitwarden/browser/blob/master/src/content/autofill.js

ちなみに、bitwarden がこれだけイベント発火しても、一部のサイト(TP-Linkのルータログインページなど)では入力がうまくJS側に拾われないんですよねぇ。

AnguarJS のng モデルにchromeコンソールから入力する。

angular のモデルに変数を突っ込む

angular のモデルに直接値を突っ込んでもHTML要素の書き換えは反映されない。

ng-model を探す

angular を呼び出して。html element からスコープを取り出す。

var scope = angular.element(document.querySelector('input[name=nationalId]')).scope();

新生銀行での例

f:id:takuya_1st:20211215015549p:plain

modelをscope で探して apply する。

var scope = angular.element(document.querySelector('input[name=nationalId]')).scope();
scope.$apply(function() {
  scope.nationalId='123456789'
  scope.password='AAAAAAAAA'
});

これで、だいたい動く。angarJSなので、typescriptベースのangularでも動くかは試してないから、apply がどのバージョンまで動くかはわからない。

Angularの場合は、次で動くはず。

ng.probe($0)

document.forms[] や HTMLElementを使うところから比べるAngularは自己完結なのでちょっとめんどくさいですよね。

AngularJS/Angular に特化するより、DOMのInput系のイベントをファイアしたほうが楽だと思う。

今後、webasembly とか出てきたらスクレーパーはどんどん難しくなっていくだろうな辛い。

USB OTG でOTGで 複数の機器を有効にする。

OTGで 複数の機器を有効にする。

root@OrangePi:~# cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

g_cdc

Raspi からみると・・・ usb0 ネットワークが出現した

takuya@raspi-ubuntu:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 8: usb0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether d6:f8:81:1e:7c:23 brd ff:ff:ff:ff:ff:ff

USBを見てみると・・・

takuya@raspi-ubuntu:~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 0525:a4aa Netchip Technology, Inc. Linux-USB CDC Composite Gadge (Ethernet and ACM)
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Ethernetカードとして認識されている強い。

OrangePi Zero 側からみてみると。usb0が出現した

root@OrangePi:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 3: usb0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 2a:80:fe:93:0b:78 brd ff:ff:ff:ff:ff:ff

通信してみる。

takuya@raspi-ubuntu:~$ sudo  ip link set usb0 up 
takuya@raspi-ubuntu:~$ sudo  ip addr add 10.1.1.1/24 dev usb0
root@OrangePi:~# ip link set usb0 up 
root@OrangePi:~# ip addr add 10.1.1.2/24 dev usb0

ping 疎通確認

takuya@raspi-ubuntu:~$ ping 10.1.1.2
PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data.
64 bytes from 10.1.1.2: icmp_seq=1 ttl=64 time=0.474 ms
64 bytes from 10.1.1.2: icmp_seq=2 ttl=64 time=0.352 ms

iperf3 で速度チェック

root@OrangePi:~# iperf3 -c 10.1.1.1
Connecting to host 10.1.1.1, port 5201
[  4] local 10.1.1.2 port 51210 connected to 10.1.1.1 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  11.7 MBytes  97.8 Mbits/sec    0    146 KBytes
[  4]   1.00-2.00   sec  7.46 MBytes  62.4 Mbits/sec    0    232 KBytes
[  4]   2.00-3.00   sec  2.55 MBytes  21.4 Mbits/sec    0    253 KBytes
[  4]   3.00-4.00   sec  5.28 MBytes  44.4 Mbits/sec    0    253 KBytes
[  4]   4.00-5.02   sec  9.69 MBytes  79.6 Mbits/sec    0    253 KBytes
[  4]   5.02-6.00   sec  4.66 MBytes  39.9 Mbits/sec    0    253 KBytes
[  4]   6.00-7.01   sec  7.77 MBytes  64.9 Mbits/sec    0    253 KBytes
[  4]   7.01-8.00   sec  2.17 MBytes  18.3 Mbits/sec    0    253 KBytes
[  4]   8.00-9.00   sec  2.49 MBytes  20.9 Mbits/sec    0    253 KBytes
[  4]   9.00-10.01  sec  10.3 MBytes  85.7 Mbits/sec    0    253 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.01  sec  64.0 MBytes  53.7 Mbits/sec    0             sender
[  4]   0.00-10.01  sec  63.5 MBytes  53.3 Mbits/sec                  receiver

iperf Done.

逆も念の為。

takuya@raspi-ubuntu:~$ iperf3 -c 10.1.1.2
Connecting to host 10.1.1.2, port 5201
[  5] local 10.1.1.1 port 35584 connected to 10.1.1.2 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  10.7 MBytes  90.1 Mbits/sec    0   52.3 KBytes
[  5]   1.00-2.00   sec  10.5 MBytes  87.7 Mbits/sec    0   52.3 KBytes
[  5]   2.00-3.00   sec  10.5 MBytes  88.2 Mbits/sec    0   52.3 KBytes
[  5]   3.00-4.00   sec  10.5 MBytes  88.5 Mbits/sec    0   52.3 KBytes
[  5]   4.00-5.00   sec  10.4 MBytes  87.4 Mbits/sec    0   52.3 KBytes
[  5]   5.00-6.00   sec  9.99 MBytes  83.8 Mbits/sec    0   83.4 KBytes
[  5]   6.00-7.00   sec  1.07 MBytes  8.99 Mbits/sec    1    197 KBytes
[  5]   7.00-8.00   sec   827 KBytes  6.78 Mbits/sec    0    225 KBytes
[  5]   8.00-9.00   sec   636 KBytes  5.21 Mbits/sec    1    247 KBytes
[  5]   9.00-10.00  sec  5.22 MBytes  43.8 Mbits/sec    0    274 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  70.4 MBytes  59.0 Mbits/sec    2             sender
[  5]   0.00-10.00  sec  69.2 MBytes  58.1 Mbits/sec                  receiver

iperf Done.
takuya@raspi-ubuntu:~$

そこまで速度が出るわけじゃないけど、便利。

ethtool では情報が出ないですね

takuya@raspi-ubuntu:~$ sudo ethtool usb0
Settings for usb0:
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes
root@OrangePi:~# ethtool usb0
Settings for usb0:
        Link detected: yes

他にもマスストレージ、オーディオになれる。強い。

https://qiita.com/alt-core/items/a3b37a96e16e771e6cb1 https://linux.yebisu.jp/memo/1160

linux の iproute2 でブリッジの追加。( brctl に代わる bridgeというiproute パッケージのコマンド )

linux の iproute2 でブリッジの追加。

brctl はもう時代遅れらしいので、iproute2 (ip コマンド)で追加する方法を模索してみた。

ブリッジの追加と削除

ブリッジを作成して、インタフェースをブリッジに挿す。

sudo ip link
sudo ip link add name br0 type bridge
sudo ip link set dev br0 up
sudo ip link set dev macvlan1 master br0
sudo ip a
sudo dhclient -v br0

削除

sudo ip link set dev br0 down
sudo ip link del br0

実際にやってみた結果。

ブリッジを追加するとどのように変わるのか。コマンドを実行して確認したいと思います。

ブリッジの追加

追加前

takuya@raspi-ubuntu:~$ sudo ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether dc:a6:32:dd:23:c4 brd ff:ff:ff:ff:ff:ff
5: macvlan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:76:71:6e:4f:80 brd ff:ff:ff:ff:ff:ff
6: macvlan0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 32:b7:9f:1a:67:d4 brd ff:ff:ff:ff:ff:ff

追加:ipコマンドで追加

takuya@raspi-ubuntu:~$ sudo ip link add name br0 type bridge

追加後: br0 が追加されてる

takuya@raspi-ubuntu:~$ sudo ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether dc:a6:32:dd:23:c4 brd ff:ff:ff:ff:ff:ff
5: macvlan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:76:71:6e:4f:80 brd ff:ff:ff:ff:ff:ff
6: macvlan0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 32:b7:9f:1a:67:d4 brd ff:ff:ff:ff:ff:ff
23: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether a6:e2:d0:d6:9e:5a brd ff:ff:ff:ff:ff:ff
takuya@raspi-ubuntu:~$

ブリッジにNICを追加。

ブリッジにNICを参加させると、どう変わるのか、コマンド実行して結果を確認したいと思います。

追加前

takuya@raspi-ubuntu:~$ bridge link
takuya@raspi-ubuntu:~$

追加:br0 に macvlan1 を参加(接続)させる。

sudo ip link set dev macvlan1 master br0

結果の確認

takuya@raspi-ubuntu:~$ bridge link
5: macvlan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 4

まだ試してないこと。

btctl でもやってたと思うけど。。。

BPDUを使ったルートポートとブロッキング・ポートの処理。

STPによるループ処理 について知っておく必要がある。

参考1 , 参考2

STPでは、BPDU を送出し、相互にSTP有効であることを認知する。 スイッチが互いを認知する際に、ブリッジ・プライオリティを送出する。 スイッチはお互いの経路を認知する際に、PATHコストを計算する。 ルートスイッチは、自分のコスト=0として広告 各スイッチは、ルートに近いポートを認知 不要なポートはブロック。

このあたりをbrdige コマンドのコスト設定で可能になる。

ip link add br0 type brige でできるのはわかるけど、検索して引っ掛けるのは不可能なんじゃ。。。

参考資料

https://wiki.alphaframe.net/doku.php?id=linux:macvlan

linuxで macvlan on mavlan でネストしたネットワーク・インタフェースを作ってみる。

macvlan on macvlan は動くのか

これを見ていて、ふと愚問が湧いた。 ネストしたらどうなるんだろう。

ネストできるのか興味が出たので試した。

作れる。まじか。

macvlan3 on eth0

sudo ip link add macvlan4 link macvlan3 type macvlan mode bridge

macvlan 4 on macvlan3

sudo ip link add macvlan4 link macvlan3 type macvlan mode bridge

dhcp for macvlan4

dhclient -v macvlan4

動く。

takuya@raspi-ubuntu:~$ sudo dhclient -v -r macvlan4
Killed old client process
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/macvlan4/d2:27:17:3a:41:59
Sending on   LPF/macvlan4/d2:27:17:3a:41:59
Sending on   Socket/fallback
DHCPRELEASE of 192.168.2.113 on macvlan4 to 192.168.2.1 port 67 (xid=0x24dec657)```

macvlan3/macvlan4 に同時にdhcpしてみる

41: macvlan3@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 26:c0:ec:88:cc:ec brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.113/24 brd 192.168.2.255 scope global dynamic macvlan3
       valid_lft 43186sec preferred_lft 43186sec
    inet6 fe80::24c0:ecff:fe88:ccec/64 scope link
       valid_lft forever preferred_lft forever
42: macvlan4@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether d2:27:17:3a:41:59 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.114/24 brd 192.168.2.255 scope global dynamic macvlan4
       valid_lft 43198sec preferred_lft 43198sec
    inet6 fe80::d027:17ff:fe3a:4159/64 scope link
       valid_lft forever preferred_lft forever

まじか。ネストできるんじゃん。

実験環境

takuya@raspi-ubuntu:~$ uname -a
Linux raspi-ubuntu 5.4.0-1046-raspi #50-Ubuntu SMP PREEMPT Thu Oct 28 05:32:10 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
takuya@raspi-ubuntu:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.3 LTS
Release:        20.04
Codename:       focal

macvlan on macvlan ができるのなら。macvlan on mavlan をlxc に追加してみる。

macvlan on macvlan ができるのなら。lxc に追加してみる。

linuxにmacvlanを追加するコマンド

iproute を使ってmacvlan や macvtapを追加する場合は次のようにする。

ip link add link eth0 name macvlan0 type macvlan
ip link add link eth0 name macvtap0 type macvtap

実際にmacvlanを追加する。

ホスト側にmacvlanを追加してみる。

sudo ip link add macvlan4 link macvlan3 type macvlan mode bridge

lxc にmacvlan として追加

lxc にmacvlan をホストのmacvlan3 に追加してみる。

lxc config device add sample01 eth1 nic nictype=macvlan  parent=macvlan3

動くよ。

takuya@raspi-ubuntu:~$ lxc shell  sample01
root@sample01:~# dhclient -v eth1
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/00:16:3e:02:08:7d
Sending on   LPF/eth1/00:16:3e:02:08:7d
Sending on   Socket/fallback
DHCPREQUEST for 192.168.2.115 on eth1 to 255.255.255.255 port 67 (xid=0x7915b91d)
DHCPACK of 192.168.2.115 from 192.168.2.1 (xid=0x1db91579)
RTNETLINK answers: File exists
bound to 192.168.2.115 -- renewal in 20428 seconds.
root@sample01:~#

多分こんな感じになってる。

ホスト(eth0-macvlan1-macvlan3)----macvlan--(eth0--lxc sample01)

orange pi zeroのOSについて

orange pi の最新版OSはこれだった。

https://www.armbian.com/orange-pi-zero/

入れ替えた!

f:id:takuya_1st:20211213212032p:plain

Armbian で、 ubuntu focal と debian bullseye が選べる ( 2021-12-13 現在 )

バージョン・アップに併せて提供される。

Orange Piは、長時間の動作時にフリーズがが頻発するのだけど、フリーズなければ常用するんだけどなぁ。

windows のリモートデスクトップ(mstsc.exe)の設定を初期化する。

リモートデスクトップのプログラムが覚えすぎ

いろいろ、設定を覚えすぎたときに面倒だから、初期設定を消してデフォルトとして保存されてしまった設定を消す。

 rm ./Documents/Default.rdp

起動し直すと、きれいになる。

f:id:takuya_1st:20211209190909p:plain

かんたんですね。

以上

linux のデスクトップ画面をフルスクリーンで全x11転送する

tl;dr

xlaunch で、フルスクリーンを選ぶ
ssh -X でログインする
gnome-session を起動する
ただし、rdp のほうが高速

x11 の転送を設定する。

最初にX転送が正しく行えていてリモートのGUIが設定されていることを確認

takuya-1st.hatenablog.jp

フルスクリーン・ワンウインドウで起動する

f:id:takuya_1st:20211209151108p:plain

フルスクリーンにした場合

全画面で真っ黒に表示されちゃう。Cmd+TAB/ Win+Tab で切り替えて抜ける

シングルウィンドウの場合

f:id:takuya_1st:20211209151735p:plain:w200

空っぽのディスプレイが起動します。サイズを調整します。

リモートにログインする。

ssh -X user@myserver

gnome-sessionを起動する

gnome-session が起動コマンドになります。

takuya@server:$  gnome-session

起動しました。

f:id:takuya_1st:20211209152000p:plain

通常通り使えます。

f:id:takuya_1st:20211209152028p:plain

終了

ウィンドウを閉じる(Xlanunch を終了) するか、gnome-sessionを終了すれば大丈夫です。

遅いし・キーアサインが・・・

ただし、使えるというだけで、転送量がかなりあるので大変です。

キーアサインも細かく設定できません。

rdp のプロトコルを使ったほうが無難です。

unboundをインストールしてdns問い合わせしつつ、書き換えする。

unbound を使って、DNS問い合わせを書き換える。

俗に言う、DNS広告ブロックってやつです。以前書いた記事から愚痴を除去してスッキリさせて書き直し

sudo apt install  unbound dns-root-data

/etc/unbound/unbound.conf

include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"
server:
  include: "/etc/unbound/myhosts/*.conf"
  include: "/etc/unbound/block/*.conf"

ブロック設定を作る

mkdir /etc/unbound/block
touch /etc/unbound/block/my-adblock-list.conf

設定を確認する。

unbound-checkconf

再起動する

systemctl restart unbound

ip6 は使わない。

 error: can't bind socket: Cannot assign requested address for ::1 port 8953

v6使い始めると考えることが多くなるので一旦切っておく。

do-ip6: no

dns フィルタリスト入手元

Adguard 、280blocker など

dns って何?ってひとは Adguard Home

AdGuard Homeを導入するのがかんたんです。特定サイトをきれいにブロックしてくれます。

以前の記事

参考URL

https://tech.akat.info/?p=3531

フルスクリーンで、UI(アドレス・タブ・ステータス)を消す。キオスクモードのようにプレゼン用

プレゼン時のブラウザを開くときにタブとアドレスバーを隠したい。

キオスクモードのようにウェブページだけを表示するようにして、プレゼン用に他のタブを見せたくない。

f:id:takuya_1st:20211207234859j:plain:w200

やり方(macOSの場合)

 ⌘+^+F 押して、そのあとに ⌘+Shift+F( google chrome )
 ⌘+^+F 押して、そのあとに ⌘+F10 ( vivaldi)

Windowsでもショートカットキーは違えど同じです。(たぶん)

どういうふうに変わるか

通常閲覧画面

f:id:takuya_1st:20211207234844j:plain

全画面( cmd+ctrl+F )

f:id:takuya_1st:20211207234851j:plain

全画面+UIなし(キオスクモード)

f:id:takuya_1st:20211207234859j:plain

完璧ですね。読書を妨げません。そして、プレゼンしてて、他のタブを見せなくて済みます。完璧ですね

まとめ

ブラウザ 全画面表示/mac UIを非表示/mac 全画面表示/win UIを非表示/win
chrome ⌘+^+F ⌘+Shift+F だれか教えて だれか教えて
vivaldi ⌘+^+F ⌘+F10 だれか教えて だれか教えて
Safari ⌘+^+F だれか教えて n/a n/a
Edge n/a n/a だれか教えて だれか教えて

契約書面をログインして閲覧する煩わしさから解放された件

PDFを閲覧するのにログインとかありえない。

契約書面や料金明細のような書面を確認するのに、ログインとかありえないってずっと言ってきました。

Povo、君はチャレンジャーだよ。

Povo 2.0 がついにPDFをメール送信をしたんですよ。大進歩です。素晴らしいです。PDFはパスワード付き

f:id:takuya_1st:20211206175615p:plain:w250

仕組みはこれでいいんだよ。これで。

契約書面や明細PDFのためだけに、「絵合せ認証」とか謎認証や「SMS認証」させられて、広告見せられて、戻るボタン禁止されるストレスから解放される。

au 側も無駄な「システム開発」から解放される。そして料金を安くできる。

Win-Winじゃないか。もっと普及してほしいですよ。

でも、パスワードが生年月日は一考の余地あり。

PDFのパスワード機能は、十分な長さを持つものであれば、全く問題がない。

パスワードが生年月日は、「たかだか30000通り」(365x80)なので、あっという間に突破できます。

パスワードをもうすこし複雑にする必要がありますが、メール送信するので盗聴リスクを考えても妥協点です。

明細書もお願いします。

明細書もこの方式で送っていただけると助かります。

パナソニックのドアホンが行けてないので、早く滅びて欲しい。

パナソニックのドアホンが行けてないので、早く滅びて欲しい。

新築マンション見に行ったんですよ。どこもパナソニックのドアホンなんですよ。やってられない。

ドアホン=Androidスマホ

ドアホンは、<マイク・スピーカー・カメラ・液晶モニタ・通話機能>これらが一体になった製品です、そうよね。スマホですわ。

極論すれば、Android防水機種を玄関に置いておけば事足りるわけですよ。極論すればね。

パナソニックのドアホンは、そこんところがまるでダメ

  • 日本独自のJ-DECT対応
  • 非暗号化通信
  • 有線LANない。
  • 無線LANは2.4ghz 75MBps
  • SMTPS の対応が微妙
  • スマホ通知機能が微妙
  • アップデートが不明

無線LANはAESでガッチリ暗号化されてると言うのに、J-DECTは非対応のまま放置 *1

スマホに近づき自動アップデートが必要になったドアホン。

いまの、ドアホンなんてスマホ技術を応用して、3年ごとに大幅にアップデートしてもいい商品なのじゃないかな。もし10年使う前提なら、wifiカード内蔵せずに有線LANにしてほしい。WifiはUSBアダプタ挿すとか専用機器を買い換える方式にしてほしい。

ドアホンはv6対応してない、v4のみ。セキュリティ的にはいいかもしれないが、それが原因で、リモートから利用が不便になってる。UPnPでポート開けて通信する。WebRTCで443ポートでビデオ会議やってるこの時代にですよ。ポート解放してるんですよ。内と外のネットワーク境界型なセキュリティに限界が来ているこの時代に、外部サーバーでSTUN的なこをとするわけでもない。どうなってるんですかね。SIPのような既存の枯れた技術を使わないの?

そして、何が怖いってパナソニック製品のマルウェア侵入による乗っ取りですよ。セキュリティアップデート履歴すらない会社にポート解放させて使われるなんてゴメンですわ。ていうかv6時代な現代でポート解放して製品にFW搭載するんではないのか。と。

ドアホンはいまのことろ製品寿命が長い

製品寿命が長い製品だから仕方ない?だったら余計にスマホ連携機能などは、「追加機能」を有効にするUSB機器で出してほしいと望む、WiFiすらも追加アダプタで出してほしい。本体は有線LANにして、無線LANは時代の進化に合わせて別で売れって思う。

プリインなスマホ機能?パナ製品にそんなの機能は求められてないよね。住宅設備機器のパナに求めるのは10年以上使える寿命だよね。

無線LAN対応してても2.4Gの11g製品を10年後に使いますか?と言われても判断に困るし、2.4GHzの11g相当のWiFi機器をいつまで維持するんだろうか。屋外で5GHzは使えないし、MIMO 443Mbpsの対応も困難、、、PoEで良いんじゃないですかね。

リコール

パナソニックのドアホンの大量リコール

ところが10年ただずに発火してリコールですよ。安全性と信頼がパナのコア部分でしょ何やってんの。もうダメですねこの会社。

パナに撤退してほしい。

パナご自慢の信頼と安定感すらリコールで喪失かな。もうインターホンから手を引いてほしい、コロナ禍における在宅ワーク、ウーバイーツなリモート普及において、パナソニックのドアホンが社会の妨げになってる。潔く負けを認めてこの固定電話とドアホン事業から手を引いてほしい。食洗機や洗濯機で戦ってください。ソフトウェア開発に向いてないのよ。

新築やリフォームで「パナ製品」しか選択肢がないので絶望します。

欲しいのはそこじゃないよ。

パナソニック製品の既存配線に接続できればそれでいいんだよ。スマホ連携追加機能とかは、追加製品で売れよ。、なんで本体に内蔵してるんだよ

しかもその本体がSDカード?え?SDですか?TF(microSD)でもなく?もうさ、本体にUSBストレージ挿せばいいだろ。USB機能つければいいじゃん、USBメモリが不格好に飛びだないように、本体に切り込みスリット入れたら済む話でしょ。切り込みスリットにピッタリ収まるUSBメモリをオプション製品として販売して暴利を貪ればいいじゃん。

枯れた技術で戦ってほしい。

本体に有線LANとsambaかFTP機能つけとけばそれでいいんだよパナ製品は。sdカードと11g無線LANとか中途半端なものつけないでよ。専用アプリを企画設計してアップデートを継続する実力もなさそうなので、SIPFTPやSambaといった枯れた技術を搭載していれば良いではないか。

SambaやFTPなんて枯れた技術なのに、samba 機能をつけないから、こういうことをする人が出てくる。製品として敗北してるんですわ。f:id:takuya_1st:20211206164140p:plain

ドアホン・電話連携機能、こんなもの追加アダプタ機器でいいだろ。

J-DECTとかいう平文を使った機器連携

連携機能でj-dect製品同士通信できますと言う割に、対応機器が限られていて、パナサイトをしらみつぶしに見ないとわからない。相互に通信できる機器が対応機器がわかりにくすぎる。ドアホンと電話の連携だけでどれだけのPDF資料読み漁らなくちゃいけないのもう疲れ

j-dectとか言う無線とWiFiの両方対応に金払わせて平気な顔してるとかやばくねパナソニックwifiつかうならwifiだけでいいよ。

WiFiあるのに、もう一つ別の無線機能J-DECTが入ってる。2つも無線機能は必要ないよね。しかもJ-DECT非暗号化通信で、対応機種も限られる。こんな別機能使うかどうかわからないのに、製品代金に上乗せされている、正直いってごめん被る。

パナの固定電話のカナ電話帳

パナ電話機に至っては、未だ昭和ですよ。カタカナの電話帳しか使えないんですよ。sdカードでインポ・エキスポも不可能ってなんだよ。

いま固定電話が使われないのは、固定電話の性能の問題じゃないですかね。とくにパナの責任じゃないか?

手のひらにスマートホンや携帯電話があるのに、わざわざ固定電話を使ってもらうんだから、スマホに固定電話機能をつ追加できるような、魅力的な機能を提供出来ないのか。昭和レトロのカナ電話帳な留守番電話機能で音質も微妙だから、その製品に魅力がないんだよ。固定電話が使われないんじゃないかな。ドアホンや固定電話なんて、どうしてもスマホと比較しちゃう。

wifi 連携のあるべき姿。

Google doorbell なんて、顔認識で識別してるし、知らない人が勝手に荷物を持ち出したら通知くるぞ。スマホ連携どころかスマホ前提ですよ。

中華製インターホン見てみろや。1080pでアプリに通知出してんぞ。Androidの技術蓄積が生きてるじゃないか。パナ製品のインターホンのスマホ連携機能は、6-8マンもするのに中華メーカー製8000円で売ってんじゃん。パナは大部分が中国生産ですよね、それで中華メーカにすら太刀打ちできないってなんなのこの会社。やる気あんの。

安く買って早く買い換えるか、高く買って永く使うか

中華ガチャで当たり引くまで粗悪品返品ガチャになる買う気がなかなか、起こらないのだが、パナ製品を見てると心底から呆然としたので、中華ガチャ引こうかなという気になってる。

我が家のドアホンをカメラ付きにしようと、メード・イン・ジャパンを信仰する親世代のために、パナ製品でスマホ対応が出るのを辛抱強く待っていました、初代iphoneを買ってから8年ほどです。辛抱強く待ちましたが、もう我慢の限界です。仕方なく中華メーカーを買うことにする。進歩の早いwifiや暗号方式、そしてカメラ技術を考えると、安い中華メーカーを3年くらいで買い替えた方がずっとマシに思える。

うちの実家はいまだにカメラなしチャイムのみの昭和なので、、早くドアホン・インターホンを買い替えたくてスマホ対応を待って待って待ってたのに、8年待ったよそれで出てきてるパナのインターホン見てゾッとしたよ。なんだこれ。消費者舐めるとかのレベルじゃない。時代に合わない物を堂々と売り、リコールを起こし、ほとんどのご家庭に当たり前のように採用されてる。この現状がもう耐えられない。

改めて、冷静に考えると、ドアホンなんてただの据え置きAndroidでしかない。Androidでもない非暗号化無線で、アプリも中途半端な昭和の電話機がが五万を超える値段で販売されてるの?なんで?おかしくないか?

そして新築マンションや新築住宅に、パナ製ドアホンみたいな昭和の電話機つけんな。許せない。

長く使えない、高い、無駄な機能がついてる。連携できない。もう壊れる前提で中華メーカでGoogle Home assistant / Amazon Alexa 対応のや使うわ。

ここまでが怒り。

どんな製品があれば嬉しいのか。

じゃあどんな製品があれば嬉しいのか。

それを体験してるのがamazon echo show と google nestだよね。コレらモニタ付き機器に対応したドアホンが出ればみんな満足。

パナソニックgoogle nestが出るより前に、ホームハブを売るべきだったんだよ。nature remo内蔵のモニタ付きハブを、ドアホンに接続アダプタ付きで出すべきだったんよ。

全くこの国はどうなっているの。

wifiはいますごく進化してる技術なので、10年以上使うインターホン・ドアホンに「内蔵」するなんて正気の沙汰じゃない。製品寿命を読み間違えてるよ。

PoE とルータ

「オシャレ女子」の「ミニマリスト」のPinterestを見てると、ルータの配線をいかに「隠す」かがメインテーマになっている。PoEを知らない人たちが懸命にACアダプタを隠蔽しているのを見ていると、可哀想って思う。PoEこそ一般家庭に普及させる技術じゃないのかなと思い始めてる。

ドアホンは、昭和レトロの技術で出来てるが、通信と給電を同時に実現した商品です、そういうのを現代に置き直せば、WiFiよりPoEのほうが伸びしろがある気がするんですね。

パナソニックは、PoEに対応したドアホン接続を規格化して開発するべきじゃないですかね。スマート・ホームを標榜なら家庭用にPoEを導入していくのが伸びしろのある事業ドメインじゃないかと思うわけです。

パナソニック家庭用の操作パネル多すぎ

パナソニックの提案するスマート・ホームを導入すると、このリモコンの壁が必要になるんですよ。ちょっと考えられない。全部スマホにまとめるのがスマートホームじゃないんですかね。

f:id:takuya_1st:20211206164853p:plain

まとめ

日本の住宅事情がひどくてリモートワークをしづらいのは、パナ電工に代表される住宅設備機器が時代遅れになってるからではないんですかね。

パナソニックの住宅設備をみてると昭和レトロ技術を延命する会社になってます。

スマホ連携ではなく、スマホ前提な商品を出すべきだったのです。

マネーパワーでNature Remoやスイッチボットの会社の社員ごと引き抜いてくるくらいの危機感がないとパナソニックの住設情報機器の分野は終了すると思う。そしてその終了する企業の製品と連携するような高額な住宅設備を導入したいとは思わないです。

2020年の今に対応できないのなら、ドアホン関連からもう撤退するか、団塊世代の年寄向けに細々と残存者利益で稼ぐだけにしてほしいです。以上

私は、実家の壁に穴を開けてPoE配線を通して、中華ガチャを引く決断をしました。

*1: SMTP Auth だけど、SMTPSに言及が少ない。仮にSMTPSに対応したとしてルート証明書の更新などできるような企業でもなさそうだし。どうするんですかね。 f:id:takuya_1st:20211206163949p:plain