mac adres omzetten naar serie nummer

[rvandaalen]

Is het mogelijk een reversible functie/formule te maken welke een
mac address 00:00:00:00:00:00 - FF:FF:FF:FF:FF:FF
omzet naar een 8 numeriek getal/serial. Waarbij je de oorspronkelijke mac weer kan afleiden adhv de serial?
Of is dit onmogelijk?

[TheDiver]

Met dank aan Google, of heb je die niet?
FF goed lezen? Het is een voobeeld! Dus zelf ff knutselen.

How can I determine my UDS, SDS or Cobox's serial number from it’s ethernet (MAC) address?
Calculating Serial Numbers from Ethernet (MAC) address:
(for units: CoBox-E2, CoBox-FL, Mini, Micro, UDS-10, UDSx00, XPress-DR, SDSx100, DinRail, NTP)

Brief explanation of the Ethernet address serial numbers
- ---------------------------------------
Ethernet addresses are of the hex form:

00-20-4A-xx-xx-xx

00-20-4A is a range of Ethernet addresses that Lantronix purchased. All Lantronix CoBox/UDS10 products that have an Ethernet address will use 00-20-4A as the first six digits of their network address.

The next two digits of the Ethernet address are the product code.

So, an Ethernet address for an UDS10 (US-EMI) would be:

00-20-4A-54-xx-xx

Note that xx-xx is a hexadecimal number with values ranging from 00-00 to FF-FF. This corresponds to decimal numbers 0 through 65535.

The actual product serial number is generated by converting the last 4 characters of the Ethernet address into decimal and then placing the product code in front of the number. So for example, the serial number for Ethernet address:

00-20-4A-54-00-82 -- convert 0082 hex to decimal ==> 130
-- pad with leading zeros(5 digits total) ==> 00130
-- Start with the product code 54 => 54
-- Append the unit number ==> 5400130


Current list of product codes:
upper half 4th Byte:
1 US-LTRX
2 MX-HEI
3 GmbH-LTRX
4 Gmbh-RTG
5 US-EMI
6 US-EMI

Lower half of the 4th Byte:
1 - one port (DinRail, Mini)
2 - two port (E2, NTP, E2M)
4 - one port (UDS10, Micro, Mini-Rev2)
8 - Token Ring

[Verwijderd]

Dit is onmogelijk met een getal, er zijn 16¹² ofwel 281474976710656 mogelijke adressen. Maar als je de 8e wortel neemt van dat getal, kom je uit op 64. Als je dus een getallenstelsel neemt met 64 mogelijke tekens per positie dan komt het goed. Je zou base64 op een binary representatie van het MAC adres kunnen proberen.

[jeroen3]

Van de laatse twee bytes van het mac adres de nibbles met leading zero afdrukken.
xx:xx:xx:xx:AB:CD -> aabbccdd

[RobIII]

jeroen3 schreef op vrijdag 15 augustus 2014 @ 07:21:
Van de laatse twee bytes van het mac adres de nibbles met leading zero afdrukken.
xx:xx:xx:xx:AB:CD -> aabbccdd

En hoe is dat terug te herleiden naar de originele MAC?

Ook TheDivers' "oplossing" werkt alleen als je een zeer specifieke range netwerkkaarten gebruikt en alle anderen uitsluit.

@TS: nee. Vraag je dit eens af; hoe kun je de getallen 0-1000 opslaan in 2 digits met enkel cijfers? Dat kan niet want je kunt hooguit 100 combinaties maken. 1:10 combinaties zal dus een "collision" geven met 10 andere combinaties. Je zult dus 1 van je twee eisen moeten droppen: meer digits gebruiken of de code is niet (ondubbelzinnig) terug te leiden naar het originele MAC.

Lang verhaal kort:
In een MAC-adres is weinig ruimte om nog informatie "weg te gooien" zonder dat je collisions gaat krijgen. Het enige wat je nog kunt doen is de hexadecimale notatie opschroeven naar een encoding met meer informatie per "digit" en dus >base16. Je kunt base36 (0-9 en a-z) gebruiken of base64 (0-9, a-z, A-Z, + en / _{waarbij je natuurlijk je eigen encoding kunt "verzinnen" door bijv + en / te vervangen door bijv - en .}) om meer informatie in de beschikbare ruimte te proppen maar dan houdt 't op.

[ Voor 32% gewijzigd door RobIII op 15-08-2014 09:47 ]

[MSalters]

Klopt. TS is duidelijk niet bekend met het Pigeonhole principle. Als je 100 duiven en 99 duiventillen hebt, dan gaat dat niet passen. En als je 2^48 duiven hebt en 10^8 tillen, dan ook niet. Je hoeft dan niet eens na te denken welke duif waarheen moet; het past sowieso niet.