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: Interface.Flags always 0 on Windows 8 #10530

Closed
ffoebel opened this issue Apr 22, 2015 · 5 comments
Closed

net: Interface.Flags always 0 on Windows 8 #10530

ffoebel opened this issue Apr 22, 2015 · 5 comments

Comments

@ffoebel
Copy link

ffoebel commented Apr 22, 2015

Go version: 1.4

The following code works on Windows 7:

package main
import "fmt"
import "net"
func main() {
    ifs, _ := net.Interfaces()
    for _, i := range ifs {
        fmt.Println(i.Flags)
    }
}

Tried both "run as administrator" and "compatibility mode" to see whether this was a side effect but never saw any flags when running on Windows 8.

@mattn
Copy link
Member

mattn commented Apr 22, 2015

it is fixed in 2015/02/10.
https://go-review.googlesource.com/#/c/3024/

@mikioh mikioh changed the title net.Interface.Flags always 0 on Windows 8 net: Interface.Flags always 0 on Windows 8 Apr 22, 2015
@mikioh
Copy link
Contributor

mikioh commented Apr 22, 2015

Duplicate of #5395.

@mikioh mikioh closed this as completed Apr 22, 2015
@oliveagle
Copy link

same here. on windows 2012 R2
go 1.4.2

@mattn
Copy link
Member

mattn commented Jul 8, 2015

The fixes is applied to the tip on repo. So go1.4.2 doesn't have the fix.

@gopherbot
Copy link

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

mikioh pushed a commit that referenced this issue Dec 10, 2015
…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>
@mikioh mikioh added this to the Go1.6 milestone Dec 10, 2015
@golang golang locked and limited conversation to collaborators Dec 14, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants