P的胡言亂語

為什麼硬撥正常、軟撥沒達標？處理器與軟體架構差異
硬撥（數據機/路由器）： 由專用硬體晶片（ASIC/NP）直接進行 PPPoE 封包拆裝，效率極高且不佔用 CPU 資源。
軟撥（Windows 系統）： 由 Windows 系統的 PPPoE 軟體驅動與 CPU 共同處理，過程中容易受到系統負載、網路卡驅動程式或 CPU 單核心效能限制。
第三方安全軟體干擾
防毒軟體、防火牆或防護軟體（如 Windows Defender、第三方網頁防護）會對軟撥的 PPPoE 封包進行即時掃描與過濾，進而拉低下載/上傳速率。
網卡進階功能未優化
Windows 預設的網卡省電模式或特定封包卸載功能（如 Large Send Offload / TCP Checksum Offload）未針對 PPPoE 最佳化，導致傳輸效率下降。
簡易處理與改善步驟
停用/關閉防毒軟體與防火牆試測：暫時關閉第三方防毒軟體再進行測速，確認是否為即時掃描導致減速。
更新網卡驅動程式： 前往主機板或網卡原廠（如 Realtek, Intel）官網下載最新驅動，避免使用 Windows 內建的通用驅動。
調整網卡進階設定：
開啟 裝置管理員 -> 網路介面卡 -> 內容 -> 進階。
將 節能乙太網路 (Energy Efficient Ethernet / EEE) 設為 停用 (Disabled)。
將 Green Ethernet 設為 停用 (Disabled)。
透過 CMD 重置 TCP/IP 網路架構：
以管理員身份執行命令提示字元，輸入：
netsh winsock reset
netsh int ip reset
（執行後需重啟電腦）。
結論建議：
若數據機硬撥能達到申辦速率，代表實體光纖線路與機房供裝皆完全正常。
若使用者無特殊需求（如固定 IP 指定需求），建議直接透過數據機/路由器硬撥連線，除了能獲得最穩定的滿速體驗外，也能節省電腦 CPU 資源。

(繼續閱讀...)

chunju 發表在 痞客邦 留言(0) 人氣()

(中華電信 MOD) 更換為 Model 503 機上盒後，其他電視頻道正常、唯獨 Hami Video 開不了或無法播放，通常不是傳統的 IPTV 訊號問題，而是OTT 影音串流介面（封包走 Internet/DRM 驗證）與網路設定或帳號綁定異常導致。
常見的原因與排查方向如下：
1. 網路連線與 DNS 設定（最常見）
MOD 的一般電視頻道走的是獨立的 Multicast（組播）專用通道，即使 Internet 沒通或 DNS 錯誤，電視頻道依然能看；但 Hami Video 屬於 Unicast/OTT 串流，必須經過標準的 Internet 連線與網址解析。
原因：如果機上盒未順利取得 Internet IP、自動取得的 DNS 異常，或是自備的 Wi-Fi 分享器／防火牆擋住了特定的串流 Port/域名，就會導致 Hami Video 載入失敗或黑畫面。
查測方式：
確認小烏龜（光世代數據機）與 MOD 503 之間是否直連，儘量避免中間經過未設定好 IGMP Snooping 或有特殊防火牆設定的自備路由器。
進 MOD 系統設定選單，檢查網路連線狀態，確認是否有順利取得 Internet IP 與預設 DNS。
2. DRM 版權保護與 HDCP 協定未過
Hami Video 內的影音內容有嚴格的數位內容權利管理（DRM）保護。
原因：503 機上盒在輸出高畫質 DRM 內容時，會要求電視端或中間的影音設備（如擴大機、HDMI 切換器）符合 HDCP（高頻寬數位內容保護）規範。
若 HDMI 線材過舊、連接切換器、或是電視 HDMI 埠的 HDCP 協定未能順利 Handshake（握手），一般頻道可能放得出來，但 Hami Video 會黑畫面或報錯。
查測方式：
將 HDMI 線直接插在電視上，不經過任何切換器或 Soundbar。
嘗試更換一條支援 HDCP 2.2 以上的 HDMI 線，或更換電視的其他 HDMI 插孔。
3. 機上盒機型綁定（MAC Address / 門號對應未同步）
原因：換機上盒後，後台系統需要將您的 Hami Video 訂閱權益與 MOD 服務門號（或新 503 機上盒的 MAC Address / Device ID）重新綁定。
如果工程師換機後，電信後台機房尚未完全完成開通資料同步，就會出現「系統找不到這台機上盒的 Hami Video 授權」而無法觀看。
查測方式：
進 MOD 503 內的 Hami Video App，嘗試先登出帳號再重新登入（或選擇以「MOD 門號登入/認證」）。
重新開機：直接關閉 MOD 機上盒電源（或拔掉電源線），等待 30 秒後重新插電開機，強制機上盒向機房重新拉取最新的授權 Profile。
4. 系統快取或 App 版本未更新
原因：新裝設或剛更換的 503 機上盒，內建的 Hami Video 應用程式可能仍為舊版韌體快取狀態，或是版本與後台 API 不相容。
查測方式：
檢查 MOD 503 是否有系統韌體更新可下載。
入 App 專區確認 Hami Video 是否有更新提示。
快速檢查步驟建議
重啟設備：先重啟光世代數據機（小烏龜），待連線穩定後，再重啟 MOD 503 機上盒。
直連測試：確保 MOD 503 是用網路線直接插在小烏龜上。
重新認證：在 MOD 上打開 Hami Video，手動執行「登出/重新認證門號」。

