Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Windows 8.1 hibernation problem
26-01-2014, 07:35 PM
Post: #1
Windows 8.1 hibernation problem
The control point stack doesn't survive system hibernation on Windows 8.1. The subnet and adapter change from the real adapter to the loopback adapter is detected correctly on entering hibernation, but the change back from the loopback adapter to the real adapter isn't detected when exiting hibernation.

This leaves ohNet in a broken state with access only to the loopback subnet. It seems to be necessary to restart ohNet to recover from this.

There is no problem on Windows 7. The subnet and adapter changes are detected correctly when entering hibernation and also when exiting hibernation.

For some reason, this problem affects only the control point stack, not the device stack. On Windows 8.1, the device stack detects the subnet and adapter changes when entering hibernation and also when exiting hibernation. Does this provide any clues?
Find all posts by this user
26-01-2014, 09:33 PM
Post: #2
RE: Windows 8.1 hibernation problem
Differing behaviours for control point and device stacks is surprising. They both update after the same OS notification. Can I check a couple of things:
  • How do you know that the control point stack is sticking to loopback? Similarly, how do you know the device stack is updating?
  • Is the device stack behaviour you see for an application running the device stack only or combined (device and control point stacks)? If it is device-only, is it running on a single subnet or all subnets?
Find all posts by this user
26-01-2014, 11:39 PM
Post: #3
RE: Windows 8.1 hibernation problem
(26-01-2014 09:33 PM)simonc Wrote:  How do you know that the control point stack is sticking to loopback? Similarly, how do you know the device stack is updating?

I have ohNet debug logs that show this for both cases. Would you like to see them?

Quote:Is the device stack behaviour you see for an application running the device stack only or combined (device and control point stacks)? If it is device-only, is it running on a single subnet or all subnets?

The correct device stack behaviour was for an application running the device stack only. It was running on all subnets.

I tried it with the device stack using a single subnet to see if that would make a difference. The subnet change was detected correctly when entering hibernation and when exiting hibernation.

I have just tried the control point stack again, and this time it worked OK. This suggests some kind of race condition. The problem was originally reported by a MinimServer user, and I repeated it myself to confirm it.

I will ask the user to repeat this a few times to see whether it works for him on some occasions.
Find all posts by this user
27-01-2014, 09:25 AM
Post: #4
RE: Windows 8.1 hibernation problem
(26-01-2014 11:39 PM)simoncn Wrote:  I have just tried the control point stack again, and this time it worked OK. This suggests some kind of race condition.

The race condition could be between the order in which the resumption from hibernation reactivates the network connection and reactivates the ohNet application. If the network connection is reactivated first, the ohNet InterfaceChangeThread might not receive the Windows event that notifies an adapter change.

If this happens, it would be good to give the user the ability to manually refresh the interface list. Is there an ohNet API to do this?
Find all posts by this user
27-01-2014, 10:35 AM
Post: #5
RE: Windows 8.1 hibernation problem
(27-01-2014 09:25 AM)simoncn Wrote:  If this happens, it would be good to give the user the ability to manually refresh the interface list. Is there an ohNet API to do this?

You could try calling Library.notifyResumed(). I haven't tried this for the device stack but it should do what you need.
Find all posts by this user
27-01-2014, 11:32 AM
Post: #6
RE: Windows 8.1 hibernation problem
(27-01-2014 10:35 AM)simonc Wrote:  You could try calling Library.notifyResumed(). I haven't tried this for the device stack but it should do what you need.

Is it OK to call this for both the control point stack and the device stack? I have only seen this problem on the control point stack so far, but I suppose it could happen with the device stack as well. I will try this (with both stacks) to see what happens.
Find all posts by this user
27-01-2014, 11:46 AM
Post: #7
RE: Windows 8.1 hibernation problem
(27-01-2014 11:32 AM)simoncn Wrote:  
(27-01-2014 10:35 AM)simonc Wrote:  You could try calling Library.notifyResumed(). I haven't tried this for the device stack but it should do what you need.

Is it OK to call this for both the control point stack and the device stack? I have only seen this problem on the control point stack so far, but I suppose it could happen with the device stack as well. I will try this (with both stacks) to see what happens.

The code should work for device stacks but has only been tested with control point so far. If you give it a go, I'll fix any issues that crop up.
Find all posts by this user
28-01-2014, 10:23 AM
Post: #8
RE: Windows 8.1 hibernation problem
(27-01-2014 11:46 AM)simonc Wrote:  The code should work for device stacks but has only been tested with control point so far. If you give it a go, I'll fix any issues that crop up.

I've added this call as part of the manual refresh operation for the control point (MinimWatch). It works OK (I see "Subnet changed" in the log), but I haven't been able to confirm that it fixes the original problem with resumption from hibernation because I've been unable to reproduce this problem recently. I will ask the user who reported the original problem to try the fix and see if it fixes the problem for him.

On the device side (MinimServer), there's currently no manual refresh operation and I don't have a way to detect resumption from hibernation, so I haven't tried calling this on the device stack.
Find all posts by this user


Forum Jump: