博客

  • frp的xtcp打洞测试

    • 在windows上无论如何都会失败(windows成功率更低)
      后来发现只是我这台电脑有问题,不过仍然说明兼容性并不好
    • xtcp依懒于stun,然而并没有稳定的stun服务器,自建的stun服务器都用不了(可能需要开放全部端口才行)
      国内可用的stun服务器stun.miwifi.com:3478,stun.qq.com:3478
    • stun测试
      执行命令./frpc nathole discover --nat_hole_stun_server stun.miwifi.com:3478,如果 正确返回IP端口号则说明stun能正确工作,如果不能xtcp大概率也不会通
    • 从结果来看xtcp的打洞成功率远低于wireguard+wgsd

    Views: 167

  • WireGuard部署及NAT打洞

    主要参考文档:

    wireguard文档
    相关中文翻译
    – https://blog.51cto.com/u_15077562/4574884
    – https://icloudnative.io/posts/wireguard-docs-theory/
    nat穿透
    相关中文翻译
    – https://xie.infoq.cn/article/3f68cde0163b359b13fa1a8f0
    – https://icloudnative.io/posts/wireguard-endpoint-discovery-nat-traversal/

    总结

    • nat穿透的时候需要NAT后的节点共同连到一个有公网IP的节点上
    • 在nat背后的两个节点相连的时候需要至少一个是全椎形NAT,或者双方都为限制椎形
    • coredns部署在具有公网IP的节点上
    • wgsd_client需要在nat背后的节点上定时运行,可以5分钟或10分钟一次
    • wgsd的代码可以自己编译,尤其在windows上只能自己编译,在对应目录中运行go build就可以了
    • nat状态表的过期时间一般为2分钟,所以keepalive周期最好在1分钟以内
    • nat后节点不需要与公网节点能正常通信,只需要能向公网节点发起连接就行,所以coredns最好在公网开放端口,这样在不能与公网节点通信时也能用
    • 运营商级NAT都不是全椎形
    • nat类型探测工具
      https://github.com/HMBSbige/NatTypeTester
    • nat类型介绍
      https://support.huawei.com/hedex/hdx.do?docid=EDOC1100331440&id=ZH-CN_CONCEPT_0183792552
      https://zhuanlan.zhihu.com/p/657998085

    Views: 808

  • windows10/11禁用和开启Hyper-V

    1. 禁用
      bcdedit /set hypervisorlaunchtype off
    2. 开启
      bcdedit /set hypervisorlaunchtype auto

    Views: 61

  • 生成HPE ILO证书

    使用.NET远程控制台的时候发现会有证书错误,导致无法使用.NET远程控制台,所以用acme.sh生成正确的证书
    登录ILO后找到存取管理->安全性,然后点击自定义证书,填写正确的域名,生成CSR,等一会儿再点一次生成CSR,把CSR保存下来
    然后执行命令

    acme.sh  --signcsr --csr dl360.csr --dns dns_gd
    acme.sh --install-cert -d dl360.hetao.me --fullchain-file /opt/certs/dl360.hetao.me/fullchain.pem --cert-file /opt/certs/dl360.hetao.me/dl360.hetao.me.pem
    cd /opt/certs/dl360.hetao.me
    sed '4r dl360.hetao.me.pem' ilocert.cfg>dl360cert.cfg
    hponcfg -f dl360cert.cfg
    


    ilocert.cfg的内容如下

    <RIBCL VERSION="2.0">
    <LOGIN USER_LOGIN = "adminname" PASSWORD = "password">
    <RIB_INFO MODE = "write">
    <IMPORT_CERTIFICATE>
    <!-- Replace the following text and comments with the certificate -->
    <!-- INCLUDE the full header and full footer of the certificate -->
    </IMPORT_CERTIFICATE>
    <!-- The iLO will be reset after the certificate has been imported. -->
    <RESET_RIB/>
    </RIB_INFO>
    </LOGIN>
    </RIBCL>
    

    也可以用命令行操作

    然后会生成证书文件dl360.hetao.me.pem(不是fullchain.pem),把里面的证书再粘到ILO中,ILO会自动重置,ILO再次启动后就好了,.NET远程控制台也能用了。
    注意:
    ilo固件刷新后需要重新生成CSR,不然导入证书时会不识别

    Views: 59

  • pve(KVM)中抑制ignored rdmsr消息

    这个问题跟nvidia显卡虚拟化有关,执行以下命令可解决
    echo “options vfio_iommu_type1 allow_unsafe_interrupts=1” > /etc/modprobe.d/iommu_unsafe_interrupts.conf && update-initramfs -u -k all

    参考:
    https://pve.proxmox.com/wiki/PCI_Passthrough#NVIDIA_Tips

    Views: 33

  • PVE安装Tesla P4并实现GPU虚拟化

    硬件介绍

    P4的参数相当于GTX1080,是一个半高单槽的卡,另外P100(HBM2)和P40(GDDR5X)是双槽全高的卡,具体比较可以看这里:

    https://developer.aliyun.com/article/753454
    https://cloud-atlas.readthedocs.io/zh_CN/latest/machine_learning/hardware/nvidia_gpu/tesla_p10.html

    P4适用于1U的服务器,P40和P100适用于2U的机器,价格比P4要贵一倍多,在HP 360 Gen9服务器上P4可以直接安装。

    关于HP DL360 Gen9服务器的介绍,这个是别人写的,我贴过来:
    https://cloud-atlas.readthedocs.io/zh_CN/latest/linux/server/hardware/hpe/hpe_dl360_gen9.html
    360GGen9的扩展能力比较小,最多只能安装两张GPU卡,再加一个SSD就满了。
    支持vGPU的显卡列表:
    https://docs.nvidia.com/grid/gpus-supported-by-vgpu.html
    桌面显卡启用vGPU:
    https://gitlab.com/polloloco/vgpu-proxmox

    host驱动安装

    • 开启IOMMU
      编辑/etc/default/grub,在quiet后面添加intel_iommu=on iommu=pt
    • 安装驱动
      apt install pve-headers-$(uname -r)
      apt install build-essential dkms pve-headers mdevctl
      echo -e "vfio\nvfio_iommu_type1\nvfio_pci\nvfio_virqfd" >> /etc/modules
      echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
      echo "options nouveau modeset=0" >> /etc/modprobe.d/blacklist.conf
      update-initramfs -u -k all
      chmod +x NVIDIA-Linux-x86_64-535.104.06-vgpu-kvm.run
      ./NVIDIA-Linux-x86_64-535.104.06-vgpu-kvm.run --dkms
      reboot
      

      用nvidia-smq命令可以查看显卡的工作状态
      用mdevctl types命令可以查看支持的vGPU实例类型和数量,所有vGPU实例需要用完全相同的规格,显存也是等分的,不能超额分配。如果要支持8K显示至少要2G显存,如果4K显示1G就够了。

    虚拟机配置

    vGPU实例类型参考这里:
    https://docs.nvidia.com/grid/13.0/grid-vgpu-user-guide/index.html#virtual-gpu-types-grid
    – 添加虚拟机
    先添加虚拟机实例,安装好virtio-gt和virtio-gm程序,虚拟机配置中开启qemu-guest-agnet,bios不要选uefi(装驱动时需要重新签名)

    • 安装远程桌面
      apt install xrdp

    • 禁用或删除nvidia开源驱动

      apt remove nvidia-*
      echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
      echo "options nouveau modeset=0" >> /etc/modprobe.d/blacklist.conf
      

      不然的话在添加vGPU后有可能黑屏

    • 添加PCI设备
      硬件->添加->PCI设备
      pci配置
      这里面列出的设备可能比较多,要仔细找

    guest驱动安装

    以Debian为例
    – 开启xorg(关闭wayland)
    编辑/etc/gdm3/daemon.conf,添加
    WaylandEnable=false

    • 更新系统
      sudo apt update
      sudo apt upgrade
      reboot
      
    • 安装依懒
      sudo apt install dkms build-essential dkms jq uuid-runtime -y
      sudo apt install -y linux-headers-$(uname -r)
      sudo apt install pkg-config libglvnd-dev -y
      
    • 安装驱动
      init 3
      echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
      echo "options nouveau modeset=0" >> /etc/modprobe.d/blacklist.conf
      update-initramfs -u -k all
      chmod +x NVIDIA-Linux-x86_64-535.104.05-grid.run
      ./NVIDIA-Linux-x86_64-535.104.05-grid.run --dkms
      reboot
      
    • 授权
      curl --insecure -L -X GET https://dls.hetao.me/-/client-token -o /etc/nvidia/ClientConfigToken/client_configuration_token_$(date '+%d-%m-%Y-%H-%M-%S').tok
      service nvidia-gridd restart
      nvidia-smi -q | grep "License" #要等大约1分种后才能看到结果,每次授权的有效期是3个月
      
    • 远程
      apt install xrdp
      在我使用的时候发现rdp不能在本地户用登录的状态下使用,反之使用rdp的时候本地也无法登录(黑屏)
      Debian本身带的也有桌面共享,是基于rdp协议的,但是我没有连成功,最后还是安装的xrdp。

    • 驱动下载
      现在可用的下载链接:
      https://alist.homelabproject.cc/foxipan/vGPU
      https://yun.yangwenqing.com/ESXI_PVE/vGPU/NVIDIA
      https://pan.hetao.me/s/RHMxwE95QwmGmAG
      已经不能下载:
      https://foxi.buduanwang.vip/pan/vGPU/
      https://foxi.buduanwang.vip/pan/foxi/Virtualization/vGPU/
      https://github.com/justin-himself/NVIDIA-VGPU-Driver-Archive
      https://archive.biggerthanshit.com/NVIDIA/

    参考:
    https://gitlab.com/polloloco/vgpu-proxmox/-/tree/master

    Views: 343

  • 什么是5G RedCap?

    近日,工信部发布《关于推进5G轻量化(RedCap)技术演进和应用创新发展的通知(征求意见稿)》,提出到2025年,5G RedCap产业综合能力显著提升,新产品、新模式不断涌现,融合应用规模上量,安全能力同步增强。其中,全国县级以上城市实现5G RedCap规模覆盖,5G RedCap连接数实现千万级增长。

    一时间,RedCap再次成为业界关注的焦点。

    那到底什么是RedCap?我们今天来展开讲讲。

    蜂窝物联技术演进

    先来画一张蜂窝物联技术演进图。


    自Release 8以来,在移动宽带(MBB/eMBB)速率不断增长的同时,3GPP也引入了LTE Cat 1、Cat 1 bis、eMTC、NB-IoT、EC-GSM、RedCap等多种蜂窝物联技术。

    这些蜂窝物联技术通过不同程度的“功能裁剪”来降低终端和模组的复杂度、成本、尺寸和功耗等指标,从而“量体裁衣”适配不同的物联需求。

    简单介绍一下:

    • LTE Cat 1/LTE Cat 1 bis:

    LTE Cat 1是3GPP Release 8专门为M2M物联应用制定的蜂窝物联技术,信道带宽为20MHz,下行峰值速率为10Mbps,上行为5Mbps。

    LTE Cat1 bis提出于Release 13,作为Cat 1的演进,它进一步将LTE Cat 1终端的双接收天线裁剪为单接收天线。

    • LTE Cat 0/eMTC:

    LTE Cat 0是3GPP Release 12提出的适用于物联应用的UE类型,信道带宽为20MHz,上下行峰值速率为1Mbps。LTE Cat 0支持单接收天线和半双工模式,因此与LTE Cat 1相比,终端复杂度下降至少50%。

    在Release 13中,LTE Cat 0演进为eMTC或LTE-M(Cat M1)。由于最大信道带宽缩减至1.4MHz,LTE Cat M1相比LTE Cat 0的复杂度进一步减小,覆盖能力得到进一步提升。

    之后,eMTC演进至5G时代的Release 15和Release 16,功能持续增强。

    • NB-IoT:

    NB-IoT是3GPP Release 13引入的窄带物联技术,信道带宽为180KHz,峰值速率几十至200Kbps左右。

    与eMTC一样,NB-IoT也从4G时代的Release 13、Release14持续演进至5G时代,功能不断增强,共同推动5G Massive IoT发展。

    • EC-GSM-IoT:

    EC-GSM-IoT是3GPP Release 13规范的一部分,主要由2G技术升级演变而来,可通过2G GSM网络软件升级实现,信道带宽为200KHz,峰值速率约70至240Kbps。

    • RedCap:

    RedCap制定于5G Release 17版本,全称Reduced Capability NR,即“裁剪NR能力”的意思,所以也被称为轻量版、简化版的5G NR。

    为什么要引入RedCap?

    众所周知,5G最初定义了eMBB、uRLLC和mMTC三大场景,与之相对应,5G时代的物联网类型包括宽带物联网、关键任务型物联网和大规模物联网。


    eMBB主要针对高清视频、VR/AR等大带宽应用,通常网络下行峰值速率高达Gbps,上行达几百Mbps。

    uRLLC主要针对远程控制、无人驾驶等关键任务型物联网应用,要求网络端到端时延低至毫秒级,可靠性高达5个9。

    而mMTC由4G时代的NB-IoT和eMTC低功耗广域物联网技术演进而来,主要面向智能抄表、智能路灯等大规模物联网场景,对数据传输速率和时延要求很低,网速小于2Mbps,时延可容忍至10秒。

    虽然这三大场景差异化匹配了高速率、低时延和低速率的物联应用需求,但细心的你一定发现了,那些对速率和时延要求中等的物联网应用还没有覆盖到。

    比如,用于测量和采集温度、湿度、压力等数据的工业无线传感器要求数据传输速率约2Mbps,时延小于100毫秒,可靠性仅需99.99%;智能手表、医疗监控设备、AR/VR眼镜等可穿戴设备要求数据传输速率约2至10Mbps;监控摄像头要求数据传输速率约2至25Mbps,时延小于500毫秒,可靠性仅需99%至99.9%。

    这些物联网场景如果用eMBB和uRLLC能力来支撑,就是大材小用、资源浪费,而mMTC的速率和时延能力又不能满足需求。

    RedCap,正是为了填补eMBB、mMTC与uRLLC之间的“空白地带”而生的蜂窝物联技术。

    正如演进图中所示,RedCap位于中间位置。如果根据带宽、时延、成本、终端功耗、覆盖距离等技术指标将5G蜂窝物联网分为低、中、高三个档位,那么RedCap就是5G时代的“中档”物联技术。

    RedCap裁剪了哪些能力?

    640?wx_fmt=png
    如上表,Release 17 RedCap主要裁剪了以下功能,从而将终端复杂度和成本下降50%至65%。

    • 最大带宽从NR的100MHz缩减为20MHz
    • 天线配置从NR的2T4R减少到1T1R或1T2R
    • 最小下行MIMO层数减少至1
    • 最大调制阶数最低可支持64QAM
    • 引入了半双工模式

    为了实现更高的峰值速率,RedCap终端设备也可以不用裁剪得这么狠,可以选择更高级的功能,比如支持2个接收天线、2个下行MIMO层、256QAM、全双工FDD等。

    通过这些能力剪裁,可更加低成本、高效率地匹配可穿戴设备(包括可穿戴手表、AR/VR眼镜等)、工业无线传感器、监控摄像头等物联应用的网络连接需求。

    同时,针对可穿戴设备、工业无线传感器等通常没有外部供电条件的场景,要求电池使用寿命长达1-2周甚至数年,RedCap还通过降低终端发射功率等级、引入eDRX和RRM测量放松等节电技术,来进一步降低终端功耗。

    RedCap将取代谁?

    比较一下技术指标,很明显,RedCap主要将取代4G时代的LTE Cat 4和LTE Cat 1/1 bis。

    准确点讲,Release 17版本的RedCap预计将取代基于LTE Cat 4的物联应用。而Release 18版本中的RedCap,即增强版RedCap预计将取代基于LTE Cat 1和LTE Cat 1 bis的物联应用。

    在R18版本中,增强版的RedCap或将增加支持5MHz、10MHz和40MHz带宽,并进一步降低终端复杂度和成本,以及增加定位、sidelink连接等功能,从而支撑更广泛的物联应用。

    为啥要取代LTE Cat 4和Cat 1/1bis?

    首先,RedCap为4G时代的LTE Cat1/1 bis和Cat 4提供了向5G网络迁移的路径,面向未来利于运营商重耕4G LTE频谱资源。据统计,当前LTE Cat 1 bis 和 Cat 4 约占当前全球蜂窝物联网市场的一半。

    其次,与LTE Cat 4和Cat 1/1bis相比, RedCap天然具有5G能力优势,比如,不仅支持包括毫米波在内的更广泛的频段、网络效率更高、具备5G安全能力,而且可与5G网络切片、5G专网、5G定位等技术结合提供更好的物联服务,同时理论上运营商只需对现有5G网络进行软件升级即可部署。

    另外,RedCap填补了中档物联空白,使5G具备了一张网络适配所有低、中、高档物联应用的能力,这也利于蜂窝物联网统一高效管理。

    转载自:https://www.txrjy.com/thread-1297962-1-1.html

    Views: 8

  • 5G中的物联网技术

    • urllc

    低时延,大带宽,与embb共存部署,urll可以与tsn结合使用,为了降低时延还需要全双工支持(R19支持TDD的全双工)

    • nb-iot,eMTC

    4G时代定义的技术,被5G采纳
    nb-iot 使用180khz带宽,支持159/127kbs的上下行
    eMTC使用1.4MHz带宽时支持1Mbps的上下行,使用5MHz带宽时支持7/4Mbps的上下行
    R15中支持NR带内部署,R16中支持连接5G核心网

    • NR-Light

    速率高于eMTC,仅次于eMBB,与eMBB共存部署
    使用20MHz带宽时91/227Mbps的上下行,使用10MHz时支持100Mbps的上下行,使用5MHz时支持10Mbps的上下行。

    Views: 18

  • Wifi8的时间线

    wifi8(802.11bn)计划是2028年最终发布,预计2026或2027年会发布一个中间节点的标准,主要特性是集成毫米波,AP协同,基于MLO的漫游,降低延迟和抖动,节能,改进P2P(wifi直连)

    Views: 176

  • 3GPP R18特性

    3GPP R18

    • 下行非连接状态小数据包传输(R17支持上行)
    • 性能更低的RedCap,频段带宽降到5MHz
    • RedCap支持定位
    • 基站侧节能
    • 改善高速移动目标的MIMO性能
    • 提高定位精度和速度
    • 覆盖增强
    • 时间敏感通信(TSC)和URLLC增强
    • 确定性网络(物联网场景)
    • 卫星增强
    • 终端到终端的中继
    • 卫星物联网
    • 多SIM卡支持增强和更平滑的切换,可以支持两个SIM卡同时处理连接状态(R17只能一个连接一个空闲状态),在以外多SIM都是手机自己实现的,没有标准化,现在3GPP提供统一的标准来支持多SIM卡

    3GPP R19

    • 带内全双工
    • 低功耗设备(包括RedCap)支持独立唤醒接收器
    • 700/800/900载波聚合
    • 终端到终端中继增强,支持多路径,多跳中继,终端聚合
    • 卫星增强,卫星和地面共用频谱
    • 卫星上的RedCap
    • 超表面
    • 通感一体化
    • 节能
    • 覆盖增强
    • 跨3层的漫游,在没有信号时可以用Wifi连接提供服务避免通话中断
    • sidelink支持距离测量,相对定位,绝对定位(为研究项目,可能车联网用的多)
    • 卫星定位(非GPS定位)

    参考:
    https://www.txrjy.com/thread-1214262-1-1.html
    https://www.txrjy.com/thread-1278460-1-1.html
    https://www.atis.org/?smd_process_download=1&download_id=1732913
    https://www.5gamericas.org/wp-content/uploads/2022/12/Becoming-5G-Advanced-the-3GPP-2025-Roadmap-InDesign.pdf
    https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/setting-off-the-5g-advanced-evolution-with-3gpp-release-18.pdf

    Views: 103