IzIy's Files - MyPress - MyPre.Cn

9月 - 东极!

Sun, 01 Sep 2024 00:00:00 +0000

群晖利用公网服务器ip中转流量与内网无缝切换

Sat, 22 Jun 2024 00:00:00 +0000

最近想起nas的公网访问一直是个问题。中转网络一直不通畅，如果走公网转nas又会过度暴露而被自动扫描攻击,导致硬盘频繁唤醒。

这里实现一套方案，利用公网服务器的ip进行流量转发，并且添加一道简单的防火墙来过滤网络扫描。可以在回家以后自行将流量切换到内网。

在使用公网ip转发的时候，流量和带宽受公网服务器上限所限制。在家中互联场景，本地路由器可以通过拦截公网ip流量，自动转发到nas。免去内外网ip来回切换的问题。

graph TD User1(["User1/Phone/PC"]) -->|Access from local NetWork| B{Router} NAS["NAS lisening:5000(http)/5001(https)"] <-->|In local NetWork| B{Router} Internet{Internet} <--> PubServer[PubServer onPort:80/443/5001] Internet <--> B{Router} User2(["User2/DS File/Photo"]) --> |Access to PubServer:5001| PubServer

主要有以下几个部分实现：

在nas上，将本地端口5000映射到公网ip上，通过 ssh -R 转发。

在计划任务中添加一个bash脚本，建立公网服务器的ssh连接用于端口转发，并设置为开机启动。内容如下：

#!/bin/bash

while true; do
sleep 1
echo "Start Port Forward 5000 @ " `date`
ssh -R 5000:127.0.0.1:5000 yourAccount@YourServer.com -C -q -N -o ServerAliveInterval=60 -o ServerAliveCountMax=10
echo "End of Port Forward 5000 @ " `date`
done;

该脚本启动后会将公网服务器所有来自5000端口的流量转发到nas本身。

5000端口为nas的http服务的连接端口，5001端口为nas的https服务的连接端口。

接下来在公网服务器上配置nginx来实现http流量转发并且配置https端口为5001，通过白名单机制将流量转发到nas。

