ODI DFP-34X-2C2 trong một Turris Omnia chỉ lên link ở 1000base-x, ethtool không nhận speed 2500
Tôi đã đổi ONU của ISP sang một stick GPON ODI DFP-34X-2C2 trong Turris Omnia của mình, để sợi fibre kết thúc ngay tại router thay vì ở một hộp khác trên kệ. Phần đó thì ổn: line đã đăng ký, traffic chạy, không có gì để phàn nàn. Vấn đề nằm ở tốc độ. Nó không bao giờ vượt quá 1Gbps, mà 2.5G mới chính là lý do tôi mua con stick này.
- Turris Omnia, TurrisOS 6.0.4
- stick GPON ODI DFP-34X-2C2 trong cage SFP, eth2
- WAN đồng đã rút, cage sở hữu port
Kernel báo gì sau khi boot, và chuyện gì xảy ra khi tôi cố ép tốc độ:
# dmesg | grep mvneta
eth2: switched to inband/1000base-x link mode
# ethtool -s eth2 speed 2500
Invalid argumentethtool eth2 khi link đang up hiện module là 1000baseX/Full và không gì cao hơn, và sự từ chối ở trên là ethtool đang nói với tôi rằng speed 2500 không thể được advertise.
Đã thử cho đến nay:
- telnet vào stick và set tốc độ từ chính shell của nó; nó nhận lệnh rồi vẫn quay về 1Gbps
- reboot cả khi có và không có WAN đồng gắn vào
- lục qua dmesg tìm bất kỳ điều gì về việc MAC được đề nghị 2.5G, không có gì cả
Đây là router đang giới hạn port, hay là do chính module? Và có gì ở phía host có thể khiến eth2 lên được ở 2500base-x với con stick này không?
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 5
Cái trần ở đây là chính module, không phải con Omnia.
Cái mà host negotiate dựa vào chính là những gì EEPROM của module khai báo nó làm được, vì tại thời điểm probe thì con chip đó là thứ duy nhất cage có để dựa vào. Trên con stick đó nó được code cho 1000Mbps. Nên port được thiết lập là inband/1000base-x, không có mode 2500base-x nào để phylink đưa ra, và ethtool từ chối speed 2500 vì chẳng có gì để advertise nó cả. Không có công tắc nào phía host lách qua được chuyện đó: ethtool chỉ có thể yêu cầu các mode mà port đã được báo là tồn tại. Cái shell bên trong stick cấu hình phía PON của module, chứ không phải cái cage advertise về phía MAC, và đó chính xác là lý do vì sao thay đổi qua telnet của bạn bốc hơi và bạn quay về 1Gbps.
Vậy còn lại hai lựa chọn thực sự: cho code lại module để nó advertise 2.5G, hoặc thay nó bằng một con đã sẵn làm được điều đó. Nếu đi theo hướng code lại, hãy giữ sẵn một con dự phòng trên bàn. Bạn đang viết lại trang định danh mà host tin tưởng, và một byte sai ở đó sẽ khiến cage ngừng nhận diện module đó luôn. Cũng nên tách rõ hai tốc độ trong đầu: cái phía PON mang lại và cái link SFP-to-MAC negotiate là hai con số khác nhau, nên hãy tính rõ bạn thực sự được lợi gì trước khi bỏ tiền vào việc này.
Trước khi đổ lỗi cho stick, kiểm tra xem máy đang boot bằng device tree nào. Cái cage trên một Omnia không phải là một interface phụ thêm: nó cùng với nửa WAN kim loại là hai mặt trước đấu vào đúng một eth2, và chỉ một trong hai được nối thông tới MAC tại một thời điểm. Cái nào được nối thì tùy vào dtb mà kernel nạp lúc boot. Nên xem thử /boot/dtb đang trỏ vào đâu: nếu không phải armada-385-turris-omnia-sfp.dtb, thì bạn đang nhìn vào phía đồng và các con số chẳng có ý nghĩa gì.
Cũng nên đăng toàn bộ dmesg | grep -i sfp, chứ không chỉ dòng mvneta. Cái kernel đọc được từ module tại thời điểm probe mới là phần đáng chú ý ở đây, và nó thường giải quyết câu hỏi chỉ trong một dòng.
dtb đã là bản SFP rồi, tôi đã symlink armada-385-turris-omnia-sfp.dtb ngay từ lúc đầu cắm stick vào, nếu không thì chẳng có gì lên cả. Cage sở hữu eth2 và WAN đồng vẫn để rút.
dmesg | grep -i sfp cho thấy module được nhận diện rồi đến đúng dòng tôi đã đăng, eth2 switched to inband/1000base-x link mode. Không có gì về 2500 ở bất kỳ đâu. ethtool eth2 báo 1000baseX/Full trong khi link đang up và chạy traffic, và ethtool -s eth2 speed 2500 vẫn quay về Invalid argument, nên nó sẽ không advertise 2500 chút nào. Set tốc độ qua telnet bên trong stick hành xử y như trước, nó chấp nhận lệnh rồi lại rơi về 1Gbps.
Câu chuyện liền kề trên cùng board, phòng khi có ai đó lạc vào đây với một stick hoàn toàn không lên chứ không phải kẹt ở 1G. HALNy HL-GSFP trong một Omnia chạy Turris OS HBS 6.2.4: kernel nhận diện được nó, port thậm chí còn chuyển sang inband/1000base-x, rồi link rớt và eth2 không bao giờ lên.
Trường hợp đó không phải vấn đề EEPROM. Có nguyên một hệ điều hành nhỏ sống bên trong con stick đó, và nó cần khoảng một phút cho riêng mình trước khi ở trạng thái có thể trả lời host. Ở một lần cold start, router đã probe cage và bỏ cuộc từ rất lâu trước thời điểm đó, nên port quay về lại phía magnetics đồng. Kéo dài delay của U-Boot đã sửa được ở đây:
Mặc định là 3 giây; ở mức 60 thì stick đã lên xong trước khi kernel kịp quay lại probe cage. Rút WAN đồng ra và reboot thêm lần nữa cũng giúp việc nhận diện. Và nếu bạn có bao giờ cần nhìn vào bên trong một stick, cổng serial của nó là 38400 8N1.
Đồng ý với chẩn đoán, kèm một lưu ý cho bất kỳ ai lạc tới đây với triệu chứng tương tự. Không phải mọi trường hợp "không lên được 2.5G" trên board này đều do module. Từng có một bản snapshot OpenWrt nơi code phylink validate chung bị backport vào, và nó làm hỏng hẳn cái cage của Omnia: ethtool vẫn advertise 2500baseX/Full nhưng lại báo Link detected: no. Revert bản backport đó đưa port trở về đúng như trước, ethtool đọc Link detected: yes, 2500Mb/s full duplex, và một pull request sau đó đã xử lý ổn thỏa bản backport đó ở upstream.
Dấu hiệu nhận biết nằm ở những gì ethtool liệt kê là supported và advertised. Nếu 2500baseX/Full có trong đó mà link đơn giản là không chịu lên, hãy nhìn vào kernel và phylink sau lần upgrade image gần nhất của bạn, chứ đừng nhìn vào optic. Còn nếu, như ở đây, port chỉ biết mỗi 1000baseX vì đó là điều module tự khai báo về bản thân nó, thì không phần mềm host nào triệu hồi được cái mode đó. Đó chính là byte nominal bit rate trong EEPROM đang làm đúng những gì SFF-8472 quy định.