key chain a
key 1
key-string 7 045802150C2E
show key chain
key chain a
key 1
key-string 7 045802150C2E
show key chain
找个有网口的电脑直接用网线连接光猫。
登录路由器管理界面,默认是 http://192.168.1.1 用户名密码在光猫背后。登录后记录下 VLAN ID,宽带账号密码。
访问 http://192.168.1.1/hidden_version_switch.gch 选 Default version,密码 CUAdmin,确定,此时光猫会重启。
访问 http://192.168.1.1/cu.html 用户名密码都是 CUAdmin – 基本配置,IP 协议版本选「IPv4/IPv6」,模式选「Bridge」,端口绑定四个 Lan 都选上,VLAN 模式选「改写(tag)」,VLAN ID 填写前面记录的 ID(北京是 3961),点创建。
Router连上光猫,设置 PPPoE 拨号上网即可,能成功获得 IPv6 地址了。
答案是肯定的,但是如果下行加密了,就没有意义了。
研究文档:
https://pierrekim.github.io/blog/2016-11-01-gpon-ftth-networks-insecurity.html
一下午的搜寻有了结果:https://zhuanlan.zhihu.com/p/89578609
股沟搜索命中上面文章的关键语句:为什么无线频宽决定速度
802.11g能够提供54Mbps最大速率,802.11n和802.11ac单流分别能够提供150Mbps和433Mbps的最大速率,这些数字是怎么算的呢?
一、802.11g的最大速率54Mbps的由来
802.11g工作在2.4G频段下,能够支持OFDM和CCK两种调制方式,提供16-QAM、64-QAM、BPSK和QPSK四种编码方式,我们通常说的54Mbps速率就是在2.4G频段下,通过OFDM调制,采用64-QAM编码的情况下实现的。
其中影响速率的计算因子如下:
1. 采用的OFDM能够提供52个子载波信道,但其中仅有48个用于数据传输;
—–相当于有52条车道,仅有48条可用
2. 64-QAM编码方式能够在每个子载波信道通过一次传输过程携带6bit的数据位;
—–每条车道每辆车上有6个座位
3. 64-QAM编码每次传输提供3/4的码率,即有效数据容量;
—–所有车辆的平均满座率是3/4
4. 一次传输占用的时间固定为4微秒;
—–平均每条车道每4微秒有一辆车发出
根据以上计算因子,802.11g能提供的最大速率(单位时间最多能拉乘客数量)为:(1秒/4微秒) × (6bit × 48 × 3/4) = 54M
二、802.11n单流最大速率150Mbps的由来
1. 802.11n在11g的基础上对OFDM调制方式进行了优化,将子载波信道的数量从52个提升至56个,但只有52个用于数据传输;
—–相当于车道由52条增加至56条,其中仅有52条可用
2. 802.11n对64-QAM编码技术进行优化,将每次传输提供的码率从3/4提升至5/6;
—–所有车辆的平均满座率由3/4提升至5/6
3. 802.11n可以工作的频宽从11g的20MHz变为40MHz,这样OFDM所能提供的子载波信道数量从56个进一步提升为112个,其中用来传输数据的子信道数量为108个;
—–道路宽度增加1倍,车道数相应增加1倍,被占用的4车道释放,共108条车道可用因此,802.11g单流能提供的最大速率(单位时间最多能拉乘客数量)为:(1秒/4微秒) × (6bit × 108 × 5/6) = 135M
另外,802.11n在条件允许的情况下(当实际环境中的多径效应较小时)可将OFDM两次传输之间的保护间隔时间从11g的800ns缩短为400ns(相当于平均每条车道每3.6微秒有一辆车发出),这样可以进一步将最大速率提升至150Mbit/s。
[1秒/(4微秒 – 400纳秒) ] × (6bit × 108 × 5/6) = 150M
路由: 直接转发原IP包
代理: 客户端IP包的源地址替代为代理服务器的IP地址和目标地址通讯
最近从SS-A的build错误得到了很多新的概念
Rust — Microsoft C++ build tools for Visual Studio — vspkg&nuget — Perl — openssl
build environment – CI/CD — Android Studio NDK — Clang — llvm — cmake — gcc — mysys2 — mingw — Cygwin — git — docker
CircleCI — Travis-ci — Snap — Bintray — Jcenter — crates.io
libev — socket
算法方面:
In algorithmic situations, recursion and iteration can be employed to the same effect. The primary difference is that recursion can be employed as a solution without prior knowledge as to how many times the action will have to repeat, while a successful iteration requires that foreknowledge.
开发方法方面:
The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier parts or versions of the system. Learning comes from both the development and use of the system, where possible key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added.
解释就是:快速做出一个样子,然后一边用一边完善功能,不停的推出新版本。
迭: 换
迭代:换代
2015年5月,紫光与惠普合作——紫光集团收购中国惠普公司旗下”新华三”51%的股份。7月,中国惠普又专门成立了全资子公司——紫光华山。
亦即,新华三=紫光华山+杭州华三通信。
旋即,瞩目良久的惠普公司分拆事件落地——11月,惠普(HPI)和惠普企业(HPE)各立门户。中国惠普与全球一致,顺利完成了分拆。原来的中国惠普企业级集团,也就是成为我们现在经常提及的中国HPE,专注企业级业务。
分拆对重组工作并没有影响,只是在表述上有了一些变化——新华三的业务范畴,涵盖紫光华山负责的HPE服务器、存储业务,以及杭州华三负责的H3C网络设备业务。
Copy From:http://www.cnbp.net/magazine/article/11192
参考:新华三的前世今生
自己的一点总结和疑问:
HPE多品牌运营,借助紫光和华三两个具有本地品牌标识的优势,使得HPE的服务器,存储和网络产品多了几个渠道和方式进行销售,或者贴牌,或者独家代理。
H3C网络产品实际上是3Com的产品加上本地公司研发的新产品。
原H3C品牌实际所有人是HP,通过公司股份出让,品牌的实际控制人也换成了紫光一方。
H3C贴牌的服务器和存储等设备的产品供应链和收益模式?HPE品牌产品是否支付代理费和品牌使用费? HPE产品的售后似乎还是由HPE自己来提供,后期是否会转交H3C?