server {
    server_name yourServerName;
    location / {

#       set $pass_url http://127.0.0.1:8000; # for enter password.
#       if ( $http_user_agent ~ 'Synology-' ) { 
#          // we can also use UA to imp more filters.
           set $pass_url http://127.0.0.1:5000;
#       }
        proxy_pass $pass_url;
        proxy_set_header Host $host:80;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        include <your_list_path>/nas_allow_list.conf;
        deny all;
    }

    location /log {  // 
        set $pass_url http://127.0.0.1:8000; # for enter password
        proxy_pass $pass_url;
        proxy_set_header Host $host:80;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    listen 443 ssl; # managed by Certbot
    listen 5001 ssl; # managed by Certbot
    <the ssh certs config >
}

在上述conf中/log访问点的流量反代到白名单配置程序，可以用于动态更新 nas_allow_list.conf白名单。

一个简单的基于白名单配置程序：

from werkzeug.wrappers import Request, Response
import subprocess

@Request.application
def application(request):
    auth_html = '''<body style="margin: 0;"><div style="margin: auto ; width: 100%; height:100%; border: 2px solid green; padding: 50px 0; text-align: center; "><form  method="POST">
            <input type="password" name="psw" style="line-height: 25px;" value="" required placehold="Enter Text..." />
            <input type="submit" style="width: 90px;height: 30px;" value="Submit" />
        </form></div>'''
    if request.method != "POST":
        return Response(auth_html, content_type="text/html")

    data = request.get_data(cache=False,parse_form_data=True)

    input = request.form.get("psw", None)
    if input != "<Your Pass Word>":
        return Response(auth_html[:-6] + "<red>N/a</red></div>", content_type="text/html")

    iplist = ",".join(request.access_route)
    if request.remote_addr == "127.0.0.1": // the traffic is came from nginx.
        record_addr = request.access_route
    else:
        record_addr = [request.remote_addr]
    for ipaddr in record_addr:
        ipaddr = ''.join(i for i in ipaddr if i in '0123456789.')
        # also we can use firewall to filter te trific
        #cmd = ["firewall-cmd","--zone=sszone","--add-source="+ipaddr+"/32"]
        cmd = ["bash","-c", "echo 'allow "+ipaddr+";'>> <your_list_path>/nas_allow_list.conf"]
        subprocess.check_call(cmd)
        cmd = ["nginx", "-s", "reload"]
        subprocess.check_call(cmd)

    return Response("<h1>You are grand to access, IP<" + iplist + "> has record.<h1>")

if __name__ == "__main__":
    from werkzeug.serving import run_simple
    run_simple("0.0.0.0", 8000, application, threaded=True)

在路由器配置iptables ，将内网client到公网服务器的流量直接转发到local nas:

iptables -t nat -A PREROUTING -d <yourPubServerIP> -p tcp --dport 5001 -j DNAT --to-destination <yourLocalNasIP>:5001

记一次黑群晖系统升级失败之后的数据恢复

Sun, 25 Jun 2023 00:00:00 +0000

最近折腾了一下群晖系统的硬盘休眠, 由于不小心动到了硬盘的RAID设置, 导致系统认定系统盘和数据盘中的系统出现了diverge. 重启之后, 提示需要重装安装系统, 重装失败后系统丢失.

群晖系统要求的重装安装时,操作界面给出了两个选项: 迁移和重新安装.

虽然都提示数据不会改动, 因此没有太在意细节 . 而不小心点到了重新安装, 并且选到了自动更新,(没有手动从官网下载安装包), 没想到安装包没自动下载成功, 直接就安装失败了. 当时也没管,直接强制断电关机睡觉了(这也许是最好的保护软件损毁数据的方法), (原本只需抹去并从启动盘中重新sync一份系统到数据盘, 现在事情弄复杂了.)

第二天起来,发现惊奇的是, 群晖已经将所有系统整个/dev/dm0格式化了.. 格式化这种敏感的操作, 居然不是放在最后等必要条件准备就绪才做. 这波操作让人着迷, 恐怕只有印度小伙能干出来.

Linux数据救援不同于win平台使用PE, 搜寻了一蕃LiveCD的解决方案, systemrescue(https://www.system-rescue.org/) 看起来可以不错,后续使用过程中也都满足了需求,.

基本的disk io操作工具都有,包括testdisk, photorec, parted, mdadm, cifs.

注意: Ubuntu的server版liveCD似乎由于内核没有编译RAID模块, 无法操作raid分区, 已踩坑,不建议用作数据救援.

##正文:

整个硬盘有系统盘和数据盘两块硬盘, 系统盘剩余空间做了数据用.在没有格式化之前系统盘SSD的分区layout是这样子的, 所有硬盘前两个分区分别为synology的system和swap分区, 分区大小一致. 系统盘除了sys/swap分区还有2个启动引导分区(ESP/FAT16)和1个数据分区(挂载到了/dev/DM3)

lanbing$ sudo gpt -r show /dev/disk3
     start      size  index  contents
         0         1         PMBR
         1         1         Pri GPT header
         2        32         Pri GPT table
        34      2014         
      2048   4980480      1  GPT part - A19D880F-05FC-4D3B-A006-743F0F84911E
   4982528   4194304      2  GPT part - A19D880F-05FC-4D3B-A006-743F0F84911E
   9176832     68736         
   9245568     40960      3  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
   9286528     81920      4  GPT part - 142F5F5D-B9E5-4433-87C0-68B6B72699C7
   9368448     68736         
   9437184  70903816      5  GPT part - A19D880F-05FC-4D3B-A006-743F0F84911E
.....      
 110485727        32         Sec GPT table
 110485759         1         Sec GPT header

lanbing$ sudo fdisk -l 
...
  /dev/disk3 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +5.4 GB     disk3
   1:                 Linux_RAID                         2.6 GB     disk3s1
   2:                 Linux_RAID                         2.1 GB     disk3s2
   3:                        EFI NO NAME                 21.0 MB    disk3s3
   4: 142F5F5D-B9E5-4433-87C0-68B6B72699C7               41.9 MB    disk3s4
   5:                 Linux_RAID                         38.3 GB   disk3s5

而被格式化之后, 现在系统盘只剩下system/swap分区其它空间为free/状态. 数据盘的分区表还在, 但系统分区内容也已被清空空.

lanbing$ sudo gpt -r show /dev/disk3
     start      size  index  contents
         0         1         PMBR
         1         1         Pri GPT header
         2        32         Pri GPT table
        34      2014         
      2048   4980480      1  GPT part - A19D880F-05FC-4D3B-A006-743F0F84911E
   4982528   4194304      2  GPT part - A19D880F-05FC-4D3B-A006-743F0F84911E

备份

目前有一块2t SSD空间可以用来做全盘备份.

备份方法, 全盘备份可以用dd. 注意, 不要使用gz, 或tar, 而是使用xz压缩, 如果真的用上了backup,那么结合nbd client/server可以实现decompress on the fly, 参考 [https://unix.stackexchange.com/questions/31669/is-it-possible-to-mount-a-gzip-compressed-dd-image-on-the-fly]

挂载samba备份目录
[root@sysrescue ~]# mount -t cifs -o username=lanbing //192.168.123.166/nas_bak /mnt/nas_bak/
Password for lanbing@//192.168.123.166/nas_bak: 


[root@sysrescue /mnt/nas_bak]# dd if=/dev/sdb bs=4MiB status=progress | xz -0 --threads=4 --block-size=4MiB --check=crc32  > sdb_full_raw_Block4MiB_-0-thread4.img.xz
328837627904 bytes (329 GB, 306 GiB) copied, 44534 s, 7.4 MB/s
562762350592 bytes (563 GB, 524 GiB) copied, 76977 s, 7.3 MB/s
705729396736 bytes (706 GB, 657 GiB) copied, 96124 s, 7.3 MB/s
780731940864 bytes (781 GB, 727 GiB) copied, 105951 s, 7.4 MB/s
799388205056 bytes (799 GB, 744 GiB) copied, 108518 s, 7.4 MB/s
800344506368 bytes (800 GB, 745 GiB) copied, 108636 s, 7.4 MB/s
874453663744 bytes (874 GB, 814 GiB) copied, 118417 s, 7.4 MB/s
934025363456 bytes (934 GB, 870 GiB) copied, 126278 s, 7.4 MB/s
949103886336 bytes (949 GB, 884 GiB) copied, 128327 s, 7.4 MB/s
965440700416 bytes (965 GB, 899 GiB) copied, 130582 s, 7.4 MB/s
971669241856 bytes (972 GB, 905 GiB) copied, 131489 s, 7.4 MB/s
972730400768 bytes (973 GB, 906 GiB) copied, 131654 s, 7.4 MB/s
984688361472 bytes (985 GB, 917 GiB) copied, 133392 s, 7.4 MB/s
991944507392 bytes (992 GB, 924 GiB) copied, 134390 s, 7.4 MB/s
1316285841408 bytes (1.3 TB, 1.2 TiB) copied, 153846 s, 8.6 MB/s 
3000533778432 bytes (3.0 TB, 2.7 TiB) copied, 167043 s, 18.0 MB/s
715397+1 records in
715397+1 records out
3000592982016 bytes (3.0 TB, 2.7 TiB) copied, 167044 s, 18.0 MB/s

备份过程历时两天..

操作

首先使用testdisk 检测分区, 全盘检测之后, testdisk可以识别出系统盘中两个被抹去和一个数据分区.

分区表得以被重建. 并且通过恢复photorec可以恢复大部分系统分区的文件, 但是会丢失文件名.

似乎将ext4格式化成ext4后, backup的superblock的位置是相同的. 因此所有的superblock似乎全被replaced. 这点待确认.

之后,使用mdadm -AsR 可以扫描并自动组建raid盘. 数据分区确实没有丢失.

重装系统后, synology可以识别到两盘中的数据区内容.

然而在群晖的系统 web中显示硬盘已损毁(Crashed), 但数据内容还可以读取, mdadm -D显示存在Fault

admin@LanBingDisk:~$ cat /proc/mdstat 
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
md3 : active raid1 sdh3[0]
      2925444544 blocks super 1.2 [1/1] [U]
      
md2 : active raid1 sdb5[0](E)
      35450880 blocks super 1.2 [1/1] [E]
      
md1 : active raid1 sdb2[0] sdh2[1]
      2097088 blocks [16/2] [UU______________]
      
md0 : active raid1 sdb1[0]
      2490176 blocks [16/1] [U_______________]
      
unused devices: <none>
admin@LanBingDisk:~$ sudo mdadm -D /dev/md2
/dev/md2:
        Version : 1.2
  Creation Time : Mon Aug  8 12:01:00 2022
     Raid Level : raid1
     Array Size : 35450880 (33.81 GiB 36.30 GB)
  Used Dev Size : 35450880 (33.81 GiB 36.30 GB)
   Raid Devices : 1
  Total Devices : 1
    Persistence : Superblock is persistent

    Update Time : Mon Jun 19 18:12:45 2023
          State : clean, FAILED 
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

           Name : LanBingDisk:2  (local to host LanBingDisk)
           UUID : 1730721b:cf36f199:1ddec39d:c541e0dd
         Events : 45

    Number   Major   Minor   RaidDevice State
       0       8       21        0      faulty active sync   /dev/sdb5

可以确定的是,磁盘并没有真正存在物理损毁. 而dmesg显示磁盘读取越界

[   44.037139] md: bind<sdb5>
[   44.039696] md/raid1:md2: active with 1 out of 1 mirrors
[   44.040566] md2: detected capacity change from 0 to 36301701120
[   44.082183] attempt to access beyond end of device
[   44.082190] sdb5: rw=0, want=70903688, limit=70901768
[   44.082196] md_error: sdb5 is being to be set faulty
[   44.082223] attempt to access beyond end of device
[   44.082227] sdb5: rw=0, want=70903688, limit=70901768
[   44.082230] md_error: sdb5 is being to be set faulty

io跑飞了, 原因大概是testdisk并没有正确的判断出sdb5的分区大小.

通过阅读linux的raid模块的源码, raid分区大小至少应该为max(AvailDevSize,UsedDevSize) + DataOffset 个sectors. 貌似通常AvailDevSize==UsedDevSize然而因为分区大小的问题,两者会出现不相等的情况.

遂重新进入LiveCD, 增大分区大小, 重启进synology后,问题依旧但dmesg已经没有report io跑飞的问题.

然而,mdadm -D 结果仍然显示存在Fault.

通过查阅, 原来RAID中的faulty状态不仅存在于内核内存还存在于disk中raid partition的superblock(metadata)中.

mdadm 提供了为disk设置faulty状态的功能, 但没有提供清除faulty状态. 而faulty状态是因为partition size设置不对引起的, 并不是真正在的物理错误. 而按照群晖的提示, 需要删除硬盘重新添加…

一种比较危险的方法是删除raid后, 重新从disk创建raid阵列, 并且通过option强制raid忽略faulty状态…

可能会有数据丢失的风险. 不过亲测有效.

https://serverfault.com/questions/495392/remove-faulty-state-in-raid-1

admin@LanBingDisk:/$ sudo umount /volume1
admin@LanBingDisk:/$ sudo mdadm -S /dev/md2
mdadm: stopped /dev/md2
admin@LanBingDisk:/$ sudo mdadm --create --assume-clean --level=1 --force --raid-devices=1 /dev/md2 /dev/sdb5 
mdadm: /dev/sdb5 appears to be part of a raid array:
       level=raid1 devices=1 ctime=Mon Aug  8 12:01:00 2022
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.
admin@LanBingDisk:/$ sudo mount /dev/md2 /volume1/
admin@LanBingDisk:/$ ls /volume1/
@appstore     @database  @eaDir  photo                     surveillance                 @synologydrive           @tmp
aquota.group  docker     homes   @pkg-SynologyMom.core.gz  @surveillance                @SynologyDriveShareSync  video
aquota.user   @docker    music   @S2S                      @SynologyApplicationService  synoquota.db   

Synology Web 报告系统已经恢复, 但是数据盘系统不存在,需要修复. 点击修复即可.

这点暂时不修复,这样不会使得var/log目录被频繁写入日志而影响机械盘休眠.

结论

如果系统崩溃不可避免,那么掌握一些数据恢复的技巧,是对抗数据丢失的最好的方式.

此外, 在通用的计算机系统概念中, 一个正在使用过程中的系统分区是无法直接格式化的.

可能群晖的kernel/init过程检测到了系统异常后,没有从正常路径启动系统. 而是进入了可以运行在RAM的recovery模式. 而在recovery模式下,安装条件还没有完全满足时, 就已经将dm0格式化, 并且用户主动断电,造成系统盘失效.

显然这不是一个stat-of-art的设计,因为没有考虑到在系统升级的过程中可能发生的异常. 这不仅造成了自己的不便,还提高的自己的售后成本.

一来架构设计迁就了底层技术架构(可能是群晖的设计思想), 二来负责技术开发过程的工程师没有足够的风险意识.

关于Linux/Raid的文章目前比较少,加之多数文章年代久远,很多文章也已经过时.

后续有空再详细分析一下Linux/Raid本身的运行机制,概念,以及相关的操作工具,常见问题等等.

图片伪造技术 - 使用exiftool对图片描述信息进行增删查改

Mon, 20 Jun 2022 00:00:00 +0000

通常，一张图片本身包含其所应该包括的图像像素内容以外，还包含了很多其它描述该图片元信息，比如图片大小，图片拍摄设备，拍摄时间，焦距，地理位置等，若经过中间处理，还可能包含剪辑软件名称，版本号，版权等信息。

图片在互联网上转发的过程中，也可能经过服务器的有陨/无损压缩，格式转换，大小裁剪，水印添加。根据服务器所使用的不同处理程序也有可能对元数据进行增删改等操作。

因此简单通过分析图片的元数据可以获得除本身所能代表的信息以外，还可能可以初步确定图片是否直接来自于手机或相机拍摄，是否经过修改之类。

exIftool是一个功能强大的命令行执行工具，exiftool.org，支持对大量常见的图片格式进行操作。具体信息见其官方网站说明。

一张经过ps处理的图片文件头如下：

一张原始手机拍摄图片的元信息如下：

通过exIftool可能查看完整信息：

LandeMBP:Downloads lanbing$ exiftool -t IMG_20220616_210608_3.jpg
ExifTool Version Number 12.42
File Name   IMG_20220616_210608_3.jpg
Directory   .
File Size   1301 kB
File Modification Date/Time   2022:06:16 23:41:54+08:00
File Access Date/Time   2022:06:16 23:41:55+08:00
File Inode Change Date/Time   2022:06:16 23:41:54+08:00
File Permissions  -rw-r--r--
File Type   JPEG
File Type Extension  jpg
MIME Type   image/jpeg
JFIF Version   1.02
Exif Byte Order   Big-endian (Motorola, MM)
Make  HUAWEI
Camera Model Name ELE-AL00
Orientation Unknown (0)
X Resolution   72
Y Resolution   72
Resolution Unit   inches
Software ELE-AL00 10.0.0.195(C00E85R2P11)
Modify Date 2022:06:16 21:06:10
Y Cb Cr Positioning  Centered
Exposure Time  1/100
F Number 1.8
Exposure Program  Program AE
ISO   80
Exif Version   0210
Date/Time Original   2022:06:16 21:06:10
Create Date 2022:06:16 21:06:10
Components Configuration   Y, Cb, Cr, -
Shutter Speed Value  1/999963296
Aperture Value 1.8
Brightness Value  0
Exposure Compensation   0
Max Aperture Value   1.8
Metering Mode  Multi-segment
Light Source   Daylight
Focal Length   5.6 mm
Maker Note Unknown Text ##**qrf
Sub Sec Time   559638
Sub Sec Time Original   559638
Sub Sec Time Digitized  559638
Flashpix Version  0100
Color Space sRGB
Exif Image Width  2736
Exif Image Height 3648
Sensing Method One-chip color area
File Source Digital Camera
Scene Type  Directly photographed
Custom Rendered   Custom
Exposure Mode  Auto
White Balance  Auto
Digital Zoom Ratio   1
Focal Length In 35mm Format   27 mm
Scene Capture Type   Standard
Gain Control   None
Contrast Normal
Saturation  Normal
Sharpness   Normal
Subject Distance Range  Unknown
GPS Version ID 2.2.0.0
GPS Latitude Ref  North
GPS Longitude Ref East
GPS Altitude Ref  Below Sea Level
GPS Time Stamp 13:06:08

以下是一些简单exiftool应用命令：

copy某文件的TAG信息到别一文件：
exiftool --TAG -TagsFromFile src.jpg desc.jpg

移除文件所有元信息：
exiftool -all= -CommonIFD0= --icc_profile:all target.jpg

移除文件xmp元信息：
exiftool -xmp:all= IMG_20220616_210608_3.jpg

传统文化之偏见

Sat, 04 Jun 2022 00:00:00 +0000

我对传统文化的偏见始于一部名为《天道》的电视剧，剧中主角对养儿防老问题的看法，掀开了我对传统文化的重新认识。

我所认为的传统文化，不仅限于语文教科书中儒道法默等众家，被封建帝王所用于奴隶人民的思想，还包括一部分近代，近现代以及改开之后，老一辈所灌输的某些受封建文化影响的思想。更具体的是指那部分盛行于现代生活之中的。

正如马克思所树立的形面上学的思想一样，传统文化中大部分内容是片面的，是孤立的，是静止。甚至有时候，它伪装成所谓正确的言论，印入脑中，使得无法分辨。“有朋自远方来，不亦说乎”，看起来没有错误，但它并没有强调什么是朋友，而机械式的强调对待朋友的应该友善。在如今的现实生活中，事情并不是非黑既白，人性的多样化，区分不同的人，对待不同的人使用不同的态度，显然更加重要。

因此，传统文化是片面的而非普遍的，是感性的而非理性的，是奴役的而非真理的。人在什么样的文化渲染下成长，便会在其文化下形成某种固有的思维方式，并形成群体性思想。在群体性思想的渲染下，又会反过来影响个人。

我认为文化的作用，应该是对人的方方面面有所启发，引发人的思考，塑造人的价值观，真理观。

我们国家的社会发展，从过去到今天，社会决策，政府运作，也大多在这种文化渲染下进行。一些人口中的政治正确，在一定程序上也就成了传统文化正确。为此，我们是否应该反思，在工业自动化，农业自动化经历了高速发展的今天，人的基本物质得到极大保障的今天，传统文化是否还能肩负得起，解决现代社会问题的重任？

下面总结一些，我认为的传统文化的某些观点，具有误导性，或者不满足现代社会下的应用。

年长者效应

年长意味着经验，在技术发展缓慢，知识无法有效广泛传播的情况下，拥有经验，利用便能解决很多事情。

“所谓不听老人言，吃亏在眼前”之类便是此类渲染下的结果
认为事物通通可以用简单的方法解决

比如“一言以蔽之”，电吹风吹肥皂盒，
注重语言气势，精简，而非其表达含义。

语言的多寡，当然会使其含义变得模糊。因此说得越少错得越少，越模糊越正确。甚至于某些偏激的观点，能够流行于世。比如“不养懒汉”，“都发钱等于不发”等等。
名人必然正确

认为名人没有错误，名人的一切都是正确的。大部分具有影响力的人物维持地位的一个特点就是不在公众场合说与传统文化相左的言论，不做与传统文化相左的事情。影响力的人物大部分对传统文化是依附的。
坚持就会胜利

“铁杵磨成针”的故事背景是在了解的物品研磨特性，或者是具有了成功经验之后的总结。因此，大多数时候不了解情况，就使人盲目相信坚持就会胜利的思想显然是错误的。

一款小型哺乳动物仓笼体温监测与活动检测的装置以及部署方案

Tue, 03 May 2022 00:00:00 +0000

本方案使用物联网技术，通过高精度嵌入式红外摄像头，持续采集仓笼内热源信号，以及动物运动状态，使用嵌入式MCU对感知数据进行前端采集与简单分析，通过Wifi网络上传到数据中心，可形成数据汇总，采集时间跨度短可几周，长则跨年。装置。可按照需求，定制化按时按天按月或按年，生成可视化温度变化曲线，成本低廉，可供学术研究参考，或生物实验佐证使用。

单套设备仅需人民币300～500左右，约合美元60～80，成本低廉。对于单个仓笼，可同时部署多套设备，多套设备数据融合处理，以达到最佳采样角度，确保检测无死角。

方案包含完整装置采购清单，设备运行程序以及设备程序烧录指导，设备联网方法，现场部署指导等一系列指导文档，以及售后指导服务。

方案主体框架如下：

一些国内用户的使用范例：

类似竞品论文参考：

https://journals.plos.org/plosbiology/article?id=10.1371/journal.pbio.3000406 http://journals.plos.org/plosbiology/article/asset?unique&id=info:doi/10.1371/journal.pbio.3000406.s014

合作洽谈可联系：iziy#mypre.cn / c834606877#163.com

一例MusicBox的固件简单分析，基于STM32芯片固件分析总结（待续）

Fri, 01 Apr 2022 00:00:00 +0000

从硬件到软件，制作一个高还原性，高保真的音乐盒子一直是我的兴趣之一。因此，我尝试在淘宝买一些音乐盒子做为设计参考，从双轨正负电压供电电路，电池充放电电路，stm32核心电路，到dac的解码电路，前极放大电路。到USB声卡，sdcard播放等功能。

最近发现某款音乐播放器的固件很有趣，因此，我在这简单记录一下分析过程，顺便总结一下从中学到的一些分析经验。

固件是通过SDcard更新的，商家发布新固件后，将固件放入SDcard后，芯片上的bootloader会检测并触发更新。

固件的部分内容如下：

经过分析，固件使用了简单的压缩，一来减少固件体积，二是有校验机制。

通常，固件前一部分内容是，固件定义的栈顶指针以及芯片的中断向量表，均为4字节对齐。

栈顶指针通常是指向芯片的ram区域最后一个字节的下一个字节的地址。

中断向量表中第一个内容便是固件的start地址，用于重新初始化PC寄存器的内容。根据编译器的不同，通常会指向固件的尾部区域。

可能通过头部的一明显特征，对固件进行还原，经过恢复之后的固件头部如下：

接下来是固件的起始地址猜测，

固件的大小在700k左右，恢复后的大小在1.1MB左右，如果0x08124839确实是pc的跳转地址的话，通过分析和测试，可以确定固件的起始地址在0x08030000。载入ida后，根据芯片手册上的memory map表配置好ram和rom区域，将固件载入到0x08030000后，跳转到起始地址，可以看到明显的入口特征。

注意：由于stm32f系列处理仅支持thumb2指令，因此，在ida载入处理器选项中，需要选择cortex-m系列，以及thumb2指令集并取消自动识别thumb段寄存器。通过Alt-G可快速切换T段寄存器的值。

至此，可以根据情况进一步分析，实现一些mod功能。包括可能使用自定义的固件来反向提取bootloader，

甚至依赖现有硬件平台，编写自定义的固件功能。

（未完待续）（未完待续）

在Padavan上实现支持RTSP网络摄像头的录像机功能

Sun, 20 Feb 2022 00:00:00 +0000

基于mt7621处理器的路由器通常都具有一个可扩展的USB接口，可以转接U盘，硬盘或者USB网卡之类。

既是路由器也是一个小型网络存储器，可省去额外配置一个nas，相比nas功能比较少，但也具有一定的可配置性。

这里简单介绍如何在运行类openwrt系统的路由器上实现网络录像机(NVR)的功能。

如今网络上的云摄像头已经卖到100元上下了，有萤石云摄像头，360摄像头，小米摄像头，TP-Link等，但这类型的摄像头都需要额外购买云存储服务才存储回放录像，显然这部分附加服务不具有性价比。

按照专物专用的原则，一台群晖也可以解决，但毕竟要多出一个东西。因此在路由器上实现类似NVR功能是最经济的做法。

很多云摄像头的商品描述页面，并不会直接写明支持RTSP传输，但会写支持NVR功能。

据我了解，TPLink全系均支持NVR功能，莹石云摄像机官方未显式支持但C2C/C3C/C6C等几个型号存在RTSP协议。

下面开始正文。

运行在路由器上的openwrt是支持entware的，而entware作为一个基础运行环境，移植了大量开源应用程序，包括libx264, ffmpeg等。

这里介绍如何安装entware并且进行rtsp数据拉取存储。

在路由器配置界面开启SSH登录配置，并通过ssh登录到路由器
创建/opt 并且用一部分内存挂载为内存文件系统

mkdir /opt && mount -t tmpfs -o size=50m tmpfs /opt
下载并安装entware运行环境，

wget  http://bin.entware.net/mipselsf-k3.4/installer/generic.sh -O /tmp/entware_installer.sh
chmod +x /tmp/entware_installer.sh
sh /tmp/entware_installer.sh

该脚本会安装opkg工具，可能通过运行opkg来确定环境是否安装成功，另外请注意

wget  http://bin.entware.net/mipselsf-k3.4/installer/generic.sh -O /tmp/entware_installer.sh
chmod +x /tmp/entware_installer.sh
sh /tmp/entware_installer.sh

该脚本会安装opkg工具，可能通过运行opkg来确定环境是否安装成功
下面安装ffmpeg
```
opkg install ffmpeg
```
opkg 会安装软件所需要的依赖。另外请注意entware.net作为国外网站，并且entware官方目前不允许作为镜像网站的存在，因此，可能出现偶然性的失败。多

安装好ffmpeg后，可通过 ffmpeg命令来查看ffmpeg的编译选项和版本信息。

/tmp # ffmpeg -decoders
ffmpeg version 4.3.2 Copyright (c) 2000-2021 the FFmpeg developers
  built with gcc 8.4.0 (OpenWrt GCC 8.4.0 r1808-45c16d86)
  configuration: --enable-cross-compile --cross-prefix=mipsel-openwrt-linux-gnu- --arch=mipsel --cpu=mips32r2 --target-os=linux --prefix=/opt --pkg-config=pkg-config --enable-shared --enable-static --enable-pthreads --enable-zlib --disable-doc --disable-debug --disable-lzma --disable-vaapi --disable-vdpau --disable-outdevs --disable-altivec --disable-vsx --disable-power8 --disable-armv5te --disable-armv6 --disable-armv6t2 --disable-fast-unaligned --disable-runtime-cpudetect --disable-x86asm --enable-gnutls --enable-libopus --enable-small --enable-libshine --enable-gpl --enable-libx264
  libavutil      56. 51.100 / 56. 51.100
  libavcodec     58. 91.100 / 58. 91.100
  libavformat    58. 45.100 / 58. 45.100
  libavdevice    58. 10.100 / 58. 10.100
  libavfilter     7. 85.100 /  7. 85.100
  libswscale      5.  7.100 /  5.  7.100
  libswresample   3.  7.100 /  3.  7.100
  libpostproc    55.  7.100 / 55.  7.100

在摄像头方面，假设已经拿到了rtsp的流地址，可能过vlc等软件验证。这里演示的rtsp地址如下。

rtsp://192.168.123.112/stream1
使用ffmpeg保存录像内容。
```
ffmpeg -i rtsp://192.168.123.112/stream1 -acodec copy -vcodec copy test.mp4
```
这里要注意的是，acodec和vcodec都使用rtsp stream原本传输的音视频格式直接保存。而不进行任何编解码格式的转换，这是为了避免引入大量cpu资源，特别是vcodec。除非在mp4不支持包含某些codec的情况下，才需要进行转码，并且关注此期间的cpu负载情况。

它看起来像是个U盘，实际上是个Wireless KeyBoard/Mouse

Sun, 05 Dec 2021 08:30:55 +0000

UDP Server run on esp8266 over wifi 2.4ghz. USB HID keyboard based on ch9329 ic. 没有时间写总结，暂时放两张图片在这里吧。

多站共存的Nginx配置下使用腾讯云CDN加速Discourse出现乱码的问题

Sat, 21 Aug 2021 00:00:00 +0000

上文讲述了在国内环境下加速Discourse的部署过程。

Discourse官方并不建议在同一主机上部署多个站点，但也提供了方案：Running other websites on the same machine as Discourse。

按照官方的提供方案部署，通常可以正常将Discourse运行在standlone模式下，再通过Nginx反代访问。https的实现通过certbot也可以简单完成。

以下是nginx配置exsample:

server {
    listen 80; listen [::]:80;
    server_name forum.example.com;  # <-- change this

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;  listen [::]:443 ssl http2;
    server_name forum.example.com;  # <-- change this

    ssl_certificate      /var/discourse/shared/standalone/ssl/ssl.crt;
    ssl_certificate_key  /var/discourse/shared/standalone/ssl/ssl.key;
    ssl_dhparam          /var/discourse/shared/standalone/ssl/dhparams.pem;
    ssl_session_tickets off;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA;

    http2_idle_timeout 5m; # up from 3m default
    client_max_body_size 0;

    location / {
        proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock:;
        proxy_set_header Host $http_host;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

其中，需要注意的是，X-Forwarded-Proto用于将前端nginx接收到的请求ssl/no_ssl类型传递到后端，后端根据https或者是http生成包含不同静态资源链接的内容.

在一次今年4月的一次更新中，Discourse社区的一次改动决定，只要前端连接为https，后端则会__无条件__使用brotli压缩数据并返回内容。返回的Header包含 Content-Encoding: br。

Brotli是一种专门为http协议优化过的压缩方式，比gzip压缩率提升20%左右。虽然brotli算法在实际使用中已经存在五六年多了，主流浏览器早已支持，也相当成熟。浏览器在访问https页面时，通常会在请求header中包含：Accept-Encoding: gzip, deflate, br，br即brotli。

然而，在某些情况下，有些程序并没有良好的支持Brotli，比如curl，国内的某些cdn服务商, 在获取静态资源时，并没有指定 Accept-Encoding, 或者指定的压缩算法中不包含br. 但后端仍然会返回Brotli压缩过的内容，导致客户端解析出错。

在此情况下，可通过rewrite功能，将Brotli资源重写向到gzip资源中。添加如下语句到上述nginx中即可解决问题。

    if ($http_accept_encoding !~ .*br.*)
    {
        rewrite /brotli_asset/(.*) /assets/$1 last;
    }