当前位置

博客

Surface Laptop 上遭遇 UEFI 循环

早上翻开 Surface Laptop,旁边有点事,没有立刻出现在摄像头前,不知道是不是这个原因,可能它觉得识别了半天识别不到人,于是就自己进入 UEFI 了。第一次进,感觉像以前的 BIOS。

点重启按钮,田字 logo 闪了几下又进来了,长按 Power 键,强制关机,再按一下开机,田字 logo 闪了几下又进来了。

于是打开手机,搜 surface uefi,自动提示 surface uefi loop,就是这个现象,选了一个搜索结果。

'Restart to Surface UEFI' loop - I restarted many times without security settings showing

里面的回答翻译如下:

Have you tried 2-button shutdown?
你试过双键关机么?

Step 1: Press and hold the power button on your Surface for 30 seconds and then release it.
第一步:长按 power 键 30 秒,然后松开按键。

Step 2: Press and hold the volume-up button and the power button at the same time for at least 15 seconds and then release both.
第二步:增大音量键和 power 键同时按住至少 15 秒,然后松开这两个按键。

The screen may flash the Surface logo, but continue holding the buttons down for at least 15 seconds.
Surface 的 logo 也许会在屏幕上闪动,不要管它继续按住这两个按键至少 15 秒。

Step 3: After you release the buttons, wait 10 seconds.
第三步:松开这两个按键后等 10 秒。

Step 4: Press and release the power button to turn your Surface back on.
第四步:按 power 键即可启动你的 Surface。

上述步骤我试了一遍,成功启动。但是看原链接的回复,似乎没有解决提问者的问题。

Topic: 

安全 DNS

传统 DNS 由于采用了 UDP 协议,以及 53 公开端口,导致很容易被运营商劫持,或者被不知道哪里的设备来一个抢先应答... 许多厂商也包括标准化组织一直在想办法改进它:

1. DNSSEC,这个提出得最早,目的之一是确认应答的有效性。我理解这个方案解决了权威域名解析的安全基础架构,但还得依赖于为最终用户提供服务的转发服务器的实现
2. DNS over TLS & DNS over HTTPS(HTTP/2),这两项技术保障用户访问转发服务的安全传输,是 DNS 安全体系中另外重要的一环。DoT 是传统 DNS tcp 协议传输增加 TLS 通道,DoH 具体实现则有两个变种,当前正在标准化的阶段
3. 国际几个 Public Resolver 大厂都支持上述两类连接,包括 1.1.1.1、9.9.9.9,以及谷歌的 8.8.8.8
4. 但是在本地解析服务的部署上,变化要缓慢得多。当前几个重要的进展是:a) Android Pie 支持 DoT;b) systemd-resolved release-239 支持 DoT(2018年6月);c) firefox 62 将正式支持 DoH

安全 DNS 是安全网络环境的起点,由于我在过去配置家庭路由器中碰到的种种不靠谱,打算自己搞一个安全 DNS 服务,希望能为净化大环境起到一些微小的贡献

在当前这个时间点,要使用上安全 DNS 对普通人还是有一点费劲,要做的事情不仅仅是架 Server,而应该是一整套解决方案。正在摸索中...

手动编辑 PEAP 认证所需要 wpa_supplicant 配置内容

参考 https://eparon.me/2016/09/09/rpi3-enterprise-wifi.html

最核心的工作:

  1.         echo -n 'password_in_plaintext' | iconv -t utf16le | openssl md4
  2.         history -d num 保持安全

配置文件内容见下:我司的 Phase 2 authentication 认证用的是 MSCHAPV2/无证书,请酌情修补

country=CN
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
ssid="SOHU.COM-2.4G"
priority=1
proto=RSN
key_mgmt=WPA-EAP
pairwise=CCMP
auth_alg=OPEN
eap=PEAP
identity="qiuyingbo"
password=hash:XXXXXXXXXXXXXXXXXXXXXX
phase1="peaplabel=0"
phase2="auth=MSCHAPV2"
}

Topic: 

ChinaDNS 的原理

ChinaDNS 的说明语焉不详,一直觉得是伪科学——它的基本原理是
1. 把同一个域名送到国内国际两个域名上解析,比如 114 和 8
2. 如果从 114 得到的是一个国际IP (国内DNS说它是一个外国网站),那么外国网站自然不如 8 返回的可信

前两天看了 V2EX 上的一条讨论 https://www.v2ex.com/t/460686 , rio 也表示:“ChinaDNS 分流基于一个核心假设,就是被污染域名都解析到非 China IP。这个假设在目前是成立的,但似乎并没有什么客观原因认为它一定成立”

是啊,理论上可以把 google.com 返回成金盾官网呢,向群众展示厉国的神力

Topic: 

RTL8188CUS 网卡在树莓派 Raspbian Stretch/Kernel 4.14.x 中的情况

前文:树莓派做路由器 2018.03 (Part 2) hostapd 和 RTL8188CUS 网卡,如何在 Raspbian Stretch/Kernel 4.9.x 下工作?