(繼續閱讀...)

chunju 發表在 痞客邦 留言(0) 人氣()

當無線基地台（Wi-Fi 6 Router / AP）開啟 802.11ax 模式時，會採用新的信標封包格式（Beacon Frames）以及更進階的傳輸機制（如 OFDMA、Target Wake Time 等）。
如果舊款手機或筆電的網卡晶片（如舊款 Intel、Broadcom、Realtek）或驅動程式太舊，無法識別這些新的信標資訊，就會出現各種連線異常。
常見的相容性故障現象
完全搜尋不到 Wi-Fi：明明 AP 開著，但舊設備的 Wi-Fi 列表裡完全找不到該 SSID。
看的到連不上：點擊 Wi-Fi 輸入密碼後，一直顯示「連線中」、「無法取得 IP」或直接跳出「密碼錯誤 / 連線失敗」。
頻繁斷線或死機：連上後只要開始傳輸大流量（如看影片），舊設備的網卡驅動程式直接崩潰（甚至導致筆電藍底白字，如 Intel 網卡爆出 Netwtw08.sys 錯誤）。
現場與客戶端排錯 SOP（實務處置方案）
遇到這類舊終端設備衝突時，可以依序採取以下幾種解決方案：
方案 1：優先更新終端設備的網卡驅動程式（最根本的解法）
如果是 Windows 筆電，這通常是 Intel 舊款 Wi-Fi 網卡（如 AC-7260, AC-8260, AC-3165） 的已知 BUG。
做法：前往網卡晶片官網（如 Intel 官網）下載並安裝最新版網卡驅動程式。
Intel 官方早前已針對此問題發布更新，修復了舊網卡無法辨識 802.11ax 信標的問題。
2. 在路由器端開啟「相容模式」或調整無線模式
若終端設備為舊款 Android 手機、電視盒或無法更新驅動的嵌入式設備：
調整模式：進入 AP/路由器設定介面，將 2.4GHz 或 5GHz 的無線模式從 802.11ax only 改為 802.11a/b/g/n/ac/ax 混合模式（Mixed Mode）。
關閉 AX 特性：部分路由器允許單獨關閉 OFDMA 或 TWT（目標喚醒時間） 功能，關閉後可提升對舊設備的相容性。
3. 檢查安全加密協定（WPA3 相容性問題）
很多時候不只是 802.11ax 本身，而是 Wi-Fi 6 預設搭配的 WPA3 加密 導致舊設備無法連線。
做法：將路由器的加密方式從 WPA3-Personal 改為 WPA2/WPA3-Personal 混合模式，或是暫時降回 WPA2-PSK (AES) 測試。
4. 實施雙頻分流（2.4G 與 5G 分開 SSID）
如果 AP 開啟了 Smart Connect（雙頻合一 /Band Steering），舊設備常因無法正確處理頻段切換而斷線。
做法：將 2.4GHz 與 5GHz 的 SSID 分開設定（例如 Home_2.4G 與 Home_5G）。
讓舊設備專門連線至 2.4GHz（通常設定為 802.11n/ac），新設備則連線至 5GHz（802.11ax），確保兩者互不干擾。

