Que GPON DFP-34X-2C2 chỉ xuất hiện trong dmesg sau vài chục giây rồi lên link ở 1G
Tôi đang thay ONT của nhà mạng bằng một que GPON dạng SFP trên máy Linux đầu cuối WAN của mình, và que này hành xử chẳng giống transceiver chút nào. Cắm vào là cage im lặng suốt nửa phút hoặc hơn, đủ lâu để hai lần tôi tưởng module đã chết, và khi kernel cuối cùng cũng nhận ra nó thì link lại dừng ở tốc độ gigabit, phá hỏng hoàn toàn mục đích của việc này.
Bench:
- máy router Linux, cage SFP do lớp SFP của kernel điều khiển, kernel mainline
- que GPON ODI DFP-34X-2C2
- một que Huawei MA5671a làm mẫu thứ hai
- một module quang 1G bình thường xuất hiện ngay lập tức trong cùng cage đó, nên bản thân cage không có vấn đề gì
$ dmesg | grep -E 'sfp|Link is'
[ 77.104] sfp sfp-p0: module ODI DFP-34X-2C2 rev sn dc
[ 79.610] eth1: Link is Up - 1Gbps/Full - flow control offĐã thử:
- tháo lắp lại que và để yên vài phút trước khi đụng vào interface, và lần nào cũng phải chờ như vậy, không chỉ lần cắm đầu tiên
- bounce interface sau khi đã phát hiện được, không thay đổi gì về mode đã negotiate
- con MA5671a cũng xuất hiện chậm y như vậy, nên không phải do một mẫu lỗi
Đây đơn giản là cách các que GPON hành xử trên host Linux, hay phía tôi đang làm sai gì đó? Thực sự chuyện gì đang diễn ra giữa lúc cắm vào và lúc phát hiện được ở đây?
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 7
Trước khi bắt đầu đoán mò, có hai điều đáng làm rõ. Thứ nhất, đăng dmesg đầy đủ từ lúc cắm vào trở đi thay vì grep hai dòng. Bạn nói cage nằm sau lớp SFP của kernel và tôi không có lý do gì để nghi ngờ điều đó, nhưng những dòng bạn lọc bỏ mới là những dòng cho thấy module bị probe bao nhiêu lần, cái gì bỏ cuộc ở giữa chừng và mỗi lần thử mất bao lâu.
Thứ hai, bản thân interface tự nhận là làm được gì khi que cuối cùng cũng lên, và 2500baseX có xuất hiện ở đâu trong các mode được quảng cáo không? Và ISP đang cấp cho bạn tốc độ nào ở phía PON, vì nếu đó là gói gigabit thì link bạn đang có là đúng rồi và chẳng có gì phải sửa.
Đáng tiếc là hành vi này đúng như dự kiến, và không phải do host của bạn.
Một que GPON không phải là transceiver có chip EEPROM bên trong. Nó là một máy tính Linux nhỏ chạy trên SoC riêng, nhét vừa vào vỏ SFP, và EEPROM mà host của bạn đọc qua I2C thực ra được hệ thống đó giả lập. Không có gì trả lời trên bus cho tới khi firmware riêng của que đó khởi động đủ xa để phục vụ các page đó, đó là lý do bạn phải ngồi chờ vài chục giây trong khi một module bình thường trả lời ngay lập tức. Sự im lặng trước dòng module của bạn chính là quá trình boot đó.
Nửa còn lại của vấn đề là những gì các page giả lập đó quảng cáo thường xuyên là sai. Interface phía host trên các que này là 2500BASE-X, còn EEPROM lại nói khác, nên lớp SFP tin theo đúng những gì đọc được và dừng ở mode gigabit. Cả hai nửa vấn đề đều được xử lý trong kernel bằng các quirk riêng cho từng module chứ không phải thứ bạn cấu hình được, và con DFP-34X-2C2 OEM này bắt trúng một trong các quirk đó chính vì lý do này.
Mẫu của bạn có rơi vào quirk đó hay không phụ thuộc vào chuỗi vendor và part mà nó báo cáo, và các bản rebadge khác nhau lại khác nhau ở đó, nên hãy so dòng dmesg của bạn với điều kiện mà quirk đó match trước khi cho rằng mình đã được xử lý.
Để nhấn mạnh vì sao cách tiếp cận bằng quirk lại cần thiết: SFF-8472 giả định một thiết bị bộ nhớ thụ động trả lời trong khoảng thời gian I2C thông thường. Không có gì trong đó tính đến một thiết bị cần nửa phút để boot trước khi nói chuyện được, nên một host tuân theo chuẩn hoàn toàn có quyền bỏ cuộc với module đó, hoặc tin vào các bit mode mà nó đọc được sau cùng.
Điểm về rebadge ở trên chính là cái bẫy thực tế. Việc match dựa trên chuỗi vendor và part, nên cùng một que vật lý bán dưới tên khác sẽ trượt hoàn toàn khỏi quirk đó và bạn lại quay về link gigabit mà chẳng rõ lý do. Và đừng xây bất cứ thứ gì phụ thuộc vào việc module có mặt ngay sau khi boot, vì cuộc đua đó ở đây không thể thắng được.
Hy vọng các vendor que sửa lại nội dung EEPROM của họ cũng là quá lạc quan. Khi các vấn đề này được nêu ra, ngay cả các ISP lớn cũng nhận lại rất ít phản hồi từ họ.
Cùng loại vấn đề này cũng xuất hiện trên router gia dụng, nên ít nhất bạn không cô đơn. Chủ sở hữu Archer BE800, BE900 và GE800 cắm que vào cổng combo SFP+ 10G chỉ nhận được 1 Gbit/s thay vì 2,5 Gbit/s mà họ trả tiền, và danh sách chính thức của TP-Link về các que được báo cáo hoạt động trên các cổng đó là ODI DFP-34X-2C2, Huawei MA5671A và Nokia G-010SA, đúng cái danh sách ngắn quen thuộc mà ai cũng gặp.
Lời khuyên đầu tiên ở đó là firmware cộng với tháo lắp lại, và phần tháo lắp lại không phải vô nghĩa, một module chưa cắm khớp hẳn vào đúng là sẽ tụt xuống mode thấp hơn. Các bản beta cuối cùng cũng mở ra cấu hình port, mỗi model một bản riêng:
Với một trong các bản đó trên máy, mode của port SFP trở nên cài đặt được qua telnet, đưa interface xuống trước bằng
ip link set eth1 downrồi các bước tiếp theo.Vẫn chỉ là workaround chứ không phải fix thật, cứ nhớ vậy. Một năm sau vẫn có đúng những phàn nàn đó, và không chỉ về que: một người có một AOC JT-AOC-SFP-15 của JT-COM cắm vào cổng đó, người khác thì một DAC SFP+ 10G passive của Ampcom, và cả hai đều dừng ở 1 Gbit/s.
Đáng biết thêm về kiểu lỗi khác trước khi ai đó đề nghị chuyển que này sang một NIC. Trên OpenWrt 19.07 chạy x86 với một Intel X520 và kmod-ixgbe, một MA5671a đơn giản bị từ chối như một SFP không được hỗ trợ. Đặt allow_unsupported_sfp qua các file config module thông thường ở đó chẳng có tác dụng gì cả, tham số này phải được truyền ngay lúc load module:
Và kể cả vậy driver vẫn từ chối nó, vì ngay từ đầu EEPROM của que này không mô tả một transceiver bình thường, và cái flag đó không che lấp được điều đó. Nếu bạn thực sự chuyển sang NIC, hãy kiểm chứng port bằng một module 1000BASE-T, LX hay SX bình thường trước, không thì bạn sẽ vừa debug card vừa debug que cùng lúc.
Nhưng cẩn thận đừng gộp hai chuyện đó làm một. allow_unsupported_sfp nằm trong ixgbe và quyết định driver đó có chịu điều khiển một optic nhất định hay không, đó là một quyết định khác với quyết định đang được nói tới ở đây. Việc chờ lâu và mode sai đến từ lớp SFP generic đọc các page giả lập rồi đưa kết quả lên phylink, và đó mới là nơi các quirk riêng cho từng module nằm.
Trên một board có cage SFP đúng nghĩa, cờ ixgbe đó không tồn tại và không phải là cách sửa, còn trên một X520 thì danh sách quirk cũng không cứu được bạn. Triệu chứng bề ngoài giống nhau, nhưng lớp bên dưới khác nhau, và nhầm lẫn giữa hai thứ đó là cách người ta hay tự dựng lại driver một cách vô ích.
Nhân tiện vẽ thêm một ranh giới nữa cho rõ: việc làm cho host nhìn thấy que và việc làm cho OLT chấp nhận nó là hai vấn đề độc lập, và vấn đề thứ hai có thể còn tệ hơn nhiều.
Có một trường hợp được ghi lại khá đầy đủ về một Xicom DFP-34X-2C2 được nạp danh tính copy từ một ZTE ZXHN F601 bằng setmac và các truy vấn OMCI, gồm GPON serial, PLOAM password, LOID, hardware serial và firmware string, đủ cả. Que đó ranging tới trạng thái O5 rồi cứ dừng ở đó, không có ONU ID nào được cấp và không có traffic, vì đạt tới O5 chỉ có nghĩa là ranging thành công, trong khi việc upload MIB vẫn phải khớp với đúng profile ONT mà OLT mong đợi. Không ai trong chủ đề đó đưa ra được cách sửa.
Vậy nên khi bạn đã có được 2500BASE-X ở phía mình, đừng cho rằng phần khó đã qua. Ở nơi mà operator gắn chặt một service profile với đúng một model ONT cụ thể, có thể sẽ không có bộ trường copy nào khiến một que bên thứ ba được chấp nhận.