Skip to content

Conversation

@Snorkell
Copy link

@Snorkell Snorkell commented Jan 6, 2026

Hey,

I was trying to list all my network adapters from windows using your lib and I had some issue while listing them

When using the list_interfaces() form the file list_win.rs I saw that you were using the adapter.Ipv6IfIndex field which in some cases returns 0.
When reading about this field in the Windows documentation, 0 is a reserved index and should not be used.
It seems that interfaces that have the ipv6 stack disabled will always return 0.

Which means that some elements of the list will always be overwritten since it's inserting at index 0

//... list_win.rs
let iface = Interface {
                index: ifindex,
                name,
                hw_addr,
                ips,
            };
ifs.insert(ifindex, iface); 
//... list_win.rs

My solution in this PR is using the methods GetAdapterIndex from the Windows crate that will always return the right index for a given adapter regardless of the ip stack enabled

@thombles
Copy link
Owner

thombles commented Jan 6, 2026

Awesome, thanks for finding the bug! I had a look and I think we can do something cleaner here. In IP_ADAPTER_ADDRESSES_LH there's not only Ipv6IfIndex but also IfIndex. These will be 0 when IPv6 or IPv4 is disabled respectively. The trouble is the auto-generated Rust bindings make this hard to find - the IPv4 version is accessed via the ugly path adapter.Anonymous1.Anonymous.IfIndex.

So what I think we should do is:

  • Get the IPv4 IfIndex
  • If it was 0, get the Ipv6IfIndex
  • If that was also 0, skip this adapter because it doesn't have either IP stack enabled

This way we don't need to make any additional windows API calls.

@Snorkell
Copy link
Author

Snorkell commented Jan 7, 2026

Sure I made the changes

I found out about the Rust binding shenanigans, and I wasn't sure if you rather recall the windows API or use the confusing path to the value.

I had both solutions in mind and ready to be pushed 😅

@thombles
Copy link
Owner

thombles commented Jan 7, 2026

Perfect, thanks! Let me get this through the CI checks and I'll release a 0.4.1 for you shortly.

@thombles thombles merged commit 2f3a55c into thombles:main Jan 7, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants