VLAN adapter not working after reboot - Win10, 22.0.1

[MZies1]

Following all the events at and http://hardwarerecs.stackexchange.com/questions/2422/usb-to-ethernet-adapter-supporting-multiple-virtual-lans networking - USB to Ethernet adapter supporting multiple virtual LANs - Hardware Recommendations Stack Exchange, we now have an Ethernet driver that should properly support the Intel Advanced Networking Suite (iANS) under Windows 10.

Using Windows 10.0.14393 with all updates installed, with an I217-LM adapter and the https://downloadcenter.intel.com/download/25016/Intel-Network-Adapter-Driver-for-Windows-10 22.0.1 driver installed. Things seem to be very flaky. My focus here is primarily on being able to work with multiple VLANs, with no trunking at present.

First - when creating new VLANs, ensure that the "Network Connections" window or any similar windows other than the "Intel(R) Ethernet Connection * Properties" dialog are closed. Not doing so will frequently result in the operation hanging indefinitely. (I remember the same from when we had the working drivers here in Windows 7 and Windows 8 days.) Even with the other windows closed, sometimes it is taking almost 5 minutes to create a new VLAN - but it takes even longer to do so with the "Network Connections" window open (if it completes at all).

With this out of the way: Add a new VLAN10. Only once one VLAN is created can we then create the "Untagged VLAN" (ID 0). Reboot. Everything still works and comes back up as expected.

Add a 2nd tagged VLAN, say VLAN11. Reboot. The "Untagged VLAN" fails to pull a DHCP lease. The virtual adapter shows packets being sent and received. I ran Wireshark on the Untagged VLAN adapter, saw DHCPDISCOVER packets go out, and other unrelated broadcasts and packets coming back - but no DHCPOFFERs returned. I.E., it seems to be missing traffic in that state. Disable the Untagged VLAN adapter, re-enable, and it instantly comes back with a valid lease. This is constantly repeatable. Nothing is even connected to the other side of these VLANs yet (the connected switchport isn't even trunked). Remove the 2nd tagged VLAN leaving only one tagged VLAN and the untagged, and things work much better - but this kind of defeats the purpose.

Here's my ugly hack of a work-around for now: Add a Windows Scheduled Task to run at System Startup, and to run with highest privileges. Use a PowerShell similar to the following as the action:

$(

Get-Date

Write-Host "Starting..."

ipconfig.exe /all

Write-Host "Restarting..."

Restart-NetAdapter -Name "Ethernet - Untagged" -Confirm:$false

ipconfig.exe /all

Get-Date

Write-Host "Done."

) *>&1 > C:\FixIntelNetwork.log

I was worried about timing, and could add a 30 second delay or such in the startup trigger. However, the ipconfig outputs show that this wasn't necessary. In the first ipconfig output, the adapter was present and already had an auto-configured 169.254.x.y IP address. In the second ipconfig output, a proper DHCP lease was shown.

As I don't have anything on the other VLANs to test with yet, I still need to determine - but may have to reset the other VLAN interfaces at startup as well.

[idata]

Hi ziesemer,

Thank you for sharing the information and test done using the new driver version 22. Let me check on this.rgds,wb

[CARL_W_Intel]

ziesemerWould you be willing to send us the minidump from the failure? Our Windows driver team would like to take a look at it. You can send it directly to me and I'll send it to the driver development team.

[MZies1]

Carl_Wilson wrote:

ziesemerWould you be willing to send us the minidump from the failure? Our Windows driver team would like to take a look at it. You can send it directly to me and I'll send it to the driver development team.

I'd be happy to - but there wasn't a crash or a dump. The VLAN virtual interface simply wasn't passing traffic properly (preventing it from getting a DHCP lease) until I manually disabled and re-enabled it. So a functional issue rather than a crash.

I'm actually re-installing the workstation at present from the latest and greatest Windows 10 image (10.0.14393, same as above), + all updates. The process of creating the new VLAN adapters now seems to be working much more seamlessly. I've also been able to restart the computer a few times so far without the virtual interfaces not coming back. It still takes a minute for them to start passing traffic properly after boot - but at least they're working now. I'll update this thread again, or mark this as resolved before the end of the week.

[idata]

Hi Ziesemer,

I understand you re-install the workstation, please feel free to update the current status, hope all works well.rgds,wb

[ALlor]

Hi,

Are you planning to fix this issue soon?

As I said on my first message, be free to ask for logs, or anything you need to help you. I need to deploy this driver across the company, but it is not usable at this point.

Thank you in advance.

Best regards

Aurelio Llorente

[idata]

Hi Aurelio,

I have branch out your inquiry to another post.Thanks,wb