This is the
talk page for discussing improvements to the
MAC address article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives:
Index,
1Auto-archiving period: 365 days
![]() |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
![]() | This article has been
mentioned by a media organization:
|
I don't believe there is any concept of Least or Most Significant Byte in MAC addresses. There are merely the first octet through the nth octet (6 or 8). The standard only speaks of octets, and octets are transmitted in order one by one. The standard *does* assume a significance of bits within an octet, and specifies physical-layer transmission bit-order and the I/G and U/L bits in terms of "Least Significant Bit". But there is no "significance" of bytes in MAC addresses; they are merely identifiers; there is no concept of arithmetic with them; their essential property (as far as the protocol is concerned) is uniqueness only. (The separation of part of the address into an OUI is for convenience of human administration and is not essential to the protocol.) -- Dave Butterfield ( talk) 00:54, 21 February 2009 (UTC)
I agree here with Dave. The third and fourth paragraphs are very confusing on this point and should be rewritten. The diagram is also just wrong (no byte significance, no opposite byte/order direction, no fixed bit order transmission). And these points are quite important when trying to understand the Bluetooth protocol as in this special case, octets are transmitted in the wrong order (though BT spec pretends to be complying with IEEE 802-2001). It would be actually interesting to add a new paragraph ("transmission order") explaining these subtleties. Calandoa ( talk) 16:23, 15 March 2016 (UTC)
In various places, the text refers to "most significant byte", "most significant address octet", both mixing the 2 terms and assuming significance. In my opinion, there is absolutely no need to confuse people with byte order in this instance, and a lot of confusion could be avoided by always referring to the octets by their order on the wire, "First octet" being the first one transmitted, etc. There is a diagram that labels the first octet on the wire as both "6th byte" and "1st octet", as well as labeling the first byte as "most significant". This seems completely wrong to me and can only lead to confusion. I propose the "Address details" section be rewritten to avoid all references to byte order. It seems there is some agreement on this so I will try to do this. Catphish ( talk) 10:32, 6 June 2016 (UTC)
After reading I was forced to look elsewhere for a definition of octets and bits (as I did for IP addressing on Wikipedia). A clear note to explain the octet as a hexadecimal representation of an 8 bit binary value might help. In addition, no mention here of BSSIDs, which are also MAC-48 values; nor of (claimed?) deobfuscation of MAC addresses by websites are thereby beyond local networks. The Apple iPhone mention seems advertising given the widespread default spoofing in much software these days (including Windows 10 Settings where default randomization can be ticked, and Linux Network Manager, which randomizes by default and has to be disabled in its configuration file to allow user MAC control). 94.118.87.120 ( talk) 20:42, 21 November 2018 (UTC)
References number 26 and 27 are supposed to prove that it is possible to recognize a person given its mac address, or something along those lines. The first points to nothing while the second just looks irrelevant to me. 92.134.33.82 ( talk) 12:28, 29 September 2023 (UTC)
Why do the ranges specified only have five octet addresss e.g. X2-XX-XX-XX-XX? 2A00:23C4:DB3D:E901:90CA:4ED5:72C:E339 ( talk) 12:19, 20 November 2023 (UTC)
This is the
talk page for discussing improvements to the
MAC address article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives:
Index,
1Auto-archiving period: 365 days
![]() |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
![]() | This article has been
mentioned by a media organization:
|
I don't believe there is any concept of Least or Most Significant Byte in MAC addresses. There are merely the first octet through the nth octet (6 or 8). The standard only speaks of octets, and octets are transmitted in order one by one. The standard *does* assume a significance of bits within an octet, and specifies physical-layer transmission bit-order and the I/G and U/L bits in terms of "Least Significant Bit". But there is no "significance" of bytes in MAC addresses; they are merely identifiers; there is no concept of arithmetic with them; their essential property (as far as the protocol is concerned) is uniqueness only. (The separation of part of the address into an OUI is for convenience of human administration and is not essential to the protocol.) -- Dave Butterfield ( talk) 00:54, 21 February 2009 (UTC)
I agree here with Dave. The third and fourth paragraphs are very confusing on this point and should be rewritten. The diagram is also just wrong (no byte significance, no opposite byte/order direction, no fixed bit order transmission). And these points are quite important when trying to understand the Bluetooth protocol as in this special case, octets are transmitted in the wrong order (though BT spec pretends to be complying with IEEE 802-2001). It would be actually interesting to add a new paragraph ("transmission order") explaining these subtleties. Calandoa ( talk) 16:23, 15 March 2016 (UTC)
In various places, the text refers to "most significant byte", "most significant address octet", both mixing the 2 terms and assuming significance. In my opinion, there is absolutely no need to confuse people with byte order in this instance, and a lot of confusion could be avoided by always referring to the octets by their order on the wire, "First octet" being the first one transmitted, etc. There is a diagram that labels the first octet on the wire as both "6th byte" and "1st octet", as well as labeling the first byte as "most significant". This seems completely wrong to me and can only lead to confusion. I propose the "Address details" section be rewritten to avoid all references to byte order. It seems there is some agreement on this so I will try to do this. Catphish ( talk) 10:32, 6 June 2016 (UTC)
After reading I was forced to look elsewhere for a definition of octets and bits (as I did for IP addressing on Wikipedia). A clear note to explain the octet as a hexadecimal representation of an 8 bit binary value might help. In addition, no mention here of BSSIDs, which are also MAC-48 values; nor of (claimed?) deobfuscation of MAC addresses by websites are thereby beyond local networks. The Apple iPhone mention seems advertising given the widespread default spoofing in much software these days (including Windows 10 Settings where default randomization can be ticked, and Linux Network Manager, which randomizes by default and has to be disabled in its configuration file to allow user MAC control). 94.118.87.120 ( talk) 20:42, 21 November 2018 (UTC)
References number 26 and 27 are supposed to prove that it is possible to recognize a person given its mac address, or something along those lines. The first points to nothing while the second just looks irrelevant to me. 92.134.33.82 ( talk) 12:28, 29 September 2023 (UTC)
Why do the ranges specified only have five octet addresss e.g. X2-XX-XX-XX-XX? 2A00:23C4:DB3D:E901:90CA:4ED5:72C:E339 ( talk) 12:19, 20 November 2023 (UTC)