Wat de Catalyst 2960X berekent uit de SFP-dump: vendorcode, naam en MD5, en waarom een gekopieerde dump niet wordt geaccepteerd
Ik onderhoud een providernetwerk, het modulenpark is gemengd, dus moet ik regelmatig modules klaarmaken voor specifieke switches. Ik wil eindelijk de mechaniek van de controle begrijpen, in plaats van dumps op goed geluk te proberen.
Waar ik mee werk:
- Cisco Catalyst 2960X-24PS-L, de meest kieskeurige van het park
- QTECH QSW-3750-28TX-AC en D-Link DGS-3420, daarop komen dezelfde modules rustig omhoog
- modules SNR-SFP+SR en SFP-10G-BX
In de dump van een module die op de Catalyst geaccepteerd wordt, zie ik vooraan de byte van de vendorcode en daarna de naam in ASCII:
0E 43 49 53 43 4F ...Wat ik geprobeerd heb: ik heb een dump gemaakt van een module die op de C2960X-24PS-L wel linkt, en in een andere module alleen de vendornaam uit die dump teruggeschreven. Op QTECH en D-Link komt daarna alles omhoog, maar de Catalyst accepteert die module niet, ook al komen de aangepaste bytes exact overeen met de donor.
Vandaar de vraag over hoe de controle in elkaar zit. Wat berekent Cisco precies en over welke bytes, waar in de module ligt het resultaat, en waarom is een teruggeschreven vendornaam uit een werkende dump daarvoor niet genoeg? Mij gaat het om de logica, de rest zoek ik zelf verder uit.
Comments 6
De mechaniek erachter is simpel en al lang uitgezocht. Er wordt niet één los veld gecontroleerd, maar een koppel: de byte van de vendorcode plus de bytes van de vendornaam. Over die reeks wordt een MD5 berekend, en het resultaat ligt in de module zelf; de switch berekent hetzelfde en vergelijkt.
Reproduceerbaar met standaardtools, niets speciaals nodig:
Je vult je eigen code en je eigen vendornaam in en krijgt de waarde die in de module moet liggen. Van de codes die echt in dumps voorkomen: 02 is Finisar, 0E is Methode, 11 duikt regelmatig op, maar van wie die is, is nooit opgehelderd. Als het paar code-naam klopt en de hash ermee overeenkomt, komt de module op de C2960X-24PS-L erdoor.
Even op het vorige: laat zien wat er echt in de ontvangende module staat. Welke byte van de vendorcode is blijven staan en welke naam staat ernaast? Volgens je beschrijving heb je de naam overgezet maar de code of de hash zelf van de originele module laten staan, en dan loopt de koppeling uit elkaar en wijst de Catalyst hem volkomen terecht af. Check alle drie de dingen tegelijk, niet alleen het veld dat in de switchoutput zichtbaar is.
Gecheckt, het klopt allemaal met jullie versie. In de donor staat 0E en daarna CISCO, en in de ontvanger heb ik inderdaad de naam teruggeschreven, maar de vendorcode is de originele gebleven, en de hash ook nog de oude. Beide combinaties door xxd -r -p en md5sum gehaald: bij de donor komt de waarde overeen met wat in de module ligt, bij mijn handmatig samengestelde niet.
Dus je moet de hele koppeling overzetten, niet veld voor veld. Nu is in elk geval duidelijk waar je moet kijken en wat je moet vergelijken voordat je de module in de poort zet.
Een belangrijk gevolg dat mensen steeds vergeten: als vendorcode en naam niet kloppen, komt de module niet door de Catalyst, zelfs niet als op de switch niet-ondersteunde modules zijn toegestaan. Precies daarom werken andermans dumps maar bij de helft van de keren - ze zijn maar gedeeltelijk aangepast, en de controle kijkt naar de koppeling.
Daaruit volgt een praktische conclusie over de omvang: in een 256-byte dump zijn de eerste 128 bytes significant, daarna begint de zone van de fabrikant. Het hele image meeslepen is niet nodig, maar de eerste helft moet je wel in samenhang overzetten, inclusief velden die je met het blote oog niet in de switchoutput ziet.
Trouwens, met een dump alleen kom je er niet altijd. In de Medick SFP-10G-BX zit geen geheugen maar een microcontroller, de C8051F392: die emuleert A0 en A2 en kan best een wachtwoord of een vendor-challenge vasthouden. Daar kun je de koppeling tot op de byte kloppend maken - van buitenaf wordt hij gewoon niet geaccepteerd. Van de gereedschappen die ik echt gebruik: SNR SFP Writer en SFPTotal Plus, bij collega's nog zelfbouw op basis van CH341.
Een kleine correctie, om mensen die hier later terechtkomen niet op het verkeerde been te zetten. Deze MD5 heeft niets te maken met de MSA-controlesommen: CC_BASE en CC_EXT uit SFF-8472 zijn een simpele optelling van bytes en in een handomdraai opnieuw te berekenen. De vendorcontrole zit daar bovenop, met eigen regels, en wijst de module af precies op het moment dat de MSA-sommen kloppen - vandaar het gevoel dat de dump goed is en de module toch niet geaccepteerd wordt.
Cisco is hier trouwens verre van het ergste geval: de mechaniek is in elk geval te begrijpen en te reproduceren. Het lastigst zijn HP en Aruba, waar het geheugen interactief reageert en sleutels vereist - daar kom je met dumps alleen niet meer weg.