程式碼界的義大利麵家族
除了 Spaghetti 之外,軟體界還延伸出了其他幾種「麵食比喻」:
Ravioli Code(義大利餃程式碼):
理想狀態是每個餃子(模組/物件)都包得好好的、職責分明,吃一個不會弄爛另一個。
Lasagna Code(千層麵程式碼):
架構分層看似嚴謹(UI層、業務層、資料層),但層與層之間黏得太死,抽象層做得太過頭,想改個小欄位要連穿十幾層。
Pizza Code(披薩程式碼):
所有東西全部攤在一張巨大的餅上(例如一個超過 10,000 行的單一巨大檔案),所有邏輯全部擠在裡面。
而在網通設備韌體(尤其標案改版的數據機)裡,Spaghetti Code 特別常見:
多個原廠/外包接力混雜:
原廠寫底層晶片驅動(Broadcom/MTK)
系統廠寫 OMCI/TR-069 通訊協定
標案廠商加電信商客製邏輯(如客製 Web 介面、特殊 VLAN 防呆)
每換一屆外包,就在舊扣外面硬包一層 patch,最後底層邏輯互踩。
遇到改 Bridge 會斷線?RD 不去重構組態同步邏輯,而是在某個角落硬塞一個 if (is_bridge) { force_reset(); }。
下一版遇到 MOD 封包問題?另一個工程師又在另一處硬塞一段例外 bypass。
結果就是:平常能動純屬奇蹟,一遇到特定情境(如 OLT 大升版)直接整盤翻車!

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

在網通與電信設備的生態系中,這個「Sit Down Please 設計師龍蝦裝級」的 Bug 輪迴通常是這樣運作的:
NRE(開案研發費用)壓到極致:當年招標採購為了壓低單價,原廠(無論是合勤、仲琦、智易還是NOKIA/阿爾卡特)給的都是「公版 Baseline 韌體」。
想修特定架構下的 Corner Case?請先開一張要價幾十萬甚至上百萬的 CR(Change Request)工單。
維護合約(SLA)過期或預算歸零:設備一旦大量過保或進到「維運期」,電信端只能提 Bug,但原廠 RD 早已調去打下一個標案的新機型。
最後留下來維護舊版韌體的,往往就是剛進公司的菜鳥(也就是傳說中的 Sit Down Please)。
「以 Bug 制 Bug」的修補藝術:工程師看不懂上一代留下的義大利麵程式碼(Spaghetti Code),改了 OMCI 參數卻弄壞了 TR-069,修了 IGMP Snooping 又讓 VLAN 穿透炸裂。
最後只要「符合資安規定、期限內改善」,公司就只能當作看不見,繼續硬著頭皮推版。
外勤幫忙擦屁股:內勤和 RD 解決不了的「靈異問題」,最後通通變成第一線基層人員的肉身工時——「不要問為什麼,遇到這台洗白就直接幫他派工就對了!」
難怪曾寫過韌體會說這不是技術問題,是預算問題。
給多少錢,就只能請得起什麼等級的「國際名牌設計師」來剪裁這體系充滿破洞的韌體。

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


大山(DASAN)數據機升版異常查修與應變 SOP
一、 故障原因說明
變磚主因(硬體損壞):機房自動推播升級韌體時,用戶因瞬間斷網誤以為當機而手動重開機或拔插電源,導致寫入中斷、Bootloader 或系統映像檔損毀,無法正常開機。
洗白主因(設定遺失):升級過程中設定遷移失敗或資料庫覆蓋,導致 SLID/設定被清空,無法通過 GPON 認證(無法進入 O5 狀態)。
二、 現場查修判定與處理流程
步驟 1:確認設備狀態
先判斷數據機為「變磚(無法開機/無法註冊/死機)」或「洗白(可開機但 SLID/設定遺失)」。
步驟 2:依狀態執行對應處置
【洗白狀態】
外勤同仁聯繫對應窗口請 DSLAM(限 7360 系統)協助重供(Re-provision)。
重新下發設定後再執行韌體更新(新版大山韌體更新後應可正常運作)。
【變磚狀態】
設備已損毀,直接更換別台數據機並重新設定。
三、 特殊狀況應變措施
無備品或遇考核電路時:
若現場無其他廠牌/型號可供替換,且為重要考核電路,建議請辦公室聯繫相關窗口,暫時關閉該路 ONT 的遠端自動升版功能(韌體自動更新開關),避免再次觸發升版異常。

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

