You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 17, 2021. It is now read-only.
This is probably a known issue. Looks like the fourth octet isn't accounted for.
This is from the output of mm-commotion-mac2ip.tests:
DC:9F:DB:3F:14:BA resolved to 100.127.20.186
DC:9F:DB:7F:14:BA resolved to 100.127.20.186
DC:9F:DB:BF:14:BA resolved to 100.127.20.186
DC:9F:DB:FF:14:BA resolved to 100.127.20.186
DC:9F:DB:08:CE:C6 resolved to 100.72.206.198
DC:9F:DB:48:CE:C6 resolved to 100.72.206.198
DC:9F:DB:88:CE:C6 resolved to 100.72.206.198
DC:9F:DB:C8:CE:C6 resolved to 100.72.206.198
DC:9F:DB:3C:23:B6 resolved to 100.124.35.182
DC:9F:DB:7C:23:B6 resolved to 100.124.35.182
DC:9F:DB:BC:23:B6 resolved to 100.124.35.182
DC:9F:DB:FC:23:B6 resolved to 100.124.35.182
DC:9F:DB:1B:CD:02 resolved to 100.91.205.2
DC:9F:DB:5B:CD:02 resolved to 100.91.205.2
DC:9F:DB:9B:CD:02 resolved to 100.91.205.2
DC:9F:DB:DB:CD:02 resolved to 100.91.205.2
DC:9F:DB:34:C2:C3 resolved to 100.116.194.195
DC:9F:DB:74:C2:C3 resolved to 100.116.194.195
DC:9F:DB:B4:C2:C3 resolved to 100.116.194.195
DC:9F:DB:F4:C2:C3 resolved to 100.116.194.195
DC:9F:DB:35:AD:A3 resolved to 100.117.173.163
DC:9F:DB:75:AD:A3 resolved to 100.117.173.163
DC:9F:DB:B5:AD:A3 resolved to 100.117.173.163
DC:9F:DB:F5:AD:A3 resolved to 100.117.173.163
There are obviously a lot more of them. This is just a few at the beginning of the test.
The text was updated successfully, but these errors were encountered:
As I began developing this, I have been trying to establish an understanding of what is expected. Initially following closely to information available at #3 including initial posts with inaccurate information, I eventually concluded or it was agreed upon that duplicated ip address should be calculated from mac addresses so that all possible mac addresses would fit into the limited ipv4 range. 256 * 256 * 256 mac address possibilities (for each of the valid first three octets) to fit into only 64 * 256 * 256 ipv4 address possibilities, for the moment each ipv4 address generated is duplicated 4 times.
Let me know if some other calculation is expected.
We're converting mac addresses into the 100.6.0.0/10 subnet. This range begins with 100.64.0.0 and ends at 100.127.255.255.
In the example DC:9F:DB:F5:AD:A3, the first 3 mac numbers are ignored leaving us with F5:AD:A3.
Now, the last 2 mac numbers AD and A3 are valid in their full range. We can DIRECTLY convert them to their decimal value. So AD is 173 and A3 is 163. So we now know that our end IP address will be 100.?.173.163.
For the second octet we need to calculate the octet in modulo. When F5 is converted to decimal it is 245 which is out of the range of 64-127. That octet needs to be reliably converted in modulo to it's rightful octet which, according to the long list of IPs in #3 is 117 leaving us with a valid IP address of 100.117.173.163 as Colin correctly showed us earlier.
Questions?
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This is probably a known issue. Looks like the fourth octet isn't accounted for.
This is from the output of
mm-commotion-mac2ip.tests
:There are obviously a lot more of them. This is just a few at the beginning of the test.
The text was updated successfully, but these errors were encountered: