非礼勿视

> 可否考虑将DSCOVR:EPIC添入图片源？这颗卫星应该是一直在拍地球向阳面，不过分辨率好像比向日葵要低 2048 x 2048,确实低些，不知道有没有原始图片

下载msyh.ttc复制到~/.deepinwine/Deepin-WeChat/drive_c/windows/Fonts/，然后修改注册表~/.deepinwine/Deepin-WeChat/system.reg，但是在接下来字体注册这一步出现报错，提示deepin-wine5更新不完整，然后换思路，把字体安装到了ubuntu以后重启电脑重新安装微信，输入框方块问题解决了 环境： Ubuntu 20.04.2 LTS 微信 3.2.1.154 Deepin-win5 5.0.16-1 i386 已安装文泉驿字体 > @yovelas 试试这篇文章：https://blog.csdn.net/hymanjack/article/details/100168300 > TIM可以正常显示，微信嘛，暂时未解决。

> rdp-tcp : 3389 **rdp-udp : 3391** 感谢分享。尝试了下这个修改，没有看到效果，客户端抓包看了一下，没有UDP报文产生，应该是前面TLS握手过程没有完成，还不会开始跑UDP流量。然后用互联网直连的方式抓包验证了一下，我目前使用的这个版本的RDP的UDP使用的端口号还是3389。

> ```toml > #transport.protocol = "quic" > ``` 试了一下，效果还是一样的

> 在 frpc 捕获 `7801` 端口 没太明白捕获`7801`端口是什么意思。如果是指客户端配置的话，现在客户端与服务器通信的已经是7801端口了。如果是指用wireshark抓包的话，我尝试修改服务器跟客户端的配置，去掉quic和auth口令鉴权，最简化配置，服务器只保留日志相关，以及在frpc的配置文件中使用`tls.enable = false`，然后在网口抓包7801。但最终抓到的依旧是tls报文，不过我对比了回环抓包的报文，发现在mstsc客户端输入完frpc设备的密码，点确认之后，frps是有向frpc发送tls报文的，但是此时在回环接口上抓包就没有抓到这个报文

> > > 在 frpc 捕获 `7801` 端口 > > > > > > 在frpc的配置文件中使用`tls.enable = false`，然后在网口抓包7801。但最终抓到的依旧是tls报文 > > https://github.com/fatedier/frp/blob/52f66b05e624233105924906f67f10347a5ed0de/conf/frpc_full_example.toml#L102 这个配置是有效果的。重新抓了包，情况是这样的：第一轮鉴权的传输是正常的，到了RDP客户端输完密码回车的时候出问题了，此时RDP客户端向frps的13389端口发送了tls的client hello报文，而frps把RDP客户端请求的tls报文，也就是tcp的载荷完全一模一样得转发给了frpc客户端，frpc这端收到的tcp报文出来tcp头不一样，剩下的tcp载荷和RDP请求的报文完全一样。不知道frp的frps和frpc之间的交互协议是否有序列化的处理，至少我在前面的报文里没有看到有这种一模一样的载荷出现。而且这个报文没有在loopback口的3389端口上抓到，应该是被frpc丢掉了。