Turris Omnia từ chối stick GPON MA5671A đã unlock: eth2 không bao giờ lên trên Turris OS 5.0.3
Đang thử thay terminal của ISP trong rack ở nhà bằng một stick GPON cắm thẳng vào router, để sợi quang chỉ đi vào một hộp thay vì hai. Stick được nhận diện, và tin tốt dừng lại đúng ở đó.
- Turris Omnia trên Turris OS 5.0.3, kernel stock
- stick GPON Huawei MA5671A với firmware đã unlock, set về SGMII 1G
- pigtail SC/APC từ ổ trên tường vào stick
- eth2 là port SFP
Module được nhận diện nhưng interface không bao giờ kích hoạt:
# dmesg | grep sfp
SFP module encoding does not support 8b10b nor 64b66beth2 vẫn down sau đó, không có carrier, counter không nhúc nhích.
Đã thử:
- flash stick về lại firmware stock, kết quả là gặp lỗi đọc EEPROM thay vào đó
- ép rate bằng ethtool -s eth2 1000 autoneg off duplex full, sau đó interface nằm ở 10 Mbit half duplex
- chuyển cùng cái stick đó sang router MikroTik, ở đó nó lên khi set port speed bằng tay
Vậy là bản thân module vẫn sống và phía quang thì ổn. Có gì trong cái stick này khiến kernel phản đối, và những stick GPON nào thực sự lên được trên Omnia thay vì bị từ chối?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
Đây là vấn đề ở phía host, không phải module chết. EEPROM trong mấy con stick GPON được tận dụng lại này khai báo một encoding mà driver sfp mainline không map được, nên phylink từ chối đưa port lên, và dòng bạn dán chính là driver đang nói đúng điều đó. Bằng chứng của chính bạn cũng chỉ về hướng đó: cùng cái stick đó lên link trên MikroTik một khi port speed được set bằng tay, nên optic và phía PON đều ổn.
Thứ duy nhất tạo ra khác biệt với tôi là một kernel đủ mới để mang theo các quirk riêng cho từng module, trên Omnia nghĩa là nhánh testing HBD với kernel 5.4. Cảnh báo trước là đây chỉ là thắng lợi một phần và phụ thuộc rất nhiều vào việc bạn có stick nào. Trên kernel đó:
Vậy nên nếu muốn Omnia chạy được ngay bây giờ thay vì chờ tới lúc nào đó, DFP-34G-2C2 là con tôi sẽ cắm vào cage. Tự test trên máy của bạn trước khi chốt, kết quả ở đây rõ ràng khác nhau giữa các stick và thậm chí giữa các bản firmware khác nhau của cùng một stick.
Có hai điều đáng chốt lại trước khi ai đó bắt đầu đoán mò. Thứ nhất, 5.0.3 đó thuộc nhánh nào, và uname báo kernel gì? Các quirk SFP riêng cho từng module mà mấy stick GPON tận dụng lại này cần chỉ được đưa vào sau, nên một bản kernel stable đã ship và một bản testing hành xử rất khác nhau với đúng cùng một module.
Thứ hai, serial của ONU đã được đăng ký ở phía nhà cung cấp chưa? Một stick chưa bao giờ được OLT cấp phép sẽ nằm đó trông như chết, và không ít nhà cung cấp từ chối đăng ký ONU bên thứ ba hoàn toàn.
Và khi cắm vào, port có bao giờ chuyển sang inband/1000base-x không, hay log dừng lại đúng ngay ở dòng encoding đó?
Nhánh stable, kernel stock cho 5.0.3, không có gì tùy chỉnh thêm lên trên. Phía nhà cung cấp không phải vấn đề ở đây, vẫn cùng sợi quang đó và stick mang đúng serial đã đăng ký.
Log dừng lại ở dòng encoding, port không bao giờ chuyển sang inband/1000base-x. Kết quả nhận được tùy vào firmware. Với bản đã unlock:
cộng thêm một transmit fault do module báo. Với firmware stock thì còn chưa đi xa được tới đó:
Và như đã nói, ép rate cũng chẳng thay đổi gì cả: sau ethtool -s eth2 1000 autoneg off duplex full interface vẫn nằm ở 10 Mbit half duplex.
Còn một kiểu lỗi khác cần loại trừ trên cùng router này, vì nó trông giống nhưng chẳng liên quan gì đến encoding cả. Một HALNy HL-GSFP trên Turris OS HBS 6.2.4 được nhận diện, port thậm chí còn chuyển sang inband/1000base-x, rồi link rớt và eth2 nằm im ở trạng thái down.
Nguyên nhân: cái stick đó tự nó là một máy tính nhỏ. Nó mất khoảng một phút để khởi động firmware riêng của nó, và chỉ sau đó mới trả lời cage bằng bất cứ thứ gì có nghĩa. Cold boot khiến router nhìn vào cage từ rất lâu trước thời điểm đó, nên việc nhận diện thất bại và hộp lặng lẽ rơi về lại magnetics WAN đồng. Kéo dài boot delay là sửa được:
Sáu mươi giây thay vì ba giây mặc định, và một người khác dùng cùng cái stick đã xác nhận điều này. Thêm hai thứ nữa có ích: rút cáp WAN đồng ra và reboot thêm một lần nữa, và login vào chính module để xem nó đang ở trạng thái nào, qua serial ở 38400 8N1 hoặc qua SSH tại 192.168.77.154 port 22666.