Programmer đọc được SFP+ FTLX8571D3BCV-IT, nhưng ghi thì báo No Acknowledge
Mình giữ một quỹ trao đổi module nhỏ: các node rải rác khắp thành phố, và gần như dưới switch của người khác nào cũng phải recode lại SFP. Với module gigabit thì quy trình đã ổn định từ lâu, còn với hàng chục Gbps thì mình bị kẹt.
Trên bàn có gì:
- programmer có cage cho SFP/SFP+, nguồn 3.3 V
- Finisar FTLX8571D3BCV-IT và FTLX1471D3BCV-IT, cả hai đều đọc được
- Cisco GLC-LH-SM từ kho cũ
- HP J4858B và J4859C
Đọc thì ra ổn định và lặp lại được, cả hai bank trọn vẹn. Ghi thì không đi được ở bất kỳ trường hợp nào:
read A0 0x00-0xFF ... OK
read A2 0x00-0xFF ... OK
write A0 vendor name ... No Acknowledge
write A0 serial (bytes 68-83) ... No AcknowledgeĐã kiểm tra những gì:
- cùng thao tác đó trên SFP gigabit thường bằng đúng programmer này thì qua được, tức là mạch và nguồn đều sống;
- lấy thêm một FTLX8571D3BCV-IT thứ hai, hành vi giống hệt từng byte;
- trên GLC-LH-SM, No Acknowledge bay tới ngay lập tức, trước cả khi kịp đụng vào field vendor.
Vậy tức là không phải do một cá thể cụ thể. Đây là bảo vệ ghi bằng phần cứng ngay trong module, hay trong SFP+ bộ nhớ không còn là EEPROM trần nữa và ghi I2C thông thường đơn giản là không chạm tới được? Và riêng HP J4858B/J4859C thì có ai ghi được bằng programmer thường không, hay đây là ngõ cụt biết trước?
Show original (Русский)
Also available in: Русский
العربية
Deutsch
English
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Türkçe
Tiếng Việt
简体中文
Comments 6
Ở đây lẫn lộn hai cơ chế khác nhau, và chữa chúng theo hai cách khác nhau.
Cái thứ nhất - EEPROM thường với bảo vệ ghi bằng phần cứng. Chip nhớ có chân write protect, và khi chân đó được kéo lên, đọc thì được nhưng ghi thì rớt. Cách mà những người làm việc này sát sao hay khuyên là nối đất chân đó trong lúc flash. Với một số module gigabit thì chỉ cần vậy là đủ.
Cái thứ hai - đúng thứ bạn gặp phải ở hàng chục Gbps. Trong SFP+ dữ liệu thường không nằm trong EEPROM riêng, mà đứng sau vi điều khiển của module: nó tự trả A0 và A2 khi đọc và chỉ chấp nhận ghi qua đúng chuỗi lệnh riêng của nó. Programmer chuẩn không biết chuỗi lệnh đó và nhận No Acknowledge cho mọi lần thử, bất kể bạn nhắm vào field nào. Ở đó không có gì để nối đất cả.
Cái thực sự giúp vượt qua cage: hàn dây thẳng vào chân 4 và 7 của module, tức là vào đường I2C, bỏ qua connector của programmer. Theo phản hồi, sau đó một phần module vốn im lặng trong cage sẽ ghi được. Cách này thô bạo, tay cần vững, và module sau đó sống chết bạn tự chịu trách nhiệm.
HP là chuyện riêng. Programmer chuẩn không ăn được chúng, ở đó cần xử lý riêng, và với J4858B/J4859C bằng mạch thông thường thì mình sẽ không kỳ vọng thành công. Nếu mục tiêu chỉ là có một module chạy được trong switch của người khác, rẻ hơn là đừng hành hạ HP, mà lấy một module có bộ nhớ trần rồi đổ nguyên image của vendor vào: trong 256 byte dump thì 128 byte đầu có ý nghĩa, phần còn lại là dự trữ của nhà sản xuất.
Dĩ nhiên không vendor nào hỗ trợ kiểu recode này cả: cầm module đã flash lại thì chẳng có gì để mang đi support.
Làm rõ vài chỗ, không thì chỉ đoán mò thôi. No Acknowledge bay tới ngay ở địa chỉ thiết bị hay đã sau byte dữ liệu đầu tiên rồi? Nhìn log của programmer thường thấy được điều này. Và programmer của bạn là loại gì - thiết bị đóng gói sẵn hay đồ tự chế với mạch riêng? Cái này quyết định nên kỳ vọng gì từ 3.3 V trên cage.
Còn tò mò hành vi lúc cấp nguồn: lỗi có giống nhau ngay sau khi lắp module và sau khi nó đã có điện được vài phút không? Và cả bốn loại có hành xử giống nhau không hay Finisar với HP khác nhau: HP thường có nguyên nhân lỗi riêng của nó, nên tách ra khỏi phần còn lại ngay từ đầu.
Báo cáo kết quả. Đã hàn vào đường I2C thẳng tới chân 4 và 7, bỏ qua cage. Finisar chạy được: FTLX8571D3BCV-IT ghi xong và đọc lại xác nhận đúng, FTLX1471D3BCV-IT cũng vậy. GLC-LH-SM hết báo No Acknowledge và ghi bình thường.
HP thì vẫn chưa chịu thua. J4858B ghi thì hình thức là nhận, nhưng sau khi sửa xong module bị switch từ chối, J4859C cũng y như vậy. Nên với mình câu hỏi coi như xong một nửa: Finisar và Cisco giờ ghi được, HP thì để sang một bên chờ dịp tốt hơn.
Với HP thì bẫy sâu hơn cả bảo vệ ghi, nên kết quả của bạn là điều nên đoán trước được. Trên J4858B, khi sửa byte 68-83, tức là serial number, checksum ở byte 124-127 thay đổi theo, và module sau đó bị từ chối. Đây không phải CC_BASE và CC_EXT kiểu MSA, tính mấy cái đó không khó, mà là một checksum riêng của vendor nằm trong bốn byte cuối của A0. Thuật toán thì công khai vẫn chưa ai mổ xẻ ra được, dù có vọc bao nhiêu.
J9150A cũng cùng câu chuyện đó. Còn ở các module HP và Aruba mới hơn thì họ bỏ hẳn checksum tĩnh để chuyển sang cơ chế hỏi-đáp, HPIDv2, và ở đó programmer về nguyên tắc là vô dụng. Nên "ghi được nhưng không được chấp nhận" chính xác là kết quả lẽ ra phải xảy ra.
Vì bạn có cả một dàn chứ không phải một module, mình nói về công cụ. Mình dùng UACC-SFP-WIZARD của Ubiquiti cho việc recode Huawei S5731 và S6730 với cả HP 6120XG - làm programmer giá rẻ thì nó khá ổn. Chỉ có điều với chính module Ubiquiti thì có nhiều danh sách password truyền tay nhau, dạng như 0x00001011, SFPX, QSFP, không có chúng thì một số module không mở ra để ghi được. Về image thì mình đang dùng FTLX8571D3BCV và FTLX8574D3BCV, ít hơn là SNR-SFP+W73-3 và W37-3.
Mình chỉnh lại khái quát ở trên một chút, để không ai vội vơ mỏ hàn quá sớm: không phải SFP+ nào cũng giấu bộ nhớ sau vi điều khiển. Chỗ mình, FTLX8574D3BCV và một cặp SNR-SFP+W73-3 ghi được bằng programmer thường trong cage, không cần hàn hiếc gì. Nên trước tiên nên kiểm tra đúng cá thể cụ thể, rồi mới tính đến đường vòng.
Nối đất chân write protect, tiện thể nói luôn, cũng không phải công thức vạn năng: trên module có vi điều khiển thì nó chẳng đổi được gì, lỗi ở đó không đến từ bộ nhớ mà từ firmware của bộ điều khiển. Thao tác này chỉ có ý nghĩa ở nơi có EEPROM riêng trần trụi thật sự, và phải làm trên module đã ngắt điện, không thì rất dễ biến nó thành cục gạch thay vì module.