none
Win10 Pro ReleaseId 1709 Connection Manager/Connectivity issue - Multi-homed with Cellular and 'Stub' Ethernet networks.. RRS feed

  • Question

  • I have a particular network topology in use, which appears to have been 'broken' ever since Windows 10 Release 1709 arrived (It worked fine with Release 1703!). I'm using the machine at home, with the consumer version of Windows 10 downloaded from the Microsoft site and installed straight off a bootable UFD/USB Stick..

    BACKGROUND

    Windows 10 Pro x64 is running happily on a generic hardware platform, which has at least one Ethernet interface and a cellular modem installed (The modem is the WAN interface in this case, as the machine is at home in an area without useable wired broadband!). No Wi-Fi interfaces are installed.

    The modem establishes a cellular network connection just fine and works beautifully. The single Ethernet interface in use is directly attached to a box of tricks containing several SNMP-Addressed GPIO/Digital inputs&outputs I use for home automation and remote control. This Ethernet subnet is just a basic /24, with no 'gateway' involved - the PC interface and the GPIO box are the only two host addresses in the subnet, and both have a static address defined..think of it as a 'stub' network. The machine is, of course, NOT joined to a domain.

    Using Windows 10 Pro R1703, this worked fine, meaning Internet connectivity was as expected with the Cellular interface and Ethernet interfaces connected and operational/'UP'.

    PROBLEM

    However, as soon as the machine automatically upgraded itself to R1709, or following a 'clean install' of WIn 10 Pro x64 R1709, I loose internet connectivity. If the Ethernet cable is disconnected, internet connectivity returns. As soon as the cable is re-connected and this 'stub' Ethernet interface comes up again, I loose internet connectivity. Things to note are: [1] This problem only occurs on using R1709 - everything was fine on R1703 and previously. [2] The IPV4 and IPV6 routing tables are sane and consistant at all times (I'm more of an IP networking person than an Windows person) [3] The local 'stub' and cellular networks use IPV4 only, however all adapters have IPV6 enabled and have IPV6 Link-local addresses. [4] If I temporarily connect an ethernet connection that DOES have a IPV4 route to the internet, things still work OK as Windows 10 now appears to route via the (higher priority) gateway on the ethernet network.

    No matter what I try with adapter bindings / route metrics  etc, I cannot get the machine to pass traffic to the internet connection (The cellular interface, remember) with the 'Stub' Ethernet network connected.

    WORKAROUND

    My workaround up to now has been to disable the 'Windows Connection Manager' service from starting, as I think it's internal 'Soft Disconnect' or other logic is what's causing my problems. Disabling the WCM results in things working as expected (Thinks:Does WCM's logic understand that an Ethernet interface may or may *NOT* have a route to the internet, or has someone assumed the Ethernet will *ALWAYS* have internet connectivity?). Up to now, the WCM's service dependants (Mobile Hotspot Service and WLAN AutoConfig service) haven't been necessary, so disabling WCM was an acceptable 'fix' for me. Trouble is, I want to expand the device's capabilities and I now need at least the WLAN Autoconfig service!

    As a result, I have also tried setting the Local Computer Policy 'Minimise the number of simultaneous connections to the Internet or a Windows Domain' to DISABLED as WCM's described behaviour with this setting='disabled' seemed to be what I needed, but despite 'rsop' and 'gpresult' both showing the policy setting is in force (Set to 'Disabled'), my 'No internet connectivity with a Stub Network' problem still exists.

    SUMMARY

    No matter what I do (And I'm supposedly an experienced engineer with the will NOT to give up!) I cannot get things to work, and currently think that either (a) WCM is 'broken' when using a Mobile/Cellular connection to the internet as the 'backhaul/WAN Interface' with a local 'Stub' Ethernet network. (b) My method of applying a local GP setting on a non-domain-joined/standalone machine may be at fault (I'm NOT a Windows expert, remember!).

    Can anyone offer any (polite!) suggestions about what I may need to change in Windows R1709 to get this to work 'Properly'? Remember, things worked fine using WIn10 Pro ReleaseId 1703 - it's only since 1709 arrived I've had the problem. Hint:Using any Ethernet connection as my route to the internet is NOT an option!

    Regards,

    Paul

    Monday, March 19, 2018 12:43 PM

Answers

  • I found a good solution in this thread:

    https://social.technet.microsoft.com/Forums/windows/en-US/e20c2af2-f2c1-419c-a2a3-cd2d07d8e699/network-problem-with-mbim-after-upgrading-windows-10-1709?forum=win10itpronetworking&prof=required

    Best regards

    • Marked as answer by Paul.T Thursday, November 1, 2018 7:19 PM
    Wednesday, May 9, 2018 3:10 PM

All replies

  • Hi,

    I noticed that it worked fine in 1703, have you reinstalled 1709? Maybe there is something wrong with your system.

    Best Regards,

    Tao


    Please remember to mark the replies as answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, March 20, 2018 3:06 AM
    Moderator
  • Hi, Tao.

    I'm pretty sure it's an issue with Win10 R1709. It first surfaced after the 1703-->1709 automatic feature update, which is what caused me to look into this issue.

    I have done several re-installs over the last few weeks looking for a way round this.

    1) 'Clean' install of Windows 10 x64 Pro ReleaseId 1703...everything works fine out of the box.

    2) This '1703' installation was then allowed to update to '1709' and the problem immediately occurs. As I had not changed any settings at all, this gave me the 'Feature Update broke my system' feeling:-( Not the sort of thing I expect from Microsoft!

    3) Steps 1-2 have been repeated several times - each time, things are fine before the R1703-->1709 update, and 'broken' thereafter.

    4) I Then did a 'clean' install of R1709, and the problem is present immediately.

    5) In each case, I have tried using different driver versions for my integrated Intel I210 Ethernet adapters (Including 'latest' ones each time), different drivers for the internal Sierra Wireless cellular modem (Including 'Latest') and even changing the cellular modem to a different manufacturer (Huawei in this case) to try and eliminate any possible driver issues. Also, having the internal firewall on or off makes no difference.

    6) In each case, the problem experienced was identical (I get a 'General Failure' when 'pinging' from the command line, which smacks of an IP routing problem. The cellular interface IS still working/connected (Specifing that I/F as the source address for ICMP Pings allow me to ping the next pingable hop OK on that I/F, and this I/F is *still* the default gateway in the routing tables..)

    I have spent considerable time trying to find a work-around for this on the web, including reading the MS-Published documentation to try and identify the problem, which is where I discovered the 'Windows Connection Manager' feature. Since my topology is a little (But not very!) unusual (Using the cellular data interface as WAN with a gateway-less 'Stub' network on the Ethernet I/F), I tried disabling the WcmSvc..and things worked as expected.

    This strongly suggests a change in the behaviour or internal networking policies between R1703 and R1709 (And there have been some!) which has 'broken' things on my topology. I know I said it's a slightly unusual topology above, but it isn't really - 'Stubby' Ethernet networks are very common in the comms world and the OS *should* expect them - I can find several other people suffering from this on Technet and other forums, so it's NOT just me..

    What appears to be happening is that the OS is treating the connected Ethernet I/F as a higher-priority route than the cellular interface, despite - and this is important- the Ethernet I/F *not having a route to the internet*/gateway defined. The ONLY gateway defined in the routing tables is 0.0.0.0 via the cellular I/F, but the stack seems to ignore this and with no other gateway available we get the 'General Error'..:-(

    I'd be happy with this situation, provided I can find a way of configuring the OS to select the dynamic interface priorities/metrics they way I need them. No matter what I try with the WCM-Related Local Group Policies and/or per-interface metrics, plugging in an Ethernet (which is either on a 'Stub' network with a static IP address and no gateway defined, or one that is configured to obtain it's address from DHCP but ends up with a 'Link Local' address as there is no DHCP server reachable) is enough to 'break' internet connectivity.

    This is easy to reproduce - plug an Ethernet interface with the DHCP Client enabled into a 'dumb' ethernet switch/hub with nothing on the other switch/hub ports. This brings up the Ethernet PHY, but of course no DHCP server is available, so the I/F ends up with a 'Link-Local' address automatically.....same as a Static address definition with no gateway, really!

    I'm at a loss to explain why the Local group policy 'Minimise the number of simultaneous connections to the Internet or a Windows Domain'=Disabled trick didn't work..especially as RSOP and GPRESULT both show it in the 'correct' state.

    I'm currently still running with WCM Disabled for now, but as I shortly want to use one of the features that depend on WcmSvc, I'm looking for a solution to the root cause - which appears to be WCM/Routing decision issues in the OS..

    Any suggestions on how I should configure the OS/Feature set to avoid this issue?

    Tuesday, March 20, 2018 10:55 AM
  • 6) In each case, the problem experienced was identical (I get a 'General Failure' when 'pinging' from the command line, which smacks of an IP routing problem. The cellular interface IS still working/connected (Specifing that I/F as the source address for ICMP Pings allow me to ping the next pingable hop OK on that I/F, and this I/F is *still* the default gateway in the routing tables..)

    I would try using some PowerShell diagnostics to try to understand your problem symptom.  It would be more useful if you had two cases to consider, e.g. one working and the problem case.

    First, see if  Get-NetAdapter  -IncludeHidden  gives any clues.  Then, instead of ping or tracert which are both ICMP based, try PowerShell's new  Test-NetConnection  <destination>  HTTP   (I just found out not to use 8.8.8.8 as a "destination" for this example.  <w>)



    Robert Aldwinckle
    ---

    Wednesday, March 21, 2018 12:47 PM
  • Hi,

    I noticed that it worked fine in 1703, have you reinstalled 1709? Maybe there is something wrong with your system.

    Best Regards,

    Tao


    Please remember to mark the replies as answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    I have the same problem,

    A clean 1709 has the problem from the start. I can confirm. I already tried 4 different devices. with serveral simcards from different providers and with a huawei and a telit modem. Both with the stock Microsoft MBIM driver.

    This is related and this workarround   is a temporary fix

    regards


    vitalcc


    • Edited by vitalcc Wednesday, April 4, 2018 2:28 PM new info
    Tuesday, April 3, 2018 5:49 PM
  • Oh man finally someone that understands my pain! I'm getting similar behavior with VPN connections that redirect all traffic via the VPN interface (except for a /32 network for the VPN gateway to go over the regular Internet connection from the host). The 'soft disconnect' redirects traffic for the VPN gateway to go over the VPN connection, since the adapter looks like an 'ethernet' connection.

    I've noticed this behavior in 1511, but not 1703 (and I haven't upgraded to 1709 for a couple of reasons). The 'minimize number of Internet connections' didn't work for me either.

    The official MS line is that the adapter type designation is what sets the preference, but in most cases this is not settable by the end-user (you have to modify the driver inf which makes the signature invalid on the driver, so can't install in most cases).

    BTW, the command find-netroute is what gives the actual next-hop address will be, taking into account the soft-disconnect hidden behavior.

    I wish Microsoft allowed us to disable 'soft disconnect' by itself and force the OS to *always* follow the route table like a sane system should.

    Friday, April 27, 2018 4:32 PM
  • Same problem also for me. Only Microsoft can fix this issue. Pleas a MS, help us!  
    Thursday, May 3, 2018 7:09 PM
  • Windows April 2018 Update (1803) do not fix the issue … :-(
    Thursday, May 3, 2018 7:19 PM
  • I found a good solution in this thread:

    https://social.technet.microsoft.com/Forums/windows/en-US/e20c2af2-f2c1-419c-a2a3-cd2d07d8e699/network-problem-with-mbim-after-upgrading-windows-10-1709?forum=win10itpronetworking&prof=required

    Best regards

    • Marked as answer by Paul.T Thursday, November 1, 2018 7:19 PM
    Wednesday, May 9, 2018 3:10 PM
  • Count me in too.  I am using Dell Latitude 5414 Rugged laptops that have the internal cellular card.  I installed Windows 10 1709 and as soon as either an ethernet or wifi connection is made I am unable to ping the cellular interface - I just get a  general failure error.  I paid Microsoft support their $500 and they told me after months of waiting that they do not have a solution at this time...WTF?  I also called dell who told me it was a microsoft problem.

    I can also confirm that 1803 does not solve the problem either.  In my case I had to roll back to 1703.


    • Edited by Joef123456 Thursday, May 17, 2018 6:38 PM add more text.
    Thursday, May 17, 2018 6:37 PM
  • I found a good solution in this thread:

    https://social.technet.microsoft.com/Forums/windows/en-US/e20c2af2-f2c1-419c-a2a3-cd2d07d8e699/network-problem-with-mbim-after-upgrading-windows-10-1709?forum=win10itpronetworking&prof=required

    Best regards

    The linked thread has two possible solutions. Both require a registry edit.

    I can verify that the second solution works to bypass the issue in Windows 10 v1803.

    • Proposed as answer by ShockMichael Friday, October 12, 2018 9:50 PM
    Friday, October 12, 2018 9:48 PM