IC-prog trả về dump SFP 256 byte, nhưng nửa sau là bản sao của nửa đầu, không đọc được trang A2 (HP 2530-24G)
Mình quản lý mạng của một nhà cung cấp nhỏ, thường xuyên phải nạp lại firmware cho module giá rẻ để chạy được trên HP. Việc quen thuộc: nạp vào module WDM 1.25G Trung Quốc bản image của module chính hãng, để switch chấp nhận chúng mà không càu nhàu. Donor là J4859C, phần cứng đích là HP 2530-24G J9776A.
Những gì có trên bàn:
- Switch HP 2530-24G J9776A
- Module OptiCin và Fiberstore, WDM 1.25G
- Bộ nạp mini-USB NAG
- IC-prog trên Windows, mình đọc và ghi qua nó
Dump lấy được 256 byte, nhưng nửa sau trùng khớp với nửa đầu từng byte một:
IC-prog, 0x00-0x7F: прочитано
IC-prog, 0x80-0xFF: тот же самый блок, байт в байт
на части модулей при чтении: No Acknowledge received
Những gì mình đã thử:
- cắm lại module ở vị trí khác, lau sạch tiếp điểm trong socket, đổi chốt cài
- chạy qua ba module từ các lô khác nhau, tình trạng vẫn y hệt
- đổi cổng USB, cáp và cả máy, không có gì thay đổi
Mình cần trang thứ hai, nơi chứa DDM và các byte dịch vụ, mà mình đơn giản là không thấy nó đâu. Đây là giới hạn của IC-prog, do mạch nạp bị lỗi, hay chính các module hoạt động kiểu đó?
Comments 7
Ở đây có hai lỗi độc lập, và cả hai đều không nằm ở module.
Thứ nhất - chính IC-prog. Nó có mô hình địa chỉ tuyến tính, không biết chuyển trang và về nguyên tắc không thể chạm tới A2. Cái bạn thấy ở nửa sau của dump chính là A0 đó, được đọc lần thứ hai. Nó sẽ không báo lỗi, vì theo góc nhìn của nó thì mọi thứ đều đúng đắn.
Thứ hai - mạch nạp. Trên bộ nạp mini-USB này, VccR (chân 15) bị đấu vào +5 V, trong khi theo SFF-8431 nó phải để trống, cộng thêm nguồn và đất được đi dây theo kiểu khiến một số module không vào được chế độ bình thường. Từ đó mà ra
No Acknowledge received- không phải trên tất cả mọi module, mà chỉ trên những module không ưa cách đi dây này.Cái gì hoạt động bình thường:
i2cdump -y 3 0x50vài2cdump -y 3 0x51, có sẵn script Python mã nguồn mở đọc và ghi được cả hai trang.Tiêu chí đơn giản thôi: ngay khi 0x51 bắt đầu phản hồi, phần còn lại là công việc bình thường với bộ nhớ của module, chứ không phải cuộc chiến với công cụ nữa.
Tách riêng phần mềm và phần cứng ra, không thì bạn sẽ đoán mò tới tối. Lấy một máy Linux bất kỳ và xem module có phản hồi ở địa chỉ thứ hai hay không:
Số bus thì thay bằng số của bạn. Nếu 0x50 đọc được mà 0x51 im lặng - vấn đề không còn nằm ở việc bạn xem dump bằng gì nữa, mà ở việc nguồn điện bình thường có tới được module hay không. Và cho biết luôn là với cùng bộ nạp đó, con J4859C donor chắc chắn còn sống trả về gì: nếu trang thứ hai của nó cũng không mở được, thì module giá rẻ chẳng liên quan gì ở đây cả, phải đào sâu vào tổ hợp phần mềm cộng mạch nạp.
Mình đã chạy thử donor đầu tiên: con J4859C còn sống trong cùng socket và cùng IC-prog cho ra đúng bức tranh y hệt - 256 byte, nửa sau lặp lại nửa đầu. Vậy là vấn đề không nằm ở module giá rẻ. Mình cũng kiểm tra thêm trên Linux qua bộ chuyển đổi:
Tiện ích gốc trên chính module này báo
No Acknowledge received, còn IC-prog thì lặng lẽ hiển thị bản sao của trang đầu và làm ra vẻ mọi thứ đều ổn. Module đích là OptiCin, mình lấy image đúng từ con J4859C này.Bổ sung thêm về chuyện ghi. Trong dump 256 byte, chỉ 128 byte đầu là có ý nghĩa, phần còn lại là vùng của nhà sản xuất, thường có thể không đụng vào luôn. Với HP bọn mình nạp image từ J4858C và J4859C, với WDM vài lần chỉ cần image LX thường là đủ: switch chấp nhận module và không để ý tới bước sóng.
Nhưng không phải cái gì cũng ghi được. Trên 3Com 3CSFP91 và 3CSFP92, cũng như trên hàng Allied Telesis chính hãng, việc ghi hoàn toàn không chạy: đọc bình thường, nhưng ghi thì không được áp dụng - WP bị khóa. Nên nếu sau khi đổi mạch nạp mà A2 đọc được nhưng ghi thì lặng lẽ trôi vào hư không, hãy tìm nguyên nhân ở chỗ khác chứ không phải phần mềm.
Mình xin nói rõ thêm về chuyện "phần còn lại là công việc bình thường với bộ nhớ". Bình thường thì không phải ở đâu cũng vậy. Một số module hoàn toàn không phải EEPROM: trong Medick SFP-10G-BX có một vi điều khiển C8051F392, giả lập A0/A2 và biết đòi mật khẩu hoặc trả lời challenge. Nhìn từ ngoài nó giống bộ nhớ bình thường cho tới đúng thời điểm ghi. Trường hợp nặng nhất mình từng gặp là EEPROM tương tác của HP/Aruba có khóa, ở đó không có tiện ích chuyên dụng thì chịu, không làm gì được.
Và nếu tự lắp adapter, đừng nhầm chân: TX_Disable - chân 3, Mod_Abs - chân 6, VeeR - chân 9. Một nửa số module "không đọc được" ở chỗ người quen mình hóa ra là do socket lắp sai, chứ không phải do vendor khóa.
Trong số những gì đang được dùng hiện nay: SNR SFP Writer, dòng SFPTotal Plus và hàng tự chế trên CH341 - thường chỉ là một mạch với socket cho SFP, XFP, GBIC và QSFP, đôi khi nằm trong vỏ in 3D. Không có phần mềm vạn năng, mỗi vendor một tiện ích riêng, image thì kéo từ các kho firmware và các forum chuyên ngành.
Hai điều đáng giá hơn cả phần cứng. Thứ nhất: nhiều module có mật khẩu 4 byte, phần lớn đã được công bố từ lâu, nhưng sai một phát là biến một module không hề rẻ thành cục gạch. Thứ hai: trước khi đụng vào bộ nhớ, hãy chắc chắn module còn sống đã. Nhiệt độ, điện áp, dòng bias và TX/RX từ A0h/A2h,
show interfaces diagnostics opticstrên Junos hoặcdisplay interface transceivertrên Huawei, sau đó lau chốt cài, tiếp điểm và thấu kính, rồi thay bằng một cái chắc chắn còn hoạt động. Một số module "chết" sau đó sống lại mà chẳng cần nạp lại firmware gì cả, còn tải thì kiểm tra sau qua iperf3.Báo cáo kết quả cuối cùng. Mình đã lắp một mạch trên CH341, trên Linux 0x51 phản hồi ngay, trang thứ hai đọc được trọn vẹn, không còn bản sao của 128 byte đầu nữa. Nạp image J4859C vào OptiCin, HP 2530-24G J9776A chấp nhận module không một lời phàn nàn, DDM hiển thị giá trị hợp lý, chạy tải suốt một ngày đêm không lỗi.
Mình đã gỡ IC-prog để khỏi bị cám dỗ dùng lại. Con 3Com 3CSFP91 nằm lăn lóc bên cạnh thì đúng là không ghi được: đọc bình thường, còn ghi thì không được áp dụng, nên chuyện WP là khớp hết. Cảm ơn mọi người, câu hỏi coi như đã xong.