(繼續閱讀...)

chunju 發表在 痞客邦 留言(0) 人氣()

過去車禍出險次數的滾動機制，就是保險公司用來篩選高風險保戶、維持保費公平性的核心演算法。
強制險與第三人責任險（體傷/財損）： 完全是「計次不計金額」。
只要有責出險，不論理賠金額是 3,000 元還是 30 萬元，一律加等/加點。
車體險： 採「次數＋金額」雙軌綜合計算（係數表同時考量過去 3 年的出險次數與賠款總金額比率），但次數的權重極高。即使小擦撞只賠幾千元，多出險幾次，隔年保費加成或直接被拒保的風險依然非常高
紀錄保留 5 年，加減費回溯 3 年
資料庫紀錄（5 年）： 保險事業發展中心（保發中心）及各產險公司資料庫，依《金融消費者保護法》與《個人資料保護法》相關規範，出險與拒保紀錄的法定檢索與保存期限通常為 5 年。超過 5 年的舊資料原則上不會再作為核保扣分依據。
肇事加減費（3 年）： 不論是強制險或任意險（車體險、第三人責任險），費率係數計算都是以「過去 3 年」的紀錄為滾動基準。超過 3 年的紀錄會自動淡出，不再影響保費計算。
體險與責任險的加減費邏輯
車體險： 採用「過去 3 年滾動點數制」。未出險減點（降保費），有出險加點（漲保費），3 年前的舊紀錄隨時間推移會移出統計區間。
強制險與責任險： 採用「等級制」，每一次有責出險，強制險調升 3 個等級（費率增加約 30%）；若要降回基本等級或享受優惠，必須連續 3 年無出險紀錄才能逐步調降。
拒保紀錄上傳「產險聯盟區塊鏈」與全業連動
產險區塊鏈（保險科技共享平台）： 產險公會推動的保險區塊鏈主要用於「理賠防詐」、「車險理賠區塊鏈認證」與「理賠紀錄通報」，大幅提升了跨公司查詢出險紀錄的效率。
拒保連動實務： 當一家公司拒保時，其他公司是否會跟著拒保？
紀錄透明度： 透過保發中心集中資料庫與公會系統，所有產險公司都看得到你的「出險紀錄與次數」。
連動效果： 如果拒保原因是「3 年內頻繁出險（如 3 次以上）」，因為各家產險公司的風控標準相似，確實很容易出現「在一間被拒，換到其他家也被拒保，或被要求大幅提高保費/加扣自負額」的情況。
其他拒保原因： 如果是因單一公司的特定政策（例如車款過於特殊、改裝車或特定高風險職業），換其他家可能還有核保空間；但如果是「理賠次數過高」或「有詐欺嫌疑/道德風險」，全業界通通拒保的機率極高。
車體險係數怎麼算？
https://www.cathay-ins.com.tw/c-insurance/personal/knowledge-blog/car-damage-insurance

(繼續閱讀...)

chunju 發表在 痞客邦 留言(0) 人氣()

chunju 發表在 痞客邦 留言(0) 人氣()

chunju 發表在 痞客邦 留言(0) 人氣()

