Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net: window network MAC change from MAC-48 to EUI-64 #13542

Closed
astaxie opened this issue Dec 9, 2015 · 5 comments

Comments

Projects
None yet
3 participants
@astaxie
Copy link

commented Dec 9, 2015

Here is the code I have tested on windows:

package main

import (
    "net"
    "fmt"
)
func main() {
    inets, _ := net.Interfaces()
    for _, i := range inets {
        if mac := i.HardwareAddr.String(); mac != "" {
            fmt.Println("MAC:",mac)
            fmt.Println("Name",i.Name)
            addrs, _ := i.Addrs()
            for _, addr := range addrs {
                if addr := addr.String(); addr != "" {
                    fmt.Println("Addr:",addr)
                }
            }
        }
    }
}

Run this code on different version:

On 1.4.3 get the result:

MAC: 08:00:27:0a:af:0c
Name {558CA760-9D61-47CC-AF7D-4E8635DDD283}
Addr: 10.0.2.15

On 1.5.1 get the result:

MAC: 08:00:27:0a:af:0c:00:00
Name Local Area Connection
Addr: 10.0.2.15/16

On 1.5.2 get the result:

MAC: 08:00:27:0a:af:0c:00:00
Name Local Area Connection
Addr: 10.0.2.15/16
MAC: 00:00:00:00:00:00:00:00
Name MS TCP Loopback interface
Addr: 127.0.0.1/1

The old version MAC use the standard IEEE 802 format MAC-48. but the new version use the EUI-64.

If my program is relied on the MAC as the uuid. then upgrade Go will cause big problem. Is there any config to get MAC-48 not EUI-64?

@astaxie

This comment has been minimized.

Copy link
Author

commented Dec 9, 2015

The big problem is that MacOS and Linux still use the MAC-48. it's not keep consistent for the same code

@mikioh mikioh changed the title window network MAC change from MAC-48 to EUI-64 net: window network MAC change from MAC-48 to EUI-64 Dec 9, 2015

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Dec 9, 2015

That's not neither MAC-64 nor EUI-64. It's just broken, Go 1.5 through Go 1.5.2, as described in #12691.

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Dec 9, 2015

This is a duplicate of #12691.

@gopherbot

This comment has been minimized.

Copy link

commented Dec 9, 2015

CL https://golang.org/cl/17412 mentions this issue.

mikioh pushed a commit that referenced this issue Dec 10, 2015

Mikio Hara
net, internal/syscall/windows: fix interface and address identificati…
…on on windows

The current implementation including Go 1.5 through 1.5.2 misuses
Windows API and mishandles the returned values from GetAdapterAddresses
on Windows. This change fixes various issues related to network facility
information by readjusting interface and interface address parsers.

Updates #5395.
Updates #10530.
Updates #12301.
Updates #12551.
Updates #13542.
Fixes #12691.
Fixes #12811.
Fixes #13476.
Fixes #13544.

Also fixes fragile screen scraping test cases in net_windows_test.go.

Additional information for reviewers:

It seems like almost all the issues above have the same root cause and
it is misunderstanding of Windows API. If my interpretation of the
information on MSDN is correctly, current implementation contains the
following bugs:

- SIO_GET_INTERFACE_LIST should not be used for IPv6. The behavior of
  SIO_GET_INTERFACE_LIST is different on kernels and probably it doesn't
  work correctly for IPv6 on old kernels such as Windows XP w/ SP2.
  Unfortunately MSDN doesn't describe the detail of
  SIO_GET_INTERFACE_LIST, but information on the net suggests so.

- Fetching IP_ADAPTER_ADDRESSES structures with fixed size area may not
  work when using IPv6. IPv6 generates ton of interface addresses for
  various addressing scopes. We need to adjust the area appropriately.

- PhysicalAddress field of IP_ADAPTER_ADDRESSES structure may have extra
  space. We cannot ignore PhysicalAddressLength field of
  IP_ADAPTER_ADDRESS structure.

- Flags field of IP_ADAPTER_ADDRESSES structure doesn't represent any of
  administratively and operatinal statuses. It just represents settings
  for windows network adapter.

- MTU field of IP_ADAPTER_ADDRESSES structure may have a uint32(-1) on
  64-bit platform. We need to convert the value to interger
  appropriately.

- IfType field of IP_ADAPTER_ADDRESSES structure is not a bit field.
  Bitwire operation for the field is completely wrong.

- OperStatus field of IP_ADAPTER_ADDRESSES structure is not a bit field.
  Bitwire operation for the field is completely wrong.

- IPv6IfIndex field of IP_ADAPTER_ADDRESSES structure is just a
  substitute for IfIndex field. We cannot prefer IPv6IfIndex to IfIndex.

- Windows XP, 2003 server and below don't set OnLinkPrefixLength field
  of IP_ADAPTER_UNICAST_ADDRESS structure. We cannot rely on the field
  on old kernels. We can use FirstPrefix field of IP_ADAPTER_ADDRESSES
  structure and IP_ADAPTER_PREFIX structure instead.

- Length field of IP_ADAPTER_{UNICAST,ANYCAST,MULTICAST}_ADDRESS
  sturecures doesn't represent an address prefix length. It just
  represents a socket address length.

Change-Id: Icabdaf7bd1d41360a981d2dad0b830b02b584528
Reviewed-on: https://go-review.googlesource.com/17412
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
@astaxie

This comment has been minimized.

Copy link
Author

commented Dec 18, 2015

I have tested on Go1.6 beta1. it works now

go version go1.6beta1 windows/386

> nettest-160-beta.exe
MAC: 08:00:27:0a:af:0c
Name Local Area Connection
Addr: 10.0.2.15/24

@golang golang locked and limited conversation to collaborators Dec 29, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.