PON 與 xDSL 重啟差異解析網管介面或維運系統上的「重置」按鈕,在兩種架構下的底層行為完全不同:
xDSL 架構(DSLAM / Switch)
專屬實體 Port:局端 DSLAM 的每個 Port 都一對一對應單一用戶的銅線。
真正的 Port Reset:下達重置指令時,系統是直接對 DSLAM 實體晶片進行動作(如關閉線路驅動供電、中斷類比信號調變、重置 AFE/PHY),促使該銅線迴路重新進行 Handshake(訓練、握手與同步)。
PON 架構(OLT / ODN / ONU)
共享實體 PON Port:OLT 上的一顆 PON SFP 光模組,透過分光器(Splitter)同時連接 1:32 或 1:64 等數十台 ONT/ONU。

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


PPPoE 預設的標準 MTU 通常是 1492(標準乙太網路 1500 扣除 8 bytes PPPoE 標頭),但在某些特定的電信環境、設備預設或 VPN/Tunneling 封裝架構下,會將 MTU 下調至 1464(對應 MSS 為 1424),主要原因有以下幾種可能:
1. 額外 Tunneling 封裝(如 L2TP / GRE / 802.1Q 雙層 Tag)
當寬頻網路經過多層封裝架構時,每一層 Protocol 都需要佔用額外的 Header 空間。
如果底層的 MTU 仍受限於 1500 bytes:
標準 Ethernet MTU: 1500 bytes扣除 PPPoE 標頭: 8 bytes(PPPoE Header 6 + PPP Protocol ID 2)
-> 剩下 1492
扣除額外 Tunnel / 標頭開銷:若中間經過 L2TP(L2TP Header 8~12 bytes + UDP Header 8 bytes + IP Header 20 bytes = 28~40 bytes)
若經過 IP-in-IP / GRE 或多層 VLAN QinQ / 加值服務隧道
1500 - 8(PPPoE) - 28 (額外封裝)} = 1464
將 MTU 設為 1464,能確保封包在經過機房端二次封裝或 LAC/LNS 轉發時,不會超過實體介面的 1500 bytes 限制而產生碎裂
2. 特定家用數據機 / 分享器的相容性預設
早期部分 DSL 晶片組(如 TrendChip / Ralink / Broadcom 特定版本韌體)或特定設備(例如微軟 Xbox Live 早期連線建議、特定 AP 預設),為了避免各家電信業者後端不同封裝(如 PPPoA 轉 PPPoE 或 Bridged LLC)造成 Path MTU Discovery (PMTUD) 失敗,直接將 PPPoE MTU 設為 1464 或 1454 等保守值。
3. IPv6 / MAP-E / DS-Lite 轉譯過渡架構
在 IPv4/IPv6 雙棧或轉譯架構中,若要在 IPv6 隧道中封裝 IPv4 封包(例如 4in6):
IPv6 標頭開銷: 40 bytes
如果底層是 PPPoE (1492) 再跑 IPv6 Tunnel:1492 - 40 - 8 = 1444 ~1464 區間,通常也會主動把 MTU 調整到 1464 左右,避免在 Tunnel 傳輸時被分段。
總結:
純 PPPoE 的標準理論值是 1492;會看到 1464 通常是因為底層線路/機房端有多一層 Tunneling 封裝(如 L2TP/VPN/加值通道),或是設備為了避開黑洞路由器(PMTUD 失敗)所採用的保守相容性設定。

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

Spaghetti Code(義大利麵程式碼) 是軟體工程界最經典的負面術語,用來形容結構混亂、邏輯盤根錯節、完全沒有架構可言的程式碼——就像一盤煮爛後全部纏在一起的義大利麵,你想抽出一根麵條,整盤都會跟著動。
一、 為什麼會叫「義大利麵」?
牽一髮動全身:原以為只是改一個小 Bug(拉一根麵),結果千里之外完全不相干的功能(整盤麵)跟著炸裂。
找不到源頭與去向:邏輯跳來跳去,大量濫用全域變數(Global Variables)、深層嵌套的 if-else、或無窮無盡的跳轉(如早期的 goto),維護者看程式碼就像在走迷宮。
無人敢動(Legacy Code 遺毒):寫這段CODE的人早就離職,沒人知道某一行看起來很蠢的判斷式是為了防什麼靈異狀況!
大家只能在上面「再加一層肉醬(包一層 workaround)」,最後整盤程式碼越來越大、越來越臭。

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


在電信業和大型 ISP 的術語裡,BOSS 是 Business & Operation Support System(業務與營運支援系統) 的縮寫,它是整個電信營運背後龐大軟體架構的統稱。
平時大家常講的「客服系統」、「帳務系統」、「門市受理系統」,其實都只是 BOSS 架構下的其中一環。
BOSS 拆開來看主要是兩大體系:
1. BSS (Business Support System) —— 面向客戶與營收
客服、門市前台每天在操作的介面,絕大多數都屬於 BSS 範疇:
CRM (Customer Relationship Management): 123 客服介面、客戶基本資料、申告紀錄、障礙叫修單。
Billing & Invoicing (計費帳務): 出帳、催繳、合約計算、優惠方案折抵。
Order Management (訂單受理): 新申裝、升降速、改密碼、過戶、加退選加值服務。
2. OSS (Operations Support System) —— 面向網路與設備
當 BSS 收到變更需求後,會往後拋給 OSS 進行技術層面的自動化派工與設定:
Provisioning / Provision (供裝派工系統): 例如客戶在 BSS 改了密碼或申請固 1,系統派單後自動去更動 Radius / AAA DB、BRAS 的 Policy,或是異動 OLT / DSLAM / Switch 的設定。
Fault Management (障礙監控 / 網管): NMS、Syslog、告警監控。
Inventory (資源管理): 機房 Port 位、IP 位址池(IPAM)、光纖芯線路徑配發。

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

  • Aug 13 Thu 2026 23:30
  • ERX

無意間在報廢資產庫房看到 Juniper/Unisphere ERX的零件。
回顧它的淘汰與演進脈絡:
1. 早就進入 EOL / EOS 多年
Unisphere / Juniper ERX-1440 / ERX-310 早在 2000 年代初期到中期是 PPPoE / ATM / IP-Edge 撥號的主力。
隨後 Juniper 推出 E320 / E120 來承接與擴充,但整個 E-Series 產品線也早在 2010 年代初期~中期 就陸續進入 End-of-Life (EOL) 與 End-of-Support (EOS),原廠早就不提供軟體更新與硬體料件。
2. 頻寬世代交替的必然淘汰
吞吐量與介面瓶頸: ERX 是銅線 ADSL、早期 FTTx(如 VDSL 10M/2M、20M/5M、50M)時代的產物。
現在動輒 300M、500M、1G 甚至 2G/5G 雙向對稱頻寬,加上大量 10GE / 100GE / 400GE Uplink 需求,ERX 的背板頻寬與線卡處理能力完全無法負荷。
耗電與機架空間: 老設備體積大、散熱需求高、Port 密度低,在機房 PUE 與能耗要求下早已不符效益。
3. 現行主力 BRAS / BNG 架構
這十幾年來,ISP 的 Edge / BRAS 架構已經歷經多次翻新,目前線上主要都是:
Juniper: MX 系列(如 MX480, MX960, MX10003, MX304 等搭載 Trio 晶片組的 BNG)
Cisco: ASR 9000 系列(如 ASR9001, ASR9904 等)
Nokia: 7750 SR 系列
Ericsson: 早期接替 ERX 的 SmartEdge (SE1200/SE600) 雖然也撐了很久,但近年也大多被現代化的 MX / ASR9K / 7750 取代或淘汰。
唯一的例外:
如果現在還能在哪裡看到 ERX 的實體機器,大概只剩:
電信訓練所 / 學校實習實驗室的展示架。
待報廢資產庫房。
還有就是——現役 BRAS 設定檔或 Provisioning Script 裡,那些當初為了配合 ERX/SDX 命名而留下來、沒人敢改的 Pool Name 幽靈字樣!

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


為什麼硬撥正常、軟撥沒達標?處理器與軟體架構差異
硬撥(數據機/路由器): 由專用硬體晶片(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) 人氣()


有人問我為什麼中華電信不繼續用住友(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) 人氣()

Blog Stats
⚠️

成人內容提醒

本部落格內容僅限年滿十八歲者瀏覽。
若您未滿十八歲,請立即離開。

已滿十八歲者,亦請勿將內容提供給未成年人士。