IC-prog SFP dump'ının 256 byte'ını veriyor, ama ikinci yarı birincinin kopyası, A2 sayfası okunmuyor (HP 2530-24G)
Küçük bir operatörün ağına bakıyorum, düzenli olarak ucuz modülleri HP için yeniden flashlıyorum. Görev sıradan: switch'in onları homurdanmadan kabul etmesi için Çin malı 1.25G WDM'lere orijinal modülün imajını yüklemek. Donör J4859C, hedef donanım HP 2530-24G J9776A.
Masada olanlar:
- HP 2530-24G J9776A switch
- OptiCin ve Fiberstore modülleri, 1.25G WDM
- mini-USB NAG programlayıcı
- Windows altında IC-prog, onun üzerinden okuyup yazıyorum
Dump 256 byte olarak alınıyor, ama ikinci yarı birinciyle byte byte aynı:
IC-prog, 0x00-0x7F: прочитано
IC-prog, 0x80-0xFF: тот же самый блок, байт в байт
на части модулей при чтении: No Acknowledge receivedZaten denediklerim:
- modülü yeniden taktım, soket kontaklarını temizledim, mandalı değiştirdim
- farklı partilerden üç modül denedim, tablo aynı
- USB portunu, kabloyu ve makineyi değiştirdim, hiçbir şey değişmedi
Bana DDM ve servis byte'larının olduğu ikinci sayfa lazım, ve onu basitçe göremiyorum. Bu bir IC-prog sınırlaması mı, programlayıcının eğri bir kartı mı, yoksa modüllerin kendisi mi böyle davranıyor?
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 7
Burada iki bağımsız sorun var, ve ikisi de modüllerde değil.
Birincisi IC-prog'un kendisi. Doğrusal bir adresleme modeli var, sayfa değiştirmeyi bilmiyor ve A2'ye ilke olarak erişemiyor. Dump'ın ikinci yarısında gördüğün şey, ikinci kez okunan aynı A0. Bir hata göstermeyecek, çünkü onun bakış açısından her şey dürüst.
İkincisi kart. Bu mini-USB programlayıcıda VccR (pin 15), SFF-8431'e göre serbest kalması gerekirken +5 V'a oturtulmuş, artı güç ve toprak, bir kısım modülün normal moda geçmemesine yol açacak şekilde döşenmiş.
No Acknowledge receivedde buradan geliyor - hepsinde art arda değil, bu döşemeyi sevmeyenlerde.Normal çalışan:
i2cdump -y 3 0x50vei2cdump -y 3 0x51, her iki sayfayı da okuyup yazan açık bir Python scripti var.Kriter basit: 0x51 yanıt vermeye başlar başlamaz, gerisi araçla mücadele değil modülün belleğiyle sıradan bir çalışma.
Yazılımla donanımı ayır, yoksa akşama kadar tahmin yürütürsün. Herhangi bir Linux al ve modülün ikinci adreste hiç yanıt verip vermediğine bak:
Bus numarasını kendine göre koy. 0x50 okunuyor ama 0x51 susuyorsa, artık soru neyle dump'a baktığın değil, modüle normal gücün ulaşıp ulaşmadığı. Ve aynı programlayıcının kesin çalışan donör J4859C'den ne verdiğini söyle: onda da ikinci sayfa açılmıyorsa, ucuz modüllerin bununla bir ilgisi yok, yazılım artı kart kombinasyonunu kazmak gerek.
Donörü ilk iş olarak denedim: aynı sokette ve aynı IC-prog'da çalışan J4859C tam olarak aynı tabloyu veriyor - 256 byte, ikinci yarı birincini tekrarlıyor. Demek ki mesele ucuz modüllerde değil. Bir de Linux altında adaptör üzerinden kontrol ettim:
Aynı modülde orijinal yardımcı program
No Acknowledge receivedveriyor, IC-prog ise sessizce ilk sayfanın kopyasını gösterip her şey yolundaymış gibi yapıyor. Hedef modüller OptiCin, imajı tam olarak bu J4859C'den alıyorum.Yazmanın kendisi hakkında ekleyeyim. 256 byte'lık dump'ta ilk 128 byte anlamlı, ötesi üretici bölgesi, ona genelde hiç dokunmaya gerek yok. HP için J4858C ve J4859C'den imaj yüklüyoruz, WDM için birkaç kez sıradan bir LX imajı yetti: switch modülü kabul etti ve dalga boyuna bakmadı.
Ama her şey yazılmıyor. 3Com 3CSFP91 ve 3CSFP92'de, markalı Allied Telesis'te olduğu gibi, yazma hiç gitmedi: normal okunuyor, ama yazma uygulanmıyor - WP kilitli. Yani programlayıcıyı değiştirdikten sonra A2 okunuyor da yazma sessizce hiçliğe gidiyorsa, nedeni yazılımda arama.
«Gerisi belleğe sıradan bir çalışma» konusunda bir çekince koyayım. Sıradan olması her yerde geçerli değil. Modüllerin bir kısmı EEPROM bile değil: Medick SFP-10G-BX'te A0/A2'yi emüle eden ve parola isteyebilen veya bir challenge'a yanıt verebilen bir C8051F392 mikrokontrolörü var. Dışarıdan tam olarak yazma anına kadar normal bir bellek gibi görünüyor. Başıma gelen en ağır durum, anahtarlı HP/Aruba'daki interaktif EEPROM, orada hazır bir yardımcı program olmadan yapacak bir şey yok.
Ve adaptörü kendin topluyorsan, pinleri karıştırma: TX_Disable pin 3, Mod_Abs pin 6, VeeR pin 9. Tanıdıklardaki «okunamayan» modüllerin yarısı, vendor korumasından değil eğri toplanmış bir soketten çıktı.
Şu anda kullanılanlardan: SNR SFP Writer, SFPTotal Plus serisi ve CH341 üzerine ev yapımları - genelde bu SFP, XFP, GBIC ve QSFP için soketli sade bir kart, bazen 3D baskı bir kasada. Evrensel yazılım yok, her vendor için kendi yardımcı programı, imajlar firmware veritabanlarından ve konuyla ilgili forumlardan çekiliyor.
Donanımdan daha pahalıya mal olan iki nokta. Birincisi: birçok modülde 4 byte'lık bir parola var, çoğu uzun zaman önce yayınlanmış, ama yanlış tahmin edersen ucuz olmayan bir modülden tuğla çıkarırsın. İkincisi: belleğe dalmadan önce modülün gerçekten hayatta olduğundan emin ol. A0h/A2h'den sıcaklık, gerilim, bias akımı ve TX/RX, Junos'ta
show interfaces diagnostics opticsya da Huawei'dedisplay interface transceiver, sonra mandalların, kontakların ve lenslerin temizlenmesi, sonra kesin çalışan biriyle değiştirme. «Ölü» modüllerin bir kısmı bundan sonra hiçbir flash işlemi olmadan canlanıyor, yükü de ancak ondan sonra iperf3 üzerinden kontrol ediyorsun.Sonuç olarak rapor veriyorum. CH341 üzerine bir kart topladım, Linux altında 0x51 hemen yanıt verdi, ikinci sayfa tamamen okunuyor, ilk 128 byte'ın hiçbir kopyası yok. J4859C imajını OptiCin'e yükledim, HP 2530-24G J9776A modülü sessizce kabul etti, DDM makul değerler gösteriyor, bir gün boyunca yük altında hatasız çalıştı.
IC-prog'u kaldırdım, bir daha ayartılmayayım diye. Yanda duran 3Com 3CSFP91 gerçekten yazılmıyor: okunuyor ama yazma uygulanmıyor, yani WP konusunda her şey örtüşüyor. Teşekkürler, soru kapandı.