Cần tính lại những checksum EEPROM nào sau khi sửa vendor name và PN trong image SFP

Programmer của bạn đang làm đúng cái mà tool nền CH341 vẫn hay làm, tức là không làm gì cả. Chúng ghi đúng những byte bạn đưa và không bao giờ đụng vào trường checksum. Programmer của vendor thì tự tính lại khi ghi, đó là lý do những ai chỉ dùng loại đó không bao giờ gặp chuyện này và tin rằng cả chủ đề này chỉ là tưởng tượng.

Có hai điều đáng làm rõ trước khi viết tool riêng. Thứ nhất, cái gì đọc lại image sau khi ghi - cùng một tool đã ghi, hay một thứ độc lập? Một reader phục vụ bạn từ cache riêng của nó sẽ vui vẻ hiện ra một byte chưa từng thực sự nạp vào chip. Thứ hai, bạn có tự tính tổng trên các byte 0 đến 62 của image đã sửa rồi đối chiếu với byte 63 không, hay chỉ so byte 63 với dump gốc? “Không đổi” và “đúng” không phải cùng một phép kiểm tra, và ghi chú của bạn mới chỉ cho thấy phép đầu tiên.

Cũng nên nói rõ host nào đang từ chối. Có host chỉ đọc trường định danh mà không kiểm tra gì, có host lại kiểm tra chặt và loại module ngay khi checksum sai lệch. Cùng một image, hai kết luận khác nhau.

Có hai checksum, và chúng chỉ là tổng 8-bit đơn giản, không có CRC nào ở đây cả.

• CC_BASE nằm ở byte 63, là 8 bit thấp của tổng các byte từ 0 đến 62
• CC_EXT nằm ở byte 95, bao phủ các byte từ 64 đến 94

Vendor name và vendor PN đều nằm trong vùng base, nên việc sửa của bạn làm CC_BASE sai trong khi CC_EXT vẫn đúng một cách chính đáng. Còn sửa serial number và date code thì lại đụng vào vùng extended, khi đó byte 95 mới là thứ lệch. Tính lại mỗi checksum chỉ mất hai dòng lệnh trên buffer: cộng tổng dải byte, mask với 0xFF, lưu vào byte tổng.

Nếu không muốn tự làm bằng tay thì đã có tool sẵn. py-sfp-eeprom dựng và kiểm tra image EEPROM từ Python (python3 -m sfp_eeprom), còn sfppi chạy trên Raspberry Pi, kiểm tra checksum và đề nghị tự sửa luôn. Dùng cái nào cũng là thói quen tốt hơn hex editor cộng tính nhẩm, vì kiểu lỗi này âm thầm - module đọc lại đúng y những gì bạn đã ghi và chỉ có host là kêu ca.

Tính đúng hai checksum MSA là điều kiện cần, còn có đủ hay không thì còn tùy đang cắm vào port của ai.

Cisco là ví dụ kinh điển: kiểm tra định danh không chỉ dừng ở các chuỗi text. Nhiều năm trước có người đã tìm ra rằng giá trị mà một module mã hóa kiểu Cisco mang theo có thể tái tạo chỉ bằng xxd -r -p | md5sum, đưa vào byte mã vendor rồi đến các byte tên. Trong các dump đó, mã và tên gắn chặt với nhau - Finisar đứng sau 02, Methode đứng sau 0E. Để hai thứ đó lệch nhau là một Catalyst 2960X lại nhả module ra, có chạy lệnh unlock hay không cũng vậy.

Đó thường là lý do một dump copy từ module đang chạy tốt lại ngừng hoạt động ngay khi ai đó dán một vendor string khác vào. Checksum vẫn ổn, chỉ là định danh không còn tự nhất quán nữa.

Đính chính nhỏ cho kiểu suy nghĩ “sửa hai checksum là xong”: điều đó đúng với các trường MSA, không đúng với mọi khái niệm “image hợp lệ” của từng vendor.

HP là ví dụ ngược lại kinh điển. Sửa serial number trong một image J4858B, byte 68 đến 83, thì byte 124 đến 127 của A0 cũng đổi theo - một checksum riêng của vendor nằm ngoài các byte CC_BASE và CC_EXT của MSA. Chuyện đó từng được bàn rất nhiều mà chưa ai công bố thuật toán, người ta chỉ xác nhận các byte đó có ý nghĩa rồi chủ đề dừng ở đó. Câu chuyện tương tự được báo cáo quanh J4859C và J9150A. Về sau thiết bị HP và Aruba chuyển sang cơ chế challenge response (HPIDv2), thứ hoàn toàn không thể giả trong một EEPROM.

Vậy nên trước khi đầu tư vào tooling, hãy xác định host đích thực sự kiểm tra gì: hai tổng cộng dồn với host thông thường, một định danh tự nhất quán với Catalyst, và ở một số part của HP là một trường không có tài liệu mà bạn sẽ không tái tạo được.