• 2

OpenWrt 19.07.2 +18.06.8 |Wifi Router第三方韌體之王|WPA3|工業4.0/萬物聯網IoX|嵌入設備Embedded System |單版電腦Single Board Computers(SBC)|CanBus車網 - 6 March 2020

官網還沒更新-最新版本消息
Downloads下載網站卻已釋出
第一手情報通知 OpenWrt Fans
 
 
KeyCDN的效率實在超爛.........每次下載 or Sysupgrade到70幾%↑
Speed都會急速下墜, 有時候甚至檔案抓不完, 無法100%下載
以前OpenWrt沒用KeyCDN之前都沒這種錯誤發生!
 
 
主因→→→→→CA證書驗證錯誤
downloads.openwrt.org的CA證書是downloads.lede-project.org的,
wget 若不加入 「--no-check-certificate 」無法下載
目前官方BuildSystem預設Repo下載都以wget為主,
常造成Shell腳本初始Package.gz下載失敗
 
Connecting to downloads.openwrt.org|176.9.48.73|:443... connected.ERROR: cannot verify downloads.openwrt.org's certificate, issued by `/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3':
Unable to locally verify the issuer's authority.
ERROR: certificate common name `downloads.lede-project.org' doesn't match requested host name `downloads.openwrt.org'.
To connect to downloads.openwrt.org insecurely, use `--no-check-certificate'.
Unable to establish SSL connection.
 
2. 下載downloads.openwrt.org檔案最好的參數居然是
wget --no-check-certificate --secure-protocol=TLSv1
wget --no-check-certificate --secure-protocol=TLSv1_1
wget --no-check-certificate --secure-protocol=TLSv1_2
 →→→→→無效!
 
--secure-protocol=Auto跟 --no-check-certificate 一樣都會速度: 卡住+亂飄+下墜
 
curl卻能用tls1.1 、tls1.1、tls1.2
 

------------------!!!!!!賀!!!!!!-------------------------------------------------------------

當日OpenWrt下載站,把downloads.openwrt.org從DNS Cname別名紀錄中,
迅速的修改提升為主Hostname:
downloads.lede-project.org→→→→→downloads.openwrt.org
在Batch腳本(Windows)中wget --no-check-certificate 下載速度變得快速正常
另外一個下載程式,加入下列參數較優
curl --tlsv1.2 -O
在Batch腳本(Windows)中 ,culr 若用免驗證參數 -k ,速度還是會飄
 
 
KeyCDN調整的滿快的,希望能穩定下載就好
有時候測試機要跑腳本要跑好幾次,不可能只下載一次...............
 
KeyCDN  Nginx Proxy Cache Server 記得更新版本
Version 1.10實在太過老舊......24 May 2016 之前的版本
目前最新版本已經到v1.17.9
https://nginx.org/en/CHANGES
※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※
opkg 放在CLI指令列裡直接跑沒問題,但是
放在Shell Script 腳本錯誤訊息Error:
failed to download  target\packages 3百多K ,出現wget return 4
解法:在opke update 之前, 加上idle時間10~15秒
後面的idle時間是為了檢查target\packages 3百多K是否有完整下載!
sleep 15
opkg update
sleep 10
2020-03-03 17:50 發佈

歡迎來到OpenWrt專案

 
OpenWrt專案是針對嵌入式設備的Linux作業系統。 OpenWrt不會嘗試創建單個靜態韌體,而是提供具有套件包管理功能的完全可寫文件系統。 這使您從供應商提供的應用程序選擇和設置中解放出來,並允許您通過使用套件包來定制設備以適合任何應用程序。 對於開發人員來說,OpenWrt是構建應用程序的框架,而無需圍繞它構建完整的固件。 對於用戶來說,這意味著可以完全自定義的能力,可以以從未想到的方式使用設備。
請參閱硬件表以了解受支持的設備。 有關OpenWrt項目組織的更多信息,請參見About OpenWrt頁面。
當前主流穩定版本 - OpenWrt 19.07.2
舊的穩定版系列 - OpenWrt 18.06
 
※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※

OpenWrt 19.07.2 - 正式服務版 - 6 March 2020

※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※

OpenWrt社群很自豪地宣布OpenWrt 19.07的第二個服務版本。 它側重於安全性和設備支援。 它尤其解決了ppp中的安全問題,並改善了將設備從ar71xx遷移到ath79的支援。
 
※※※※※※※※※
關於OpenWrt
※※※※※※※※※
OpenWrt項目是針對嵌入式設備的Linux作業系統。 它完全替代了供應商提供的各種無線路由器和非網絡設備的韌體。 請參閱硬件表以了解受支援的設備。 有關OpenWrt項目組織的更多信息,請參見About OpenWrt頁面。
https://openwrt.org/toh/start
https://openwrt.org/about
在以下位置獲取OpenWrt韌體:https://downloads.openwrt.org/releases/
 
※※※※※※※※※※※※※※※※※※
對OpenWrt 19.07.1的主要更改
※※※※※※※※※※※※※※※※※※
下面僅列出主要更改。 有關完整的更改日誌,請參見changelog-19.07.2。
 

安全修復

  • 安全公告2020-02-21-1-ppp緩衝區溢出漏洞(CVE-2020-8597)
  • 其他安全修復

錯誤修復和改進

  • 服務:修復19.07.1中導致umdns停止工作的libubox回歸(FS#2833)設備支援
  • 修復AR71XX-一些設備的ATH79系統升級:fritz300e
  • 添加ar71xx-ath79遷移以對所有ar93xx / qca95xx設備進行無線設定
  • 在ath79中添加對更多設備的支援:Ubiquiti Nanostation Loco M(XMXW),Picostation M(XM)
  • 添加對Luxul ABR-4500和XBR-4500的支援
  • 修復ipq806x上的CPU性能問題
  • 重新啟用D-Link DIR-645的映像
  • 多種設備的各種修復和改進:
  • ├─TP-Link TL-MR3020 v3
  • ├─TL-WA801ND v5
  • ├─TL-WR841N / ND v8
  • ├─TL-WR842N v2
  • ├─WDR3600 / WDR4300
  • ├─Mikrotik RB912UAG-5HPnD r2
  • └─Netis WF-2881

 LuCI Web界面

  • uhttpd:提高了在高負載下的HTTPS請求的可靠性(存在導致超時的死鎖)。可能仍然存在殘留問題。
  • 修復了對可選nginx整合的支援
  • 從Weblate更新翻譯

 核心組成

  • 將Linux內核從4.14.167→→→4.14.171
  • 將Mac的Mac80211更新為brcm到最新的5.6 backports
※※※※※※※※※※※※
已知的問題
※※※※※※※※※※※※
  • 過渡到ath79:ath79尚不支援ar71xx支援的多種設備:這是一項社群工作。 非常歡迎幫助將設備移植到ath79以使其在將來的版本中可用。
  • 設備支援:某些設備的映像太大,無法支援持久覆蓋,從而導致此類設備在重啟後丟失設置。 如果您遇到此問題,請在論壇中報告受影響的設備,並考慮降級到OpenWrt 18.06或使用映像產生器打包較小的自定義圖像
  • 設備支援:某些ath79設備(例如TL-WR841N)上帶有atheros開關的不穩定以太網鏈接:FS#2216,FS#2730
  • LuCI Web界面:一些可選的GUI軟件包崩潰,並顯示有關缺少“ cbi.lua”的錯誤,請安裝luci-compat軟件包以修復這些問題
另請參閱:openwrt-19.07的活動錯誤報告
 
※※※※※※※※※※※※※※※※※※
升級到OpenWrt 19.07.2
※※※※※※※※※※※※※※※※※※
借助sysupgrade實用程序,可以輕鬆地從以前的OpenWrt 19.07版本進行升級:
├─從Web界面從sysupgrade

└─從命令行從sysupgrade。
在許多情況下,包括保留設置,都支援從OpenWrt 18.06升級到OpenWrt 19.07。
但是,建議從OpenWrt 18.06升級時進行設置備份。
 
※※※※※※※※※※※※※※※※※※
OpenWrt 19.07中的亮點
※※※※※※※※※※※※※※※※※※
在此發行版中,OpenWrt項目將所有受支援的標的帶回一個通用內核版本,並進一步完善和擴展了現有設備支援。 它還引入了一個新的ath79標的並帶來了對WPA3的支援。
 

標的從ar71xx過渡到ath79

此版本為新的ath79標的提供了初步支援,該標的是流行的ar71xx標的的未來基於設備樹的繼任者。 對於19.07,仍會構建兩個標的,但是建議盡可能切換到ath79標的:OpenWrt的未來版本將放棄對ar71xx標的的支援。 有關過渡的原理,請參閱ath79技術參考。
要執行升級,請按照從ar71xx升級到ath79的說明進行操作。 給定設備的功能在兩個標的之間應該相同:如果不是,請報告該問題,並在需要時恢復為ar71xx。
 

WPA3支援

19.07版本帶來了對WPA3的初始支援。 但是,默認情況下未啟用WPA3,並且需要安裝特定的套件包:要運行WPA3作為訪問點,需要hostapd-openssl。 要用作Wi-Fi站點,您需要wpa-supplicant-openssl(僅支援站點)或wpad-openssl(AP +站點)。 由於它們的尺寸較大,默認情況下不會安裝這些套件包,因此無法將其安裝在Flash少於8MB的設備上
還應注意,許多現有客戶端設備將永遠不支援WPA3,並且有些客戶端設備支援WPA2,但無法連接到設置有WPA2 + WPA3混合模式的AP。 如果您確定問題與客戶端無關,請僅提交錯誤。
要將設備設置為WPA3接入點,請參閱wpa_modes
https://openwrt.org/docs/guide-user/network/wifi/basic#wpa_modes
 

LuCI Web界面的客戶端渲染

LuCI的新版本是OpenWrt的整合Web界面,它實現了視圖的客戶端呈現。 通過將設備(Lua編碼)上完成的某些工作卸載到客戶端瀏覽器(Javascript編碼),從而提高了性能。
LuCI生態系統很大,並且並非所有LuCI應用程序都已適應此更改,這可能導致涉及cbi.lua的崩潰。 在這種情況下,請安裝luci-compat套件包。
如果LuCI加載緩慢,請考慮安裝uhttpd-mod-ubus,關閉並重新打開瀏覽器選項卡以啟動新的LuCI會話。
通過這一步驟,減少了LuCI在LuCI中的使用,並且LuCI有效地接近了實驗性LuCI2的標的,而不必從頭開始重寫所有內容。

OpenWrt v19.07.2 變更紀錄

 
Release此變更日誌列出了自v19.07.1標記以來在OpenWrt中完成的所有提交,並按子系統分組。 更改從上到下按時間順序排列,並涵蓋了Git Repo存儲庫的歷史,直到標記19.07.2版本為止。
 
另請參見發行說明,這些發行說明提供了對19.07.2。中主要更改的更易於訪問的概述。
 

Build System / 主機實用工具 x1 項改變

  • cf2b042 firmware-utils: add lxlfw →ol for generating Luxul firmwares (+283)

Kernel x4 項改變

  • eca8a2e kernel: 躍昇 4.14 → 4.14.169 (+88,-330)
  • 2a84434 kernel: 新增支援 GD25D05 SPI NOR (+29)
  • d91b52b kernel: 新增遺失 symbol (+1)
  • af79c3b kernel: 躍昇 4.14 → 4.14.171 (+61,-66)

套件包 / 開機引導掛載程序 x1 項改變

  • a0ca72d uboot-env→ols: ath79: 新增 Netgear WNDR3700v2 (+2,-1)
 

套件包 / 共通 x4 項改變

  • b6c01fe hostapd: 移除錯誤的 $(space) 重新定義 (-3)
  • 6b7eeb7 ppp: backport 安全修正 (+129,-1)
  • 0e9e5b1 Revert "ppp: backport 安全修正" (+1,-129)
  • cf11807 ppp: backport 安全修正 (+129,-1)
 

套件包 / OpenWrt 系統用戶區 x2 項改變

  • 9e2a1af uhttpd: 更新 → 最終 Git HEAD (+3,-3)
  • ⇒ 2ee323c file: 啟動延遲程序後戳入ustream (+1)
  • 65030d8 libubox: 更新 → 最終 Git HEAD (+3,-3)
  • ⇒ 75e300a blobmsg: 修復從blobmsg_check_array傳遞的有效載荷len錯誤 (+1,-1)
  • ⇒ 7da6643 tests: blobmsg: 新增測試案例 (+177)
 

標的 / apm821xx x1 項改變

  • eca8a2e kernel: 躍昇 4.14 → 4.14.169 (+88,-330)

標的 / ar71xx x1 項改變

  • af79c3b kernel: 躍昇 4.14 → 4.14.171 (+61,-66)

標的 / ath25 x1 項改變

  • af79c3b kernel: 躍昇 4.14 → 4.14.171 (+61,-66)

標的 / ath79 x15 項改變

  • 53cd229 ath79: WNDR3700 v1/v2: 使u-boot env分區可寫入 (-2)
  • 5000fc5 ath79: 修復Ubiquiti XW分區的DTS節點名稱 (+2,-2)
  • 2d21357 ath79: ar93xx/qca95xx: 將gmac / wmac / pcie節點移出apb bus (+123,-123)
  • 95d5cbd ath79: 為所有ar93xx / qca95xx SoCs 新增wmac遷移 (+6,-5)
  • 085f383 ath79: 在fritz300e上從ar71xx啟用無力sysupgrade (+1)
  • 7cbd394 ath79: 新增 gpio4 pinmux 在 TL-WR841N/ND v8, WR842N v2, MR3420 v2 (+16,-8)
  • 6a950af ath79: 新增支援 Ubiquiti Nanostation Loco M (XM) (+24)
  • 8fa6107 ath79: 新增支援 Ubiquiti Picostation M (XM) (+24)
  • 21bf718 ath79: 新增支援 Ubiquiti NanoStation Loco M (XW) (+39)
  • b2660e6 Revert "ath79: 新增支援 Ubiquiti NanoStation Loco M (XW)" (-39)
  • c9b6bb4 ath79: phy-ar7200-usb: 適應舊行為 arch/mips/ath79/dev-usb.c (+18,-6)
  • d0c8875 ath79: ar934x: 使用重置為 usb-phy-analog (+2,-2)
  • af79c3b kernel: 躍昇 4.14 → 4.14.171 (+61,-66)
  • 4edadfb ath79: 對Ubiquiti NanoStation Loco M (XW) 新增支援(+39)
  • b33cfb7 ath79: 對NanoStation Loco M (XW) 新增缺少的reset-gpios (+1)
 

標的 / bcm53xx x2 項改變

  • cff3795 bcm53xx: 為 Luxul ABR-4500 and XBR-4500 路由器建立映像檔 (+36)
  • af79c3b kernel: 躍昇 4.14 → 4.14.171 (+61,-66)
 

標的 / brcm2708 x2 項改變

  • eca8a2e kernel: 躍昇 4.14 → 4.14.169 (+88,-330)
  • af79c3b kernel: 躍昇 4.14 → 4.14.171 (+61,-66)

標的 / brcm47xx x1 項改變

  • af79c3b kernel: 躍昇 4.14 → 4.14.171 (+61,-66)
 

標的 / brcm63xx x1 項改變

  • eca8a2e kernel: 躍昇 4.14 → 4.14.169 (+88,-330)
 

標的 / ipq40xx x1 項改變

  • af79c3b kernel: 躍昇 4.14 → 4.14.171 (+61,-66)
 

標的 / ipq806x x3 項改變

  • 191822b ipq806x: 新增缺少的core1電壓→容差 (+1)
  • bc0ca20 ipq806x: fix bug in L2 cache scaling (+2,-1)
  • af79c3b kernel: 躍昇 4.14 → 4.14.171 (+61,-66)
 

標的 / layerscape x2 項改變

  • eca8a2e kernel: 躍昇 4.14 → 4.14.169 (+88,-330)
  • af79c3b kernel: 躍昇 4.14 → 4.14.171 (+61,-66)

標的 / mediatek x1 項改變

  • eca8a2e kernel: 躍昇 4.14 → 4.14.169 (+88,-330)

標的 / mpc85xx x1 項改變

  • af79c3b kernel: 躍昇 4.14 → 4.14.171 (+61,-66)

標的 / pistachio x1 項改變

  • af79c3b kernel: 躍昇 4.14 → 4.14.171 (+61,-66)

標的 / ramips x5 項改變

  • a229907 ramips: 對TP-Link Archer C20i 刪除重複的DEVICE_PACKAGES (-1)
  • aed6632 ramips: 對TP-Link TL-MR3020 v3 and TL-WA801ND v5 使用tpt DTS觸發器(+4,-6)
  • 3d1c84d ramips: 對這 D-Link DIR-645 重啟映像檔創建(-1)
  • 2d3a933 ramips: 附加尾隨 → WF2881 initramfs 映像檔 (+8)
  • af79c3b kernel: 躍昇 4.14 → 4.14.171 (+61,-66)

標的 / sunxi x1 項改變

  • eca8a2e kernel: 躍昇 4.14 → 4.14.169 (+88,-330)

Wireless / Common x1 項改變

  • 887eb66 mac80211: brcm: 反向移植剩餘的5.6內核修正檔 (+651,-3)
 
 

已解決的錯誤

#2753

Description: 針對TP-Link TL-WR842ND v2.0 在更新到 → 19.07後導致USB缺乏電源(ath79)
Link: https://bugs.openwrt.org/index.php?do=details&task_id=2753
Commits:
  • 7cbd394 ath79: add gpio4 pinmux on TL-WR841N/ND v8, WR842N v2, MR3420 v2 (+16,-8)
 

#2833

Description: libubox: 在blobmsg_check_array() 中的臭蟲
Link: https://bugs.openwrt.org/index.php?do=details&task_id=2833
Commits:
  • 65030d8 libubox: update → latest Git HEAD (+3,-3)
  • ⇒ 75e300a blobmsg: (+1,-1)
  • ⇒ 7da6643 tests: blobmsg: 新增測試案例 (+177)
 

安全修正

CVE-2020-8597

Link: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8597
Commits:
cf11807 ppp: 反向移植安全修復 (+129,-1)
 

CVE-2019-14897

描述:在Marvell WiFi晶片驅動程式的Linux內核kernel-2.6.32版本中發現了基於堆疊的緩衝區溢出。 當STA在IBSS模式下工作時(允許連接站→不使用AP一起連接)並連接→另一個STA,遠端攻擊者能夠→導致服務拒絕(系統崩潰),或者可能執行任意代碼。
Link: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14897
Commits:
eca8a2e kernel: 躍昇 4.14 → 4.14.169 (+88,-330)
 

CVE-2019-14896

描述:在Marvell WiFi晶片驅動程式的Linux內核kernel-2.6.32版本中發現了基於堆疊的緩衝區溢出。 當STA在IBSS模式下工作時(允許連接站→不使用AP一起連接)並連接→另一個STA,遠端攻擊者能夠→導致服務拒絕(系統崩潰),或者可能執行任意代碼。
Link: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14896
Commits:
eca8a2e kernel: 躍昇 4.14 → 4.14.169 (+88,-330)

 

CVE-2013-1798

Description: The ioapic_read_indirect function in virt/kvm/ioapic.c in the Linux kernel through 3.8.4 does not properly handle a certain combination of invalid IOAPIC_REG_SELECT and IOAPIC_REG_WINDOW operations, which allows guest OS users → obtain sensitive information from host OS memory or cause a denial of service (host OS OOPS) via a crafted application.
Link: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1798
Commits:
af79c3b kernel: 躍昇 4.14 → 4.14.171 (+61,-66)

OpenWrt 18.06.8 - 正式服務版本發佈 - 6 March 2020


OpenWrt 18.06.8中的亮點

OpenWrt社區自豪地宣布穩定的OpenWrt 18.06系列的第八個服務版本。 OpenWrt 18.06.8帶來了安全修復程序以及常規的設備支持修復程序和核心組件更新。
 

此服務版本的主要亮點是:

  • 安全公告2020-02-21-1-ppp緩衝區溢出漏洞(CVE-2020-8597)
  • Linux內核從4.9.211更新到4.9.214以及從4.14.167更新到4.14.171
  • 服務:修復了18.06.7中的libubox回歸,該回歸導致umdns停止工作(FS#2833)
  • RB912UAG-5HPnD r2的設備支持修復程序

有關更多詳細信息,請參閱詳細的變更日誌。

 
請注意,套件包提要的更新可立即用於所有次要版本的OpenWrt:無需升級到新的OpenWrt映像即可安裝套件包的較新版本。這適用於核心OpenWrt套件包以及社區維護的套件包。
與往常一樣,非常感謝我們所有有效的套件包維護人員,測試人員,文檔編制者和支持者。
玩得開心!
 
OpenWrt社區
omniplay wrote:
歡迎來到OpenWrt(恕刪)


最近使用新版的19.07.2時,登入luci網頁反應速度非常慢,我的機器是NETGEAR R7800,原使用19.07.1時是正常的,後來sysupgrade後就很慢,但是SSH登入正常,CPU使用率也不高。
重新刷過也一樣,目前先刷回原廠。
中間有看到一段
-------------------------------------------------------------
並且並非所有LuCI應用程序都已適應此更改,這可能導致涉及cbi.lua的崩潰。 在這種情況下,請安裝luci-compat套件包。
如果LuCI加載緩慢,請考慮安裝uhttpd-mod-ubus,關閉並重新打開瀏覽器選項卡以啟動新的LuCI會話。
通過這一步驟,減少了LuCI在LuCI中的使用,並且LuCI有效地接近了實驗性LuCI2的標的,而不必從頭開始重寫所有內容。
-------------------------------------------------------------
不知是不是得安裝luci-compat、uhttpd-mod-ubus...

ps:我是刷 https://forum.openwrt.org/t/build-for-netgear-r7800/316 這邊版本的
domon wrote:最近使用新版的19.07...
我是刷 https://forum.openwrt.org/t/build-for-netgear-r7800/316 這邊版本的
(恕刪)   
 
1、你犯了一個嚴重的錯誤===>
誤把OpenWrt Fourm 個人推出的映象檔image 當成Offical 官方出品!
正宗唯一官方出品的image只有 https://downloads.openwrt.org/ 裡的才是
OpenWrt放在Github上面的, 那只是Mirror備用網站
真正Git Master Repositories主站是: https://git.openwrt.org/
其它都是山寨品
→包括GitHub一堆個人fork OpenWrt的image,
→包括恩山、koolshare...........
 
個人推出的Image, 你是否該去問作者怎回事?
關OpenWrt Release正式版屁事?
 
 
2、誤把snapshot版本當成Release
你肯定不會編譯,連版本號都不會變識
正宗OpenWrt 19.07.2,真正的版本號是 r10947-65030d81f3
前面的圖你沒看清楚, 我就再貼一次

 
而你用的版本號是: r10953-e7f1313bbb
編號在官方Release正式版之後, 這是snapshot版本!!!!!
 
 
3、你降版降錯了,若是19.07.2 覺得不夠穩, 並非降到19.07.1
因為這樣沒解決掉改版前的Bug,
而是降到18.06.8
這是用官方版本出錯時的解決較好的方式
 
 
4、OpenWrt 19.07不夠穩?
Ans: 確實, 我還在虛擬機VBox裡面除錯Debug
那個target裡面的超大packages下載出錯
(failed to download target\packages  --- wget return 4)
害我裝機後的腳本全部失效
我花了快一個禮拜才找到解法.....
 
通常任何版本要上Soc Router實體機前,
我會先跑shell scripts的SOP在VirtualBox
全部跑完沒出錯才會上Soc Router實體機
 
所以,其實 OpenWrt 19.07.2比較適合Developer開發者玩
一般不會Debug+Diagnostic除錯的User比較適合玩18.06.8版本
OpenWrt 19.07.2會有一些小災小難, 這還只是開始而已
因為19.07是為了要更新Kernel到linux kernel 4.19而設的
Kernel核心更新後, Package開發者能不能跟上, 還在未定之數!
去看看 https://git.openwrt.org/
裡面有多少分支,你就知道這是一個超大生態全球刷的韌體了
在觀察 Last Change 二十四小時, 時間越短的越穩........
官方只負責這一支而已 openwrt/openwrt.git
 
 
上次玩19.07 RC Snapshot 我就體驗到了XDD
-----> 一堆Luci 沒跟著更新
只好降回18.06.7
差不多一個禮拜吧, 再回去看Snapshot Kmod有更新幾個版本
我才又回刷 Snapshot 版本
所以就學會了 要看Kmod的時間戳記.................
最穩的那個版本通常就是→版本號都一樣超多版本那版(密技XDD)
 
5、至於luci-compat、uhttpd-mod-ubus
官方既然說了, 加上對空間若影響不大,當然是加上去
 
至於你說的延遲, 不知道你的標準在哪?
官方版本,通常我數三秒, 就開完了
那也可能表示你的來源有問題, 系統沒優化!
不信?
試試下列指令:
cat /proc/sys/kernel/random/entropy_avail
 
我在Zyxel Armor Z2 跟Netgear R7800 的硬體同級的數值是 3192
OpenWrt官方出廠值在VirtualBox是1010
omniplay wrote:
 1、你犯了一個嚴重(恕刪)


大大真是太強了,我只是初學而已...
我會刷那個個人推出的版本是因為它已經整合了一些功能,且他寫沒什麼問題。
試著安裝luci-compat、uhttpd-mod-ubus,某次開機後Luci竟然就正常了,卻發現kmod無法更新(與kernel版本不同),還會有read only問題出現,後來也試著下載官方19.07.2來刷,Luci介面也是一樣慢,至少5秒以上,甚至會跑出XHR錯誤訊息。
沒太多時間測試,目前先用voxel類官方版,之後再試試18.06。

感謝大大資訊~
domon wrote:
我會刷那個個人推出的版本是因為它已經整合了一些功能,且他寫沒什麼問題。
試著安裝luci-compat、uhttpd-mod-ubus,某次開機後Luci竟然就正常了,卻發現kmod無法更新(與kernel版本不同),還會有read only問題出現,後來也試著下載官方19.07.2來刷,Luci介面也是一樣慢,至少5秒以上,甚至會跑出XHR錯誤訊息。
沒太多時間測試,目前先用voxel類官方版,之後再試試18.06。(恕刪)

剛為某機子 Porting 出來的 code, 不用太急著刷..

因為總是會有某些 bug ,

如果只是想試用看看, 那你就把試用時, 遇到的一些問題 回報給 原Porting者, 讓他趕快去改.
domon wrote:大大真是太強了,我只(恕刪)        
 
 
真正的競爭,不是和別人比,而是跟昨日的我相比
刷一千次絕對跟刷個1、2次效益不同
當然不會是在主力機Soc Wifi Router上面刷----- 瘋子才會幹的事
而是丟VM虛擬機上面刷
 
會推votex的人肯定不懂Linux Kernel核心版本差異, 更不熟CVE漏洞情報
votex用的是Linux kernel 3.4.103,
跟各家OEM官方Firmware韌體採用版本->大同小異
都是Linux Kernel Phase Out 淘汰不更新的Linux Kernel
https://www.kernel.org/
Longterm 長期維護的3.x只剩3.16.82
3.16.82↓↓↓↓↓以下的版本早就死光了XDD
CVE--->Linux kernel 3.4.103
查看目前採用的FW韌體版本
# uname -r
 
OpenWrt 採用的Linux系統主力Linux Kernel 4.14,
服務完全獨立於系統,就算服務崩潰也不影響系統
通常Web服務被打死時, SSH 還是頭好狀壯,
所以SSH比Web網頁服務重要
 
服務不良通常「服務重啟」就搞定了, 不需要重刷FW
e.g 查看目前跑那些服務
# service
 
Web服務(uhttpd)重啓
# service uhttpd restart
 
 
OpenWrt版本號
snapshot主力為攻上Linux Kernel 4.19做準備, 也就是為了802.11AX硬體Ready
19.07.2 為了準備port移植 snapshot的 linux kernel 4.19 Ready,
未來移植過程可能會出現些許小災小難------>整合問題還在未定之數
 
↑↑↑↑↑所以上面兩個版本↑↑↑↑↑比較不適合新手/主力機
除非你有Mantain維護+Debug除錯校正的能力
 
新手/主力機推薦→→→→→18.06.8
omniplay wrote:
官網還沒更新-最新版(恕刪)



不好意思想請問一下,我現在用的是Dell 1012 netbook,安裝OpenWrt 19.07.2 r10947-65030d81f3

我在安裝wifi 驅動時一直找不到package,請問是不是有另外的source 位址?

指令:opkg install kmod-brcm-wl nas wlc wl

錯誤訊息:Unknown package 'kmod-brcm-wl'Collected errors opkg_install_cmd Cannot install


另外想請教openwrt 的藍芽/wabcam 的驅動有沒有哪邊有比較多的資料,或者X86_64 的整合包?

已經找了一周未果,感謝!
別人錯了,不等於你就對了。
  • 2
內文搜尋
X
評分
評分
複製連結
Mobile01提醒您
您目前瀏覽的是行動版網頁
是否切換到電腦版網頁呢?