有人問我為什麼中華電信不繼續用住友（Sumitomo）那種純 Bridge 數據機，而是全面改發 DASAN（大山）或 Zyxel 這類包山包海的型號？
降低 90% 一般用戶的客服申告（Reduce OpEx）：
大部分一般民眾根本不知道什麼叫「PPPoE 撥號」、什麼叫「自備 Wi-Fi 路由器」。
如果只給純 Bridge 數據機，用戶家裡沒裝分享器就會抱怨「為什麼手機不能上網？」、「為什麼電腦要點撥號才能連？」。
All-in-One 設備開機就有 Wi-Fi 和 PPPoE，大幅減少了現場裝機與客服教導的成本。
MOD 與 IPTV 的 VLAN 整合需求：
中華電信有龐大的 MOD 用戶群。
MOD 需要獨立的 VLAN 與 IGMP Snooping multicast 封包傳輸。
將所有功能整合在一台 Gateway 內，機房透過 TR-069 自動派送設定，MOD 插上 Port 4 就能直接看，大大降低了佈線與設定複雜度。
電信設備採購成本（CapEx）考量：
將 OLT/ONT、Wi-Fi、Router 整合在單一標案中，大批量採購（如十幾萬台）能顯著壓低單台硬體成本。

(繼續閱讀...)

chunju 發表在 痞客邦 留言(0) 人氣()

chunju 發表在 痞客邦 留言(0) 人氣()

正常的網站流程與經過第三方清洗的流程差異如下：
正常流程
國外/國內使用者->中華電信電路->客戶伺服器
經過國外清洗中心的流程（第三方清洗的情況）
全球攻擊/正常流量->國外資安清洗中心(洗掉惡意封包)->清洗中心用自己的 IP 轉發乾淨流量->中華電信電路->客戶伺服器
為什麼這會引發「PPS (每秒封包數) 過大被阻擋」的問題？
這裡就是ISP或資安系統會「誤判」或「防禦」的核心原因：
流量高度集中：
原本分散在全球成千上萬個使用者的連線，經過國外清洗中心過濾後，全部匯集由清洗中心少數的幾組「國外 IP (來源 IP)」集中傳回給客戶。
封包數量（PPS）瞬間爆量：
雖然流量的總 Mbit/s（頻寬）可能沒有擠爆，但因為所有連線都來自那幾組國外 IP，在電信業者的網管設備看來，就會呈現：
突然有少數幾個國外 IP，在極短時間內對著台灣這個客戶發送龐大數量的封包（高 PPS）！
ISP 自動資安防禦機制被觸發：
電信業者的自動化 DDoS 防禦系統（如 IPS）抓到這種「高 PPS」特徵，會以為是國外 IP 正在對台灣客戶發動 SYN Flood 或 UDP Flood 等 DDoS 攻擊，於是自動把這些國外 IP 給封鎖（Drop/Block）掉了。
因為清洗站回傳時來源 IP 很集中且 PPS 極高，防禦系統太過死板，以為那是攻擊流量給予攔截。
客戶希望ISP能將這些「國外清洗站的特定 IP」加入白名單或調整 PPS 門檻，才不會讓他們的正常業務流量一直被誤殺。
簡單來說，意思就是：
「客戶使用了國外的雲端資安廠商（例如 Cloudflare, Akamai, Imperva 等），當流量從世界各地連到客戶的伺服器時，會先經過國外的清洗中心『洗掉』惡意攻擊，最後只把『乾淨的流量』從國外的清洗中心轉發回客戶在台灣的伺服器。」
電信等級的 DDoS 防禦機制（IPS/Clean Pipe）涉及整體骨幹網路安全，通常無法針對特定單一電路直接「關閉」或「無限放寬」全域 PPS 防禦閾值，否則會帶來電信端與客戶端被真實 DDoS 癱瘓的風險。

(繼續閱讀...)

chunju 發表在 痞客邦 留言(0) 人氣()

chunju 發表在 痞客邦 留言(0) 人氣()

chunju 發表在 痞客邦 留言(0) 人氣()

chunju 發表在 痞客邦 留言(0) 人氣()