三个月之后,随着 Raspbian 把内核从 4.9.x LTS 升级到下一个 LTS 4.14.x,麻烦又来了
在这三个月里又断断续续尝试了 Pi Zero W(有内置的 BCM 无线网卡),以及 Ralink 的 RT3070 USB 网卡等,当前的结论是:
a. RT3070 做 AP 最稳定
b. Pi Zero W 的内置无线网卡能用,网上甚至有让它同时做 STA + AP 的例子,但兼容性不那么好,无法支持 chromecast 的 chrome tab 串流
c. RTL8188CUS 在 4.9.x 下尚能较稳定的工作,但到了 4.14.x 下还需要摸索摸索

  1. 内核主线里有一个 rtl8192cu 的模块,来自 realtek 的驱动源码
  2. 后来主线里又有了一个 rtl8xxxu 的模块,似乎是 realtek 自己不用心维护驱动,所以社区社区自己开干。据说这个还是靠谱的,但——直到目前还没有缺省支持 0bda:8176 (需要编译时额外增加 UNTEST 选项),以及还不支持 AP Mode
  3. 为了解决 rtl8192cu 的问题,所以有了 https://github.com/pvaret/rtl8192cu-fixes.git 项目,它编译后的模块名改成了 8192cu 以避免和主线冲突;至少直到 4.9.x 内核,还是能和 hostapd patch 后的 rtl871xdrv 一起愉快的工作
  4. 但是到了 4.14.x,rtl871xdrv 出问题了,报 ioctl[RTL_IOCTL_HOSTAPD]: Operation not supported ,可参考 https://forum.odroid.com/viewtopic.php?f=146&t=29195#p208592
  5. 话说 odroid.com 这个公司似乎是专门销售网络硬件方案的,其中 WiFi module #3 就是用 realtek 的这款芯片,所以它必须解决问题。。。
  6. 然后该公司发现,使用4.14.x主线的 rtl8192cu就能用 hostapd 的 nl80211 驱动来跑 AP,甚至无需给 hostapd 2.6 打补丁:https://forum.odroid.com/viewtopic.php?f=146&t=27287
  7. 按照它给的方法,确实能启动热点,客户机也能连上,但就最近两天的情况看并不稳定

...需要时间继续检验...

Topic: 

将 mp3 投/cast 到 chromecast 设备上

作为一个音箱,哪怕是冠以智能音箱的名义,也是必须要能满足用户想放什么声音,就能放出什么的需求的

所以,如果玩家没有 Spotify 之类的流媒体帐号,又或者是有独家珍藏的 MP3 file,怎样在 49$ 的设备上把声音播放出来呢?Echo dot 可以作为 bluetooth speaker 和手机配对,Google Home Mini 自然就是 chromecast 了

想到树莓派非常适合做家庭媒体中心,调研了一番从 Linux 主机 cast 到 chromecast 设备的方案。。。被 Raspbian Stretch 内置的 mkchromecast 似乎必须要一个桌面环境,抛弃。。。然后发现 stream2chromecast 出乎意料的靠谱,至少目前放个 mp3 ,命令行再控制一下音量是毫无问题的。。。

下一步就是开发 Alexa skills or Google Actions 让我可以赖在沙发上指挥这个树莓派了...

再等过两天 chromecast 到货后试一下 stream2chromecast 播放视频的能力;以及要是有功夫看看 VLC 3.0 能不能在 Raspbian Stretch 上编译通过和命令行工具 cvlc 的情况

UPDATE: 2018/03/21

  1. qyt 今天提示我有一个 My Media for Amazon Alexa,上亚马逊看了一下评分,还真的很高
  2. chromecast 2Gen 到货,stream2chromecast 投 mp4 视频毫无问题;VLC 3.0 的编译放弃了,steam2chromecast 是 python 开发的已然足够方便
Topic: 

关于路由器配置海内外流量分发

虽然搭树莓派的最初原因只是想使用 Google Home Mini,但这个跑起来后不可避免的就想用它来带其它设备上网,毕竟 iOS 装个 ss 客户端还是挺麻烦的不是?

研究一番,发现 tcp 流量分发异常简单

  1. sudo apt install ipset
  2. 然后创建中国地区的网络地址表,以及生成 ipset 的脚本;可以放在 cron 里每周更新一下
    • https://github.com/17mon/china_ip_list 下载来自 ipip.net 最专业的国内IP表
    • echo "ipset -N chnroute hash:net maxelem 65536">chnroute.sh; chmod +x chnroute.sh; for i in `cat china_ip_list.txt`; do echo "ipset add chnroute "$i >>chnroute.sh; done
  3. 每次启动系统的时候首先执行一次 chnroute.sh,最后在 iptables 设置 bypass 的命令中,增加如下一行
    • iptables -t nat -A SHADOWSOCKS -p tcp -m set --match-set chnroute dst -j RETURN

    现在可以访问一下国内的网站看看是否正确寻路出去了

看其它人的配置,往往还有 ChinaDNS 一项;仔细思索了一下它号称的原理,觉得从逻辑上投毒同正常业务的DNS海内外解析无法分辨的,如果仅仅依赖一个 chnroute.txt 完全做不到信任新浪的国内解析但不信任谷歌的国内解析。。。所以就不部署它了

Topic: 
订阅 RSS - 博客