6 Replies Latest reply on Mar 9, 2017 6:39 PM by Intel Corporation Branched to a new discussion.

    VLAN adapter not working after reboot - Win10, 22.0.1

    ziesemer

      Following all the events at I211/I217-V Windows 10 LACP teaming fails and 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 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.