GPON SFP ONT Nokia G-010S-A
Tóm tắt
Một GPON ONT dạng SFP hiệu Nokia G-010S-A (phần cứng ALCATELLUCENT 3FE46541AA, SFP serial ALCLF9738C78), cắm vào khe sfp1 của MikroTik RB3011. Firmware là OpenWrt Lantiq đã mod, được cấu hình giả lập serial GPON của modem Huawei HG8145V5-20 để dùng thay modem quang của Viettel.
Ngày 2026-08-17 con SFP này đã chạy Internet thật: OLT Viettel dựng dịch vụ đầy đủ, RB3011 quay PPPoE qua VLAN 35 trên sfp1 và toàn bộ LAN ra Internet qua nó (446 MB đã đi qua), không có hộp Huawei trong đường truyền.
Vấn đề còn lại không phải khả năng hoạt động mà là độ ổn định: PON rơi khỏi O5 sau 4,6–8,8 phút, rồi tự đăng ký lại sau 1,3–6,2 phút. Đo đạc đã chứng minh mọi chỉ số phía thiết bị đều sạch (không lỗi bit, không suy giảm quang, không lỗi OMCI) — việc ngắt là quyết định của hệ thống Viettel, không phải sự cố kỹ thuật. Từ phía nhà không còn gì tinh chỉnh được.
Trạng thái cuối ngày 2026-08-17: đã rút con SFP khỏi khe, trả về hộp Huawei. Đường qua SFP chập chờn 5–10 phút một lần nên không dùng thật được. Cấu hình phía RB3011 đã được gỡ ngày 2026-09-04 (dọn dẹp trước khi nâng cấp RouterOS) — muốn thử lại thì phải dựng lại vlan35-sfp + pppoe-sfp, các lệnh còn lưu ở topology-mang-homelab.
Đính chính bản ghi ngày 2026-08-16
Bản ghi trước kết luận: “Không lên được internet trên mạng Viettel — Viettel đã siết kiểm tra ONT-type ở tầng OMCI nên bản giả lập không dựng được đường dữ liệu (GEM).” Kết luận này sai, và nó đã khoá luôn bước đúng nằm ngay sau nó trong checklist.
Nguyên nhân sai là một lỗi đo: lệnh onu gpe_gem_port_get <n> nhận tham số là GEM port ID, không phải chỉ số tuần tự. Phiên trước quét khoảng 0–63 rồi kết luận “không có GEM”, trong khi GEM port ID thật do OLT cấp là 303, 431, 687 (dữ liệu) và 4095 (multicast). Các cổng này vốn đã ở trạng thái gem_port_enable=1 ngay từ đầu.
Hệ quả của việc đính chính:
- OLT Viettel có dựng dịch vụ cho con SFP này, và dựng đầy đủ.
- OLT kiểm tra serial GPON, không kiểm tra ONT-type. Toàn bộ nhánh giả thuyết “phải khai đúng loại thiết bị” là không cần thiết.
- Việc thật sự còn thiếu chỉ là gắn tag VLAN 35 phía RB3011 — đúng như chính bản ghi 2026-08-16 đã dự đoán ở phần cuối.
Điều kiện cần để hoạt động
Bắt buộc — giả lập serial GPON. OLT cấp phép theo serial. Không mang serial mà Viettel đã đăng ký thì không có ONU-ID, không có O5, không có dịch vụ.
U-Boot env: nSerial = HWTC856220AD
nPassword = rỗng (0x00 ×10)
→ OMCI ONU-G: Vendor id = HWTC, Serial number = HWTC856220AD
Bắt buộc — VLAN 35 có tag phía router. Hộp Huawei là HGU, tự map LAN↔VLAN 35 nội bộ nên RB3011 nối vào cổng LAN của hộp chạy PPPoE untagged được. Con SFP là SFU trong suốt, không có tầng map đó, nên RB3011 phải tự tạo interface VLAN 35 trên sfp1 và chạy PPPoE trên đó. Xem pppoe.
Đó là tất cả. Ngày 2026-08-17 đã chạy lại với toàn bộ các trường identity trả về giá trị nguyên bản (equipment_id=HWTC856220AD, ont_version=R4.2.139F.007, software version 6BA1896SPE2C02 với binary MD5 khớp bản gốc, mod_omcid=0) — và vẫn lên O5, ba data GEM enable=1, PPPoE quay được, LAN ra Internet bình thường (IP 116.101.240.67). Cấu hình tối thiểu đã được kiểm chứng: chỉ giả lập serial GPON + gắn tag VLAN 35 phía router.
Không cần — đã kiểm chứng bằng thực nghiệm:
| Trường | Kết luận |
|---|---|
| ONU2-G Equipment id | Không cần. GEM đã bật trước khi đổi. Giá trị nguyên bản là chính chuỗi serial nhét vào ô model — vô nghĩa với mọi ONT thật, mà OLT vẫn dựng dịch vụ đủ |
| ONU-G Version | Không cần, cùng lý do |
| ME 7 Software version | Không cần. Có lúc tưởng patch thành V5R020C10S212 làm giảm thời gian giữ O5, nhưng số liệu thu thêm đã phủ định: hai cụm chồng lấn nhau (xem phần mất ổn định). Đã trả về bản gốc 6BA1896SPE2C02 cho gọn |
Sửa file MIB .ini, ghi EEPROM i6 | Không có hiệu lực. omcid.sh sinh lại /etc/mibs/custom.ini từ nameless.ini + giá trị uci mỗi lần khởi động, đè mọi thay đổi thủ công |
Chỗ duy nhất chỉnh identity có tác dụng là uci (gpon.onu.equipment_id, gpon.onu.ont_version), vì config_onu.sh init không ghi đè chúng.
Cấu hình phía RB3011 (đang chạy)
/interface/vlan/add name=vlan35-sfp interface=sfp1 vlan-id=35
/interface/pppoe-client/add name=pppoe-sfp interface=vlan35-sfp \
user=h004_ftth_sonnb9 add-default-route=yes
/interface/list/member/add list=WAN interface=pppoe-sfp
/ip/firewall/nat/add chain=srcnat action=masquerade out-interface=pppoe-sfp
pppoe-out cũ trên ether1 giữ nguyên làm đường lùi — cắm nguồn và cáp hộp Huawei vào ether1 là có mạng lại ngay.
Bẫy bảo mật đã gặp: bộ luật firewall trên router dựa vào interface list WAN, mà RouterOS mặc định chain input là accept. Trong khoảng vài phút từ lúc PPPoE lên tới lúc thêm pppoe-sfp vào list WAN, SSH/Winbox/HTTP của router hở ra Internet. Khi thêm bất kỳ WAN mới trên cấu hình kiểu này, phải thêm vào interface list trước hoặc ngay khi interface lên. Xem huong-dan-tang-cuong-bao-mat-mikrotik.
Truy cập quản trị
Firmware có hai slot (image0/image1) với credential và host key khác nhau. Hiện đang chạy image0 — bản mod interop Final_v2021_12_28_c2 / 2023.02.08, mới hơn image1 và dùng /etc/mibs/custom.ini.
- IP:
192.168.1.10(web LuCI + SSH). Từ LAN cần route: thêm IP192.168.1.2/24trênsfp1của RB3011, masqueradeout-interface=sfp1, và route192.168.1.0/24 → 10.0.0.1trên máy trạm. - SSH: dropbear đời 2014 không hiểu key ed25519 — phải dùng key RSA. Đồng thời OpenSSH mới trên macOS chặn chữ ký RSA/SHA-1, nên cần:
ssh -o PubkeyAcceptedAlgorithms=+ssh-rsa -o HostKeyAlgorithms=+ssh-rsa -i ~/.ssh/id_rsa root@192.168.1.10 - image1 cho
rootđăng nhập không mật khẩu; image0 có mật khẩu riêng do chủ hệ thống đặt. - Nhiều script trên máy gọi
uci,fw_setenvkhông kèm đường dẫn tuyệt đối. Chạy qua SSH phảiexport PATH=$PATH:/sbin:/usr/sbintrước, nếu không chúng thất bại im lặng hoặc nửa vời.
Cảnh báo: không flash khi chưa có serial console
U-Boot của con này không tự lật về slot cũ khi image mới không boot: boot_image0/boot_image1 nạp rồi bootm vô điều kiện, hai cờ image0_is_valid/image1_is_valid không được đường boot đọc, và boot_fail là biến của firmware chứ không phải cơ chế fallback. Nhánh boot_image_err (có httpd cứu hộ) chỉ chạy khi biến commit rỗng, không phải khi boot lỗi.
Hỏng image đang boot ⇒ rơi vào U-Boot prompt, chỉ với tới được qua serial console. Pinout UART nằm trên chân Molex của SFP: 3.3V p15/16, TX p3, RX p6, GND p10/14, 115200 8-N-1.
Đã sao lưu toàn bộ flash (uboot, uboot_env, hai slot firmware, configfs, ri, ribackup, sfp, binary omcid gốc) kèm SHA256SUMS trong raw/sfp-gpon-nokia/flash-backup-20260817/. ri và ribackup có SHA256 giống nhau — hai bản hiệu chuẩn quang đều nguyên vẹn. Identity gốc trong RI: MfrID ALCL, HardwareVersion 3FE46541AA, G984Serial F9738C78, CleiCode BVL3A8JNAA, Mnemonic G-010S-A.
Thông số quang
| Tx power | +2,2 … +2,6 dBm (bình thường cho B+) |
| Rx power | −24,0 … −24,4 dBm (thấp về số đo; B+ sensitivity ~−27) |
| Nhiệt độ module | 44–46 °C |
Rx thấp không phải vấn đề: bộ đếm cho bip=0, HEC=0, BWmap=0 — thu không sai một bit nào. Đường quang chỉ hơi yếu về con số, còn chất lượng hoàn hảo. Không cần so với số Rx của hộp Huawei nữa.
Cách kiểm tra nhanh (replayable)
onu ploam_state_get # mong curr_state=5
onu gtc_status_get # mong onu_id=47 (không phải 255)
onu gpe_gem_port_get 303 # tham số là GEM port ID, KHÔNG phải chỉ số
onu gpe_gem_port_get 431
onu gpe_gem_port_get 687 # mong gem_port_enable=1, gem_port_is_omci=0
onu gpe_gem_port_get 4095 # multicast: gem_port_is_mc=1Để xem đối thoại OMCI với OLT: đặt uci set gpon.onu.omci_log_level=1 (thang nghịch: 0 chi tiết nhất, 4 tắt; script chỉ nhận 1–7). Mặc định là 3, gần như im lặng. Lưu ý omcid ghi log vào /tmp/log/debug — cùng file mà logread -f -F ghi lại từ đầu khi ring buffer 16 KB wrap, nên log verbose bị xoá trắng liên tục. Sửa đường dẫn -l trong /etc/init.d/omcid.sh sang file riêng thì mới giữ được log.
Những gì OLT làm sau khi ONT vào O5
OLT đọc identity rồi provisioning trọn vẹn; ONT trả về OK cho từng lệnh đường dữ liệu, không lỗi nào:
GetONU-G (vendor id, version), ONU2-G (equipment id), Software image @0/@1 (version, is_committed, is_active, is_valid)MibReset→MibUpload→ 206×MibUploadNextCreateGEM port network CTP ×4 (port ID 4095/303/431/687), GEM interworking TP ×3, GAL Ethernet profileCreate/Set802.1p mapper ×3, MAC bridge service profile + bridge port ×5, VLAN tagging filter ×3SetT-CONT ×11,SetPPTP Ethernet UNI @257,Create/SetExtended VLAN tagging operation
Ba dịch vụ, đọc từ ME 84 VLAN tagging filter data: VID 35 (Internet), VID 2501 (TR-069), VID 2502 (chưa rõ, bản ghi cũ chưa có).
OLT lập trình Extended VLAN tagging (ME 171) theo kiểu HGU: rule khớp frame untagged từ cổng UNI gắn cho nó VLAN 1, giả định ONT tự map LAN↔WAN nội bộ như firmware hộp Huawei. Con SFP là SFU nên không có tầng đó — nhưng vì rule chỉ khớp frame untagged, frame đã tag đi xuyên qua nguyên vẹn rồi MAC bridge + VLAN filter chuyển tới GEM đúng. Đó là lý do RB3011 gắn tag 35 thì chạy.
Đáng chú ý: OLT cấu hình ME 11 PPTP Ethernet UNI, không phải ME 329 VEIP — sau khi đọc MIB nó đã nhận ra đây là SFU và tự thích ứng, thay vì áp khuôn HGU của serial đã đăng ký. OLT cũng không chạm tới ME 134 (IP host config) hay ME 340 (TR-069 management server), tức không thiết lập đường quản trị TR-069 nào cho thiết bị này.
Năm dòng lỗi duy nhất phía ONT trong cả phiên — không nằm trên đường dữ liệu:
CORE ERR: Managed Entity class id = 373 / 350 / 292 not supported
MIB ERR: ERROR(-14) ME 334@3 init handler error (Ethernet frame extended PM)
MIB ERR: ERROR(-14) ME 334@4 init handler error
Mất ổn định: phía ta đã chứng minh là sạch
PON giữ được 4,6–8,8 phút (đo: 8m49s · 4m48s · 4m39s · 6m34s) rồi rơi, ở mọi cấu hình identity đã thử. Thời gian từ lúc khởi động tới khi lên O5 cũng dao động 1,3–6,2 phút. Phân tán lớn, không thấy quy luật.
Lúc rơi: PLOAM về vòng O2↔O3 chu kỳ 11,4 s (nT01=11000), onu_id=255.
Toàn bộ chỉ số phía ONT tại thời điểm rơi đều bình thường:
| Tầng | Bằng chứng |
|---|---|
| Quang | sig_degrade=0, sig_fail=0, loss_of_signal=0; Rx/Tx/tx-bias/nhiệt phẳng suốt chu kỳ; rơi ở đúng giá trị Rx tốt nhất |
| Bit/frame | bip=0, hec_error_corr/uncorr=0, bwmap_error=0, drop=0, omci_drop=0 |
| Cấp phát | allocations_lost=36 / allocations_total=12.605.786 = 0,0003% |
| Lưu lượng | tx_gem_bytes_total 446 MB đã thật sự đi qua |
| OMCI | 768 message; MIB upload 206/206; mọi lệnh provisioning trả OK |
| Tiến trình | omcid không restart (/tmp/omcidrebootnum rỗng, rebootcause=0) |
| Nhiệt | 44–45 °C; rơi ở đúng nhiệt độ mà nhiều phút trước đó vẫn chạy tốt |
Alarm duy nhất bật là loss_of_allocation và ploam_suf (start-up failure) — tức OLT ngừng cấp grant băng thông trong khi mọi thứ đang khoẻ.
Kết luận: không có lỗi nào ở phía thiết bị. Việc ngắt là một quyết định của hệ thống Viettel, không phải sự cố kỹ thuật. Các giả thuyết đã bị bằng chứng loại bỏ: suy hao quang, nhiệt độ / laser timing, MIB upload lỗi, omcid chết, software version.
Câu hỏi mở
Nguyên nhân hệ thống Viettel ngắt sau 4–9 phút hiện chưa biết, và hai giả thuyết từng được nêu đều đã bị chính dữ liệu làm yếu:
- Thiếu TR-069 — yếu. Nếu OLT chờ ta chạy TR-069 thì nó phải cấp IP quản trị (ME 134 IP host config data) và URL của ACS (ME 340 TR-069 management server). Log cho thấy OLT không hề chạm tới ME 134, 340, 157 hay 329 trong suốt phiên. Ta thậm chí không biết ACS nằm ở đâu.
- Đối soát hình dạng thiết bị — yếu. Sau khi đọc MIB, OLT cấu hình ME 11 PPTP Ethernet UNI chứ không phải ME 329 VEIP — tức nó đã nhận ra đây là SFU và tự thích ứng theo, không cố áp khuôn HGU. Việc ta không giống HG8145V5 rõ ràng không làm OLT khó chịu ở tầng provisioning.
Trạng thái trung thực: đã loại được suy hao quang, nhiệt độ / laser timing, lỗi MIB upload, omcid chết, software version, và làm yếu cả hai giả thuyết chính sách. Chưa có giả thuyết nào đứng vững. Mọi chỉ số phía thiết bị đã sạch nên không còn gì đo thêm từ nhà; muốn đi tiếp cần thông tin phía OLT, thứ chỉ Viettel có.
Việc còn có thể làm nhưng chưa làm:
- Phép thử rẻ: dựng
vlan2501-sfp+ DHCP client trên RB3011 xem mạng quản trị Viettel có trả lời không (cần canh cửa sổ O5 4–9 phút). Trả lời dứt điểm việc đường TR-069 có tồn tại ở tầng ta chạm được hay không. RevertĐã làm 2026-08-17 — chạy được với identity nguyên bản hoàn toàn; xem phần “Điều kiện cần để hoạt động”.equipment_id/ont_versionđể chốt cấu hình tối thiểu.
Quyết định 2026-08-17: không đầu tư vào việc dựng client TR-069. Lý do: tiền đề đã yếu (không có URL ACS, OLT không đòi hỏi), chi phí cao (OpenWrt 14.07 / MIPS, overlay chỉ còn 1,7 MB nếu chạy trên SFP), và nó đồng nghĩa với việc gửi thông tin nhận dạng sai tới hạ tầng quản lý của nhà mạng — khác về tính chất so với việc cấu hình thiết bị trong nhà.
Bài học phương pháp
- Tham số của
gpe_gem_port_getlà GEM port ID, không phải chỉ số tuần tự. Đọc sai chỗ này đã tạo ra một kết luận sai tồn tại 3 tháng. - Response của
MibUploadNextkhông có trường result — byte 8 là byte cao của ME class. Đọc như result code sẽ ra “178 lỗi” hoàn toàn không tồn tại. - Độ phân tán thời gian giữ O5 (4,6–8,8 phút trong cùng một cấu hình) lớn hơn mọi khác biệt giữa các cấu hình. Mọi so sánh A/B trên thiết bị này cần nhiều hơn 2–3 lần đo mỗi nhánh; một giả thuyết đã bị dựng lên rồi bác bỏ đúng vì lý do này.