How to use simple speedtest in RaspberryPi CLI

 

pi@ChunchaiRPI2:/tmp $  wget -O speedtest-cli https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py

--2023-06-26 10:43:47--  https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py

Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.111.133, 185.199.109.133, 185.199.110.133, ...

Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.111.133|:443... connected.

HTTP request sent, awaiting response... 200 OK

Length: 65334 (64K) [text/plain]

Saving to: ‘speedtest-cli’

speedtest-cli                                        100%[=====================================================================================================================>]  63.80K  --.-KB/s    in 0.08s

2023-06-26 10:43:48 (849 KB/s) - ‘speedtest-cli’ saved [65334/65334]

pi@ChunchaiRPI2:/tmp $ sudo chmod +x speedtest-cli

pi@ChunchaiRPI2:/tmp $ ./speedtest-cli --simple

Ping: 7.342 ms

Download: 301.20 Mbit/s

Upload: 251.35 Mbit/s

pi@ChunchaiRPI2:/tmp $

How to decompile dtb file (Device Tree)

dtc -I dtb -O dts -o devicetree.dts devicetree.dtb

$ sudo apt-get install device-tree-compiler

$ dtc -I dtb -O dts test.dtb > test.dts

$ dtc -I dts -O dtb test.dts > test.dtb

 

reference: https://forum.digilentinc.com/topic/2427-how-to-decompile-dtb-file/

Device Tree, reference:

Device Tree（一）：背景介绍  http://www.wowotech.net/device_model/why-dt.html

Device Tree（二）：基本概念  http://www.wowotech.net/device_model/dt_basic_concept.html

Device Tree（三）：代码分析  http://www.wowotech.net/device_model/dt-code-analysis.html

Device Tree（四）：文件结构解析 http://www.wowotech.net/device_model/dt-code-file-struct-parse.html

HGU – Supported Service Scenarios

From https://halny.com/knowledge-base/hgu-supported-service-scenarios/

HGU mode allows to flow multiple traffic classes across VEIP.
All UNI interfaces are belonged to one VEIP and it cannot be controlled by OMCI.
This non-OMCI part can be controlled by Web and Auto provisioning.
Most OLT vendors support dual stack:
– IP-HOST #1 -> MGMT (WEB, XML provisioning) – configure by OMCI (from OLT)
– VEIP (non-OMCI : INTERNET, VoIP, IPTV services) – configure by ONT WEB or provisioning

1.Bridge mode – only INTERNET:1-4/WIFI + MGMT

2.Bridge mode – INTERNET:1-4/WIFI, VoIP Interface + MGMT

3.Bridge mode – INTERNET:1-2/WIFI, IPTV:3-4, VoIP Interface + MGMT

4.Router mode – only INTERNET:1-4/WIFI + MGMT

5.Router mode – INTERNET:1-4/WIFI, VoIP Interface + MGMT

6.Router mode – INTERNET:1-2/WIFI, IPTV:3-4, VoIP + MGMT

SFU – Supported Service Scenarios

From: https://halny.com/knowledge-base/sfu-supported-service-scenarios/

1.Access mode – only Internet

2.Access mode – only IPTV

3.Transparent mode – Internet, IPTV, VoIP

4.VLAN translation – rBSA

5.802.1q in 802.1q Begin/End of Tunnel

6.Transparent 802.1q in 802.1q

7.OSE/MdO

OMCI協議二層功能的模型選擇

From:https://blog.csdn.net/JIANGXIN04211/article/details/48294645

我們知道有兩種大的二層功能，即MAC橋以及802.1p映射。MAC橋是IEEE 802.1D描述的，有許多的特性，可以基於MAC地址透明轉發（True bridging）或VLAN characteristics（利用VLAN filter）。而映射功能描述了一個用戶側實體到1到8個網絡側流標記的關係。那種映射與只利用VLAN標記中pbit字段作為VLAN filters的MAC橋是相等的。

那兩種基本二層服務能組合實現各種連接要求。有三種大的基本模式：

N:1 bridging多個用戶端口在同一個橋中，而只有一個網絡服務

1:M mapping基於pbit來將一個用戶端口映射成多個網絡側服務

1:P filtering  基於非pbit的VLAN信息來將單一的用戶端口映射成多個網絡側服務

除了以上三個基本可能外，也有四種複雜的組合。即：

N:M bridging mapping顧名思義，N個用戶端口在一個橋中先橋轉發然後再進行基於pbit的映射。

1:MP map-filtering 一個用戶端口做filtering以及mapping

N:P bridging-filtering N個用戶端口在一個橋中先橋轉發然後再進行基於非pbit的VLAN信息的映射

N:MP bridging-map-filtering顯而易見。

系統性地，tag filtering發生在接近MAC橋而不是tagging操作的部位。如下順序：

ANI—Tag operation—Tag filtering—Bridging—Tag filtering—Tag operation—UNI

許多公司實現了非802.1p模型而採用最簡單的bridging模型，而最簡單一種是每個用戶端在一個Bridge中。1:P模型被採用。如果是多端口的CPE設備（一般由Interworking模塊，如Broadlight chip與交換Switch模塊，如Broadcom switch組成），那塊switch chip每個用戶口有個port VLAN（每個端口不一樣），為了區隔彼此。對於Untag流需要映射pbit的話可以採用管理對象(ID:171 Extended VLAN Tagging operation configuration data)屬性來達到要求。

 

參考：G.984.4 Section 8.2.2