trying to figure out if i suck at programming or if realtek has byte-reversed their own OUI in addition to bit-reversing it as the spec needs
-
who do you think sucks at reading comprehension
this can't just be me, right
>>> hex(int("0000000000011100110010",2)) # what Realtek says
'0x732'
>>> hex(int("0000000000011100110010"[::-1],2)<<2) # what IEEE 802.3 says
'0x4ce000'00-E0-4C (hex) REALTEK SEMICONDUCTOR CORP.(what the IEEE list says)
-
this can't just be me, right
>>> hex(int("0000000000011100110010",2)) # what Realtek says
'0x732'
>>> hex(int("0000000000011100110010"[::-1],2)<<2) # what IEEE 802.3 says
'0x4ce000'00-E0-4C (hex) REALTEK SEMICONDUCTOR CORP.(what the IEEE list says)
grabbed a random other PHY, from MaxLinear
they use an OUI that doesn't exist in any of the OUI databases I've checked
-
grabbed a random other PHY, from MaxLinear
they use an OUI that doesn't exist in any of the OUI databases I've checked
@whitequark if it’s not officially granted by the IEEE then it’s not a OUI, it’s a NON.
-
grabbed a random other PHY, from MaxLinear
they use an OUI that doesn't exist in any of the OUI databases I've checked
@whitequark lol i worked on a chip years ago that used transmeta's OUI for its JTAG interface.
It waa definitely not a transmeta part. But at least it was *a* real OUI?
-
grabbed a random other PHY, from MaxLinear
they use an OUI that doesn't exist in any of the OUI databases I've checked
found another random PHY
looks like the byte-reversal is not realtek's invention. but why the fuck is it needed?
>>> hex(int('0000000000100010000101'[::-1],2)<<2)
'0xa11000'
-
@whitequark lol i worked on a chip years ago that used transmeta's OUI for its JTAG interface.
It waa definitely not a transmeta part. But at least it was *a* real OUI?
@whitequark (also there's more OUIs than address space in compressed formats like JTAG so there's some kind of weird address space compression paging going on that I don't fully grok for companies founded since like the 80s)
-
@whitequark (also there's more OUIs than address space in compressed formats like JTAG so there's some kind of weird address space compression paging going on that I don't fully grok for companies founded since like the 80s)
@azonenberg I don't think JTAG uses OUIs?
-
@azonenberg I don't think JTAG uses OUIs?
@whitequark oh right JEP106 is JEDEC I'm mixing it up with something
-
@whitequark oh right JEP106 is JEDEC I'm mixing it up with something
@azonenberg JEP106 does however use the weird address space compression paging
-
this can't just be me, right
>>> hex(int("0000000000011100110010",2)) # what Realtek says
'0x732'
>>> hex(int("0000000000011100110010"[::-1],2)<<2) # what IEEE 802.3 says
'0x4ce000'00-E0-4C (hex) REALTEK SEMICONDUCTOR CORP.(what the IEEE list says)
@whitequark FYI FreeBSD has:
Vendors do obviously not agree how OUIs (24 bit) are mapped to the 22 bits available in the id registers.
IEEE 802.3u-1995, subclause 22.2.4.3.1, figure 22-12, depicts the right mapping; the bit positions are defined in IEEE 802-1990, figure 5.2.
(There is a formal 802.3 interpretation, number 1-07/98 of July 09 1998, about this.)
...
If a vendor uses a different mapping, an "xx" prefixed OUI is defined here which is mangled accordingly to compensate. -
@whitequark FYI FreeBSD has:
Vendors do obviously not agree how OUIs (24 bit) are mapped to the 22 bits available in the id registers.
IEEE 802.3u-1995, subclause 22.2.4.3.1, figure 22-12, depicts the right mapping; the bit positions are defined in IEEE 802-1990, figure 5.2.
(There is a formal 802.3 interpretation, number 1-07/98 of July 09 1998, about this.)
...
If a vendor uses a different mapping, an "xx" prefixed OUI is defined here which is mangled accordingly to compensate.@Darius that doesn't tell me much
-
@Darius that doesn't tell me much
@whitequark just “vendors are idiots” but I suppose that isn’t news
-
found another random PHY
looks like the byte-reversal is not realtek's invention. but why the fuck is it needed?
>>> hex(int('0000000000100010000101'[::-1],2)<<2)
'0xa11000'A complete guess, but:
A lot of networking equipment used big-endian MIPS until recently. Big-endian avoided a load of byte swapping for packet headers (this is effectively free on more complex cores) and MIPS basically gave away the R4K core when they were low on cash (unlimited-use licenses). It may be that Realtek did it deliberately to make it easier to read on big-endian MIPS, but I wouldn’t be at all surprised if they did testing on big-endian MIPS and forgot that they needed to byte swap, so it passed the tests and then they shipped it.
-
A complete guess, but:
A lot of networking equipment used big-endian MIPS until recently. Big-endian avoided a load of byte swapping for packet headers (this is effectively free on more complex cores) and MIPS basically gave away the R4K core when they were low on cash (unlimited-use licenses). It may be that Realtek did it deliberately to make it easier to read on big-endian MIPS, but I wouldn’t be at all surprised if they did testing on big-endian MIPS and forgot that they needed to byte swap, so it passed the tests and then they shipped it.
@david_chisnall no, this isn't it
-
@david_chisnall no, this isn't it
@whitequark Their DV team is made of vampires and they were hanging upside down when they got to this bit?
-
@whitequark Their DV team is made of vampires and they were hanging upside down when they got to this bit?
@david_chisnall yes, but make it IBM. Realtek seems to be doing what everyone else is doing
-
@david_chisnall yes, but make it IBM. Realtek seems to be doing what everyone else is doing
@david_chisnall as far as I can tell there is no rationale or justification, they fucked it up and now we all gotta deal with it forever
-
@david_chisnall yes, but make it IBM. Realtek seems to be doing what everyone else is doing
Weird, that implies there’s some hiring overlap between IBM’s legal and DV teams.
-
R relay@relay.infosec.exchange shared this topic
