[Info-vax] FreeAXP loses network connectivity when laptop is woken up from "sleep"

[John Wallace]

On May 4, 10:10 am, John Wallace <johnwalla... at yahoo.co.uk> wrote:
> On May 3, 9:19 pm, presnyprek... at gmail.com wrote:
>
> > I have FreeAXP installed on a laptop. For networking I'm using a virtual NIC (OpenVPN) which is bridged with the laptop's real wired network interface.
>
> > When I boot up the laptop, then start FreeAXP, then boot VMS and start TCP/IP services, I can ping my ADSL router and servers on the Internet (e.g. 8.8.8.8).
>
> > If, however, I put the laptop to "sleep" (without shutting down VMS), after waking it up again VMS is still running (I can get the console back by telnetting to localhost:9000 using Putty) but it no longer has network connectivity. Sleep/wake cycling has no effect on the laptop's networking - just on VMS networking.
>
> > So far, the only way I found to get the network back (in VMS) by shutting down VMS and restarting FreeAXP.
>
> > Back in 2010, Hein reported the same problem (loss of network upon sleep/wake) but he could get it back by running "NET STOP MSICPAP" followed by "NET START MSIPCAP" in a DOS window. This doesn't work in my case. It says the service cannot be stopped. (Yes, I'm running the DOS window with Administrator privileges.) I'm assuming that's because FreeAXP is still running.
>
> > Once I completely stop FreeAXP and start it back up again, networking is back. But the idea is to get the networking back without having to restart VMS.
>
> > Any ideas greatly appreciated.
>
> > Nathan
>
> What Windows version is this? Can I guess Windows 7? [If the guess is
> wrong, sorry...]
>
> In which case I'll guess that at least part of this is OpenVPN
> related. Specifically, that something related to whatever driver is
> used to support loopback mode inside OpenVPN isn't doing quite the
> right thing when the system reinitialises its drivers after a sleep/
> standby followed by resume. A very very very quick glance at search
> results for "openvpn sleep standby" would appear to support a
> hypothesis that OpenVPN has an after-standby failure mode, and more
> specifically a failure mode that wasn't present in Windows XP but is
> present in Windows 7 (and also the dreaded Vista but I guess that's
> not relevant to this picture).
>
> See e.g.https://community.openvpn.net/openvpn/ticket/71where
> OpenVPN's failure to resume correctly after standby on Vista/Windows 7
> was reported 17 months ago and seemingly unresolved two months ago.
>
> IE try this on Windows XP and this failure mode may disappear. Or try
> eliminating OpenVPN by use a separate genuine dedicated NIC for
> FreeAXP somehow? [in a laptop? A NIC in a slot? A USB NIC? A wireless
> NIC?]
>
> For extra fun, run FreeAXP under a Windows instance under VMware using
> an emulated NIC so you don't actually need OpenVPN (guessing, of
> course, that VMware can cope correctly with standby/resume). Then when
> something works in a way different than you expect, try to guess which
> layer is responsible...
>
> Even if my guess re OpenVPN was right, I'm not willing to guess what
> will happen to FreeAXP when it's resumed after a period of standby.
> VMS itself *should* be able to do the right thing after what is
> effectively a powerdown and resume, but whether it's fair to expect
> this to work right when we don't know how FreeAXP presents these
> transitions to VMS is a bit moot.
>
> Best of luck anyway.

Couple of things I forgot (as often).

Item 1: The openvpn thread suggests a couple of workarounds.

Item 2: However, even if the workarounds do permit network traffic to
resume, there may be a bigger picture to think about, e.g. if you've
moved the laptop from one network to another while it's been asleep,
or if something else has changed e.g. DHCP leases have expired
(hopefully that shouldn't be a problem), what will happen to network
addresses, and what effect will that have on FreeAXP, and on VMS?

As others have also suggested, expecting this to generally work well
may be a bit unrealistic. You might find some cases where it can work.