DonationCoder.com Forum

DonationCoder.com Software => Coding Snacks => Post New Requests Here => Topic started by: techidave on December 15, 2010, 09:17 PM

Title: IDEA: Wireless sensor
Post by: techidave on December 15, 2010, 09:17 PM
I have searched some online trying to find something already made up but have come up empty.  So I have an idea for a coding snack but I do not know if it is possible or not.  But here goes.   :)

In a school setting with laptops, students sometimes get anxious to log into the network but find they cannot because the wireless card hasn't fully come online, etc, etc.

So what I have envisioned is this:  To have a green dot (large one) say in the upper right corner if it senses a wireless connection or a red dot in the upper left corner if their isn't.  It would also have to check, say every 5 seconds to see if the connection status has changed.  Or it could change the whole desktop a different color for that matter.

It would have to become active before the user logged in.  I haven't found a way to see if their is a active connection without being at the desktop.

Is it possible to do something like this??? 
Title: Re: IDEA: Wireless sensor
Post by: skwire on December 16, 2010, 07:12 AM
1) Is the wireless NIC its only connection to the network?
2) If so, is there a network address on the network that is always pingable (gateway, etc.)?
Title: Re: IDEA: Wireless sensor
Post by: techidave on December 16, 2010, 07:20 AM
Yes to both questions. 
Title: Re: IDEA: Wireless sensor
Post by: Stoic Joker on December 16, 2010, 07:31 AM
Pinging might get blocked by an over zealous firewall. But if the adapters were scanned for a DGW, the DGW could then be ARP'ed. If the ARP call came back with a valid result connected = true.

Firewalls won't affect ARP, and nothing needs to be hardcodded so it'll work anywhere.


Here's a ARP call/test in C++ It took me weeks to figure this out (because everything I Googled said it couldn't be done):
Code: C++ [Select]
  1. //======================================================================================================
  2. //======================================================================== Hay MAC, WTFs Your Address...?
  3. bool GetMACAddress(char *szIPAddr, char *szMAC) { //=====================================================
  4.     ULONG   DestMAC[2],ulLen = 6;
  5.         LPBYTE  lpBuff;
  6.  
  7.   memset(DestMAC, 0xff, sizeof (DestMAC));
  8.   if(SendARP(inet_addr(szIPAddr), 0, DestMAC, &ulLen) == NO_ERROR) {
  9.           lpBuff = (LPBYTE)DestMAC; // Now Convert - Address to a String.
  10.          StringCbPrintf(szMAC, GEN_BUFF, "%02X:%02X:%02X:%02X:%02X:%02X",
  11.                                         lpBuff[0], lpBuff[1], lpBuff[2], lpBuff[3], lpBuff[4], lpBuff[5]);
  12.    return TRUE;
  13.   }
  14.   // <-- IF False, Then the Target is on a Different Subnet and is therefore out of (ARP Required)
  15.   StringCbCopy(szMAC, GEN_BUFF, "Not in ARP Table"); // <------------- Broadcast Range ... Say So!
  16.   // <------------------------- Note: This Was Added as Part of Build 88 to v1.0.0 <--++++---<<<<<
  17.  return FALSE;
  18. }
Title: Re: IDEA: Wireless sensor
Post by: techidave on December 16, 2010, 07:33 AM
not sure what your little program means but one school has about 60 laptops that this would need to be done with.
Title: Re: IDEA: Wireless sensor
Post by: Stoic Joker on December 16, 2010, 08:30 AM
not sure what your little program means but one school has about 60 laptops that this would need to be done with.
-techidave (December 16, 2010, 07:33 AM)

It's just a snippet of code for doing an APR check on/for a given IP address. I thought it might help skwire if he was inclined to go that route for the app. SendARP(...) is a standard call but it was incredibly hard to find back when I went looking for a method of getting MAC addresses for Page Countster.
Title: Re: IDEA: Wireless sensor
Post by: techidave on December 16, 2010, 08:33 AM
I may not be following you SJ, but what I need is something that the student can see on the laptop.
Title: Re: IDEA: Wireless sensor
Post by: skwire on December 16, 2010, 09:41 AM
It would have to become active before the user logged in.
-techidave (December 15, 2010, 09:17 PM)

I can do everything except this since something like that requires the app to function as a service (something I don't know how to code).
Title: Re: IDEA: Wireless sensor
Post by: 4wd on December 16, 2010, 10:23 AM
As skwire said, you need a service to be able to do this before the user logs in - something I might be able to manage since the building blocks are there in AutoIt.

But is it really necessary since you can execute programs on login?

EDIT: Removed code and attachments to avoid confusion with later post.


Sorry to butt into your thread skwire, it's 0325 here and I was bored :D
Title: Re: IDEA: Wireless sensor
Post by: skwire on December 16, 2010, 11:15 AM
Sorry to butt into your thread skwire, it's 0325 here and I was bored
-4wd (December 16, 2010, 10:23 AM)

Please!  By all means...the more at the party, the better.   :D
Title: Re: IDEA: Wireless sensor
Post by: techidave on December 16, 2010, 11:21 AM
Yes I believe it is necessary 4wd.  This all needs to happen before the login.  We use the login window that you would use to login to a domain.  Can't remember what that type of login is called. 

Students typically turn a computer on and as soon as the login window appears, they try to log in.  Well some of our laptops take just a little longer for the wireless card to iniate, or become fully operational.  But in the mean time they can not log in because they cannot see the server.  We have multiple users using them, and they are always connected via wireless. 

They just need some kind of a "signal" telling them "when" they could log in.
Title: Re: IDEA: Wireless sensor
Post by: techidave on December 16, 2010, 11:26 AM
just re-read of 4wd post, maybe having something that would show down in the tray would be good too!  But I would want the other too.   :D

Title: Re: IDEA: Wireless sensor
Post by: Stoic Joker on December 16, 2010, 02:53 PM
I may not be following you SJ, but what I need is something that the student can see on the laptop.
-techidave (December 16, 2010, 08:33 AM)

Understood, I was speaking more to the how than the what. Actually it should be a service that flags the user that the connection is active and then shut itself down to avoid unnecessary resource usage. <But I'm wandering off my own point>

Here is the thing, with network utilities the tempting easy out it to shoot for (/with) ping, but... It ain't actually that easy. If you use the default MS .dll based ping the fastest you can reliably recover between pings (to a dead connection) is about 30 seconds. If you want really fast ping recovery times (like 5 sec or less) you will need to use raw socket ICMP so you can customize the socket to respond (live/die/connect/close) quickly.

This is why I am/was suggesting a way around that using a method of monitoring the LM adapter for a default gateway of something other than blank or 0.0.0.0 and then verifying that it is up/active with an ARP test. These can both be done very fast without causing other issues like hung sockets, desktop handle (leaks/) exaustion, or logs full of half open socket errors.

It would also make it possible to be used universally as the target would not need to be hard coded using this method as it is just iterating through the local adapters looking for one with an active gateway. Then it gives the go-ahead and shuts down.

Honestly I wish I had time to jump in on this - I love doing this kind of stuff. I've got a working Windows Service template project in C++ for MSVS2k5 ... If it'll help let me know I'd be happy to post it when I get home. Hell its even includes self install & uninstall functions iirc.
Title: Re: IDEA: Wireless sensor
Post by: 4wd on December 16, 2010, 05:55 PM
Students typically turn a computer on and as soon as the login window appears, they try to log in.  Well some of our laptops take just a little longer for the wireless card to iniate, or become fully operational.  But in the mean time they can not log in because they cannot see the server.  We have multiple users using them, and they are always connected via wireless.  

They just need some kind of a "signal" telling them "when" they could log in.
-techidave (December 16, 2010, 11:21 AM)

OK, I'll have a look at making it into a service - I had a play with this kind of thing, (AutoIt services), a year or so ago when I was creating a desktop background changer to annoy a friends daughter  >:D

Personally, the onscreen indicator would drive me nuts because it would always be in the way of something but I now see where you're coming from with the need for an indicator on the login screen.  I just don't know if I'll be able to put one on the login screen, if I can I may be able to have it autohide down to the SysTray, (as it is now), when someone logs in.

Might take me a few days, I've got to do some gardening, junk removal and revisit AutoIt scripts, (and most likely the forums a lot).  And probably annoy skwire endlessly with questions.  ;D

Oh yeah, if I do manage it the first comment about my lack of coding style will win a brick  :P

Addendum: In the meantime, check out CNS (http://home.pacbell.net/nhoize/CNS.html) which can display computer info on the login screen.  I don't know if it'll do what you want though or even if it works on anything later than W2000.  Hasn't been updated since 2001 but it's possible the author might still be willing to put something like a simple indicator as an option - or since it displays the IP and if your network is DHCP based, (not static), tell the students to wait until it display something other than 169.254.x.x.
Title: Re: IDEA: Wireless sensor
Post by: techidave on December 16, 2010, 08:28 PM

Personally, the onscreen indicator would drive me nuts because it would always be in the way of something but I now see where you're coming from with the need for an indicator on the login screen.  I just don't know if I'll be able to put one on the login screen, if I can I may be able to have it autohide down to the SysTray, (as it is now), when someone logs in.

oh yeah we probably would want to hide it after they logged in.   :-[

Title: Re: IDEA: Wireless sensor
Post by: techidave on December 16, 2010, 08:36 PM
4wd, I will look at the CNS in the morning.  I  actually have a laptop with a new XP install that I can try it on.  I can always reghost it if things go south on me.

Joker, I am not sure what your template is like but am willing to give it a whirl.

To answer a previous post, yes I can have it ping a firewall or whatever.

All of our laptops are on DHCP.
Title: Re: IDEA: Wireless sensor
Post by: 4wd on December 17, 2010, 06:35 AM
techidave, could you tell me what OS' the laptops are running, (XP, Vista, Home, Pro, etc) ?

Getting it to actually display something on the logon screen might be a right b!tch  :wallbash:
Title: Re: IDEA: Wireless sensor
Post by: Stoic Joker on December 17, 2010, 07:02 AM
Joker, I am not sure what your template is like but am willing to give it a whirl.
-techidave (December 16, 2010, 08:36 PM)

The template is just the source code for a roll-your-own Windows System Service. The compiled version in the download just beeps every X seconds (which isn't really useful in and of itself). But (it's a demo) the included source code is a complete (self installing & uninstalling) Windows service framework which is well commented to make it easy to modify for other purposes. Just replace the beep code and variables with the work & values needed, compile, and you're done.

[ You are not allowed to view attachments ]

@4wd - IIRC, all the service will need is the interact with desktop right which is configurable (if need be) in Services.msc
Title: Re: IDEA: Wireless sensor
Post by: 4wd on December 17, 2010, 04:54 PM
Thanks SJ, I was hoping not to have to make it a service and use the Group Policy Editor to specify a Startup script - which should mean it's running before a user logs in and is a bit nicer installation-wise.

Of course you need the Pro versions of Windows to get the Group Policy Editor and it seems to run OK this way except for a lack of SysTray icon when explorer.exe finally comes up.

EDIT: I've modified the AutoIt script above because my check for ARP output was too long, (only 20 chars output compared to wired), for wireless and it also includes a simple check for explorer.exe, which isn't running before logon, to swap between a Tooltip in the upper left corner and a SysTray icon.

It's had a name change to NetCheck.

Status at the moment:
1) Runs at Startup.
2) Displays a Tooltip on the logon screen with network status - I can't test whether it has connected since it doesn't connect until I've logged on here, (just a LAN network).
3) Hotkey exit, (currently Shift+Alt+\), which can be set in the ini file.
4) Detects whether Explorer.exe is running and turns off the Tooltip - ie. user has logged in.

The only thing left is trying to get the SysTray icon to turn on - maybe I need to put a delay in between detection of explorer.exe and turning it on?  Ideas anyone?

Just had a thought, I couldn't find anywhere after a quick search, what is set as the default directory when you run something from Group Policy Startup?  The directory where the executable is or something else?

Anyway, it looks favourable except for the icon at the moment, so if you can get by without it then I guess it can be considered working.  Although it's really going to urk me if I can't find the problem, (the technician coming to the fore  >:( ).

EDIT2: Argh!  The Tooltip doesn't come back when you log off  :wallbash:
Title: Re: IDEA: Wireless sensor
Post by: Stoic Joker on December 17, 2010, 10:25 PM
2) Displays a Tooltip on the logon screen with network status - I can't test whether it has connected since it doesn't connect until I've logged on here, (just a LAN network).
-4wd (December 17, 2010, 04:54 PM)

I could be missing something, but couldn't you just start the comp with the network cable unpluged, then plug it in to see the status change? The media connection state change is (basically) the same wired vs. WiFi.

The only thing left is trying to get the SysTray icon to turn on - maybe I need to put a delay in between detection of explorer.exe and turning it on?  Ideas anyone?
-4wd (December 17, 2010, 04:54 PM)

The following snippet is from T-Clock, it checks for a valid system tray/clock window handle before the hook is inserted. A stripped down version should be just what you're after:
Code: C++ [Select]
  1. // find the clock window
  2.   hwndChild = GetWindow(hwndBar, GW_CHILD);
  3.   while(hwndChild) {
  4.                 GetClassName(hwndChild, classname, 80);
  5.                 if(lstrcmpi(classname, "TrayNotifyWnd") == 0) {
  6.                    hwndChild = GetWindow(hwndChild, GW_CHILD);
  7.                    while(hwndChild) {
  8.                                  GetClassName(hwndChild, classname, 80);
  9.                                  if(lstrcmpi(classname, "TrayClockWClass") == 0) {
  10.                                         SendMessage(hwndChild, WM_NULL, 0, 0);
  11.                                         break;
  12.                                  }
  13.                    } break;
  14.                 }
  15.          hwndChild = GetWindow(hwndChild, GW_HWNDNEXT);
  16.   }

Actually this might be the shorter way you need:
Code: C++ [Select]
  1. // refresh the taskbar
  2.   hwnd = FindWindow("Shell_TrayWnd", NULL);
  3.   if(hwnd) {
  4.          PostMessage(hwnd, WM_SIZE, SIZE_RESTORED, 0);
  5.          InvalidateRect(hwnd, NULL, TRUE);
  6.   }

...If tray handle is valid, you're gold.


Just had a thought, I couldn't find anywhere after a quick search, what is set as the default directory when you run something from Group Policy Startup?  The directory where the executable is or something else?
-4wd (December 17, 2010, 04:54 PM)

Something tells me I should know that...  :-[ ...Just use full path in script as it tends to be safer anyhow.

EDIT2: Argh!  The Tooltip doesn't come back when you log off  :wallbash:
-4wd (December 17, 2010, 04:54 PM)

Relaunch with logoff script?

Actually, after the machine has been logged on and then off, you really don't need a status indicator...If the users are told not to try logging in when the logon-not-available light is lit.
Title: Re: IDEA: Wireless sensor
Post by: 4wd on December 17, 2010, 11:02 PM
2) Displays a Tooltip on the logon screen with network status - I can't test whether it has connected since it doesn't connect until I've logged on here, (just a LAN network).
-4wd (December 17, 2010, 04:54 PM)

I could be missing something, but couldn't you just start the comp with the network cable unpluged, then plug it in to see the status change? The media connection state change is (basically) the same wired vs. WiFi.
-Stoic Joker (December 17, 2010, 10:25 PM)

DOH!  I was testing it with the WiFi on the netbook, completely forgot about the wired connection.  :-[

However, it doesn't seem to work - I'm wondering, with a Domain Controller doesn't a network connection have to be established before logon, whereas with a normal LAN network the connection is established after logon?

Have to do some debug output to see if the arp command is actually being called that early.

The following snippet is from T-Clock, it checks for a valid system tray/clock window handle before the hook is inserted. A stripped down version should be just what you're after:

Check for the Tray, I'm afraid that's way too obvious.  Thanks for that SJ - I should just let you carry on writing it :P

EDIT2: Argh!  The Tooltip doesn't come back when you log off  :wallbash:
-4wd (December 17, 2010, 04:54 PM)

Relaunch with logoff script?

Yes, a definite possibility - check for already existing process and kill it if necessary, thanks again.

Right, back to the drawing board.

Addendum: I've found an AutoIt routine equivalent to your GetMAC C snippet above, so I can get rid of the dependence on the arp command.
Title: Re: IDEA: Wireless sensor
Post by: techidave on December 18, 2010, 06:19 AM

Quote: However, it doesn't seem to work - I'm wondering, with a Domain Controller doesn't a network connection have to be established before logon, whereas with a normal LAN network the connection is established after logon?



No, it doesn't have to.  By default, the answer is no.  There is a policy that can be set by using group policy or active directory.  I have tried changing it to wait, but that doesn't always help either.
Title: Re: IDEA: Wireless sensor
Post by: Stoic Joker on December 18, 2010, 10:12 AM
However, it doesn't seem to work - I'm wondering, with a Domain Controller doesn't a network connection have to be established before logon, whereas with a normal LAN network the connection is established after logon?
-4wd (December 17, 2010, 11:02 PM)

[Sorry if I get a bit Captain Obvious here, I'm just trying to make sure we're on the same page]

Um... If you're driving at the distinction between a Workgroup and Domain networks ...Then yes...Sort of. In a workgroup environment you initially authenticate to local machine, and then to network resources later if/when you access them. In a domain you're authenticated by the domain controller before you access anything, including local machine. There are exceptions for cached credentials/domain accounts...But those aren't important right now.

The key here is to look for a media connection first, then "verify" it by testing for an IP connection. So the program should continue looping through the adapter iteration until it finds one with a default gateway that isn't 0.0.0.0. Then and only then it should do the (IP to MAC Address) ARP lookup to verify that the IP network is "live" making it a relatively safe assumption that (the hounds can be released) a domain controller is then available.


Have to do some debug output to see if the arp command is actually being called that early.
-4wd (December 17, 2010, 11:02 PM)

We use domain/machine names, the OS uses IP addresses, and the hardware uses MAC addresses. Nothing leaves the box without the MAC address of its (first hop) destination being known. So as long as some/any communication attempt has been made with the default gateway the MAC address will be known ... Shit...

(Does anybody else see the hole in this theory?)...

Hint: Gateway connection isn't really required or guaranteed at this stage, hence the ARP test could fail even with a valid connection because no traffic has as of yet been sent to the gateway. SendARP(...) is a local machine query of the ARP cache, not an on-the-wire query for remote data.

...Which makes me an idiot. :wallbash: Sorry... :-[  ...Ping would (/will have to) be the correct answer as a last stage validation of IP connectivity. Just don't start with it in/as the initial loop timeouts are a nightmare.
Title: Re: IDEA: Wireless sensor
Post by: 4wd on December 18, 2010, 08:53 PM
No, it doesn't have to.  By default, the answer is no.  There is a policy that can be set by using group policy or active directory.  I have tried changing it to wait, but that doesn't always help either.
-techidave (December 18, 2010, 06:19 AM)

[Sorry if I get a bit Captain Obvious here, I'm just trying to make sure we're on the same page]
-Stoic Joker (December 18, 2010, 10:12 AM)

That's OK, be as Captain Obvious as you like :)   I've zero experience with anything other than a "normal" LAN setup, (ie. anything more than you'd find in a home).

Um... If you're driving at the distinction between a Workgroup and Domain networks ...Then yes...Sort of. In a workgroup environment you initially authenticate to local machine, and then to network resources later if/when you access them. In a domain you're authenticated by the domain controller before you access anything, including local machine. There are exceptions for cached credentials/domain accounts...But those aren't important right now.

The key here is to look for a media connection first, then "verify" it by testing for an IP connection. So the program should continue looping through the adapter iteration until it finds one with a default gateway that isn't 0.0.0.0. Then and only then it should do the (IP to MAC Address) ARP lookup to verify that the IP network is "live" making it a relatively safe assumption that (the hounds can be released) a domain controller is then available.

Using the DOS 'arp -a' gave 'No ARP.......' when testing the wireless connection on my netbook, whether it was connected or not - same with it's wired connection.  So I switched to using 'ipconfig' and just parse it's output for the gateway IP and that seems to work OK but that can be manually set of course, so doesn't guarantee connectivity.

Hint: Gateway connection isn't really required or guaranteed at this stage, hence the ARP test could fail even with a valid connection because no traffic has as of yet been sent to the gateway. SendARP(...) is a local machine query of the ARP cache, not an on-the-wire query for remote data.

...Which makes me an idiot. :wallbash: Sorry... :-[  ...Ping would (/will have to) be the correct answer as a last stage validation of IP connectivity. Just don't start with it in/as the initial loop timeouts are a nightmare.

...and this is what my experimentation with both the DOS 'arp -a' and the AutoIt SendARP routine seems to bear out - so as you've said, it looks like a fallback to Ping as being the 'best' solution.

And I think I'll have to create it as a service because I believe that's the reason I can't get it to stick an icon in the SysTray when the user logs in or display ToolTips when they log off - no interaction with the Desktop.

As of right now, I'm just trying to make sure the network detection works 100% - then comes the service part which should be easier.....famous last words.

Thanks guys, if nothing else it's an adventure :)

@techidave: Can you tell me if there are any servers on your network, (Web, Mail, DNS, etc), that are on 24/7 that would normally be contactable from the laptops?
Reasoning: I'm trying to avoid having to use external programs, (eg. Ping, Arp, etc), it saves me having to parse intermediate output files and AutoIt provides a TCPConnect function which will fail if it's unable to connect to a server, (any server), it just needs an IP and port to try and connect to - for that matter I suppose I could just try connecting to Googles' DNSs, (works here), for a test and make it configurable in the ini file.
Title: Re: IDEA: Wireless sensor
Post by: 4wd on December 19, 2010, 10:43 PM
Here's the current NetCheck program that seems to work reasonably well here on my netbook with both wired and wireless connection, it requires use of Group Policy Editor and as such it's restricted to Pro+ versions of Windows - I've only tested it on XP Pro SP3.

Caveat: Currently it doesn't reinitialise itself to display on the logon screen if the current user logs off - that's about it.  I'm still looking at fixing this by calling it again, (probably needs higher privileges so it can display on the logon screen again).

[Select]
#NoTrayIcon
#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_UseX64=n
#AutoIt3Wrapper_Res_Icon_Add=On.ico
#AutoIt3Wrapper_Res_Icon_Add=Off.ico
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****

Global $inifile = @WindowsDir & "\NetCheck.ini"

If Not FileExists($inifile) Then _Initialise()
$TIP=IniRead($inifile,"Main","TestServer","8.8.8.8")
$TPort=IniRead($inifile,"Main","TestPort","53")
$TTime=IniRead($inifile,"Main","TimeOut","100")
$HotKey=IniRead($inifile,"Main","Hotkey","+!\")

HotKeySet($HotKey, "_Exit")

If $CmdLine[0] > 0 Then
Select
Case $CmdLine[1] = "logon"
$logon = 1
Case $CmdLine[1] = "startup"
$logon = 0
Case Else
EndSelect
Else
$logon = 0
EndIf


Opt('TCPTimeout', $TTime)
TCPStartup()

If $logon Then TraySetState()

While 1
If (ProcessExists("explorer.exe") > 0) And (Not $logon) Then ExitLoop
$socket = TCPConnect($TIP, $TPort)
If $socket = -1 Then
If $logon Then
TraySetIcon(@ScriptName, -6)
TraySetToolTip("Network disconnected!")
Else
ToolTip("Not Connected", 0, 0,"Network Status", 3, 5)
EndIf
Else
TCPCloseSocket($socket)
If $logon Then
TraySetIcon(@ScriptName, -5)
TraySetToolTip("Network connected")
Else
ToolTip("Connected", 0, 0,"Network Status", 1, 5)
EndIf
EndIf
Sleep(5000)
WEnd

Func _Exit()
TCPShutdown()
Exit
EndFunc

Func _Initialise()
IniWrite($inifile, "Main", "TestServer", "8.8.8.8")
IniWrite($inifile, "Main", "TestPort", "53")
IniWrite($inifile, "Main", "TTime", "100")
IniWrite($inifile, "Main", "Hotkey", "+!\")
$file = FileOpen($inifile, 1)
FileWrite($file, @CRLF & "; Where: TestServer = IP address of a server to make a test connection to." & @CRLF & ";        TestPort   = Server port to make a test connection to." & @CRLF & ";        TimeOut    = Test connection timeout value in milliseconds.  Test will" & @CRLF & ";                     fail if it can't make a connection in this time." & @CRLF & ";        Hotkey     = Key sequence to terminate program." & @CRLF & ";                             + = Shift" & @CRLF & ";                             ! = Alt" & @CRLF & ";                             ^ = Control" & @CRLF & ";                             # = Windows")
FileClose($file)
EndFunc

To set it up, copy it to both of the following directories, (not really required in two locations, just makes the script dialogue easier later):

C:\Windows\System32\Group Policy\Machine\Scripts\Startup
C:\Windows\System32\Group Policy\User\Scripts\Logon

Run the Group Policy Editor, (eg. Start->Run->gpedit.msc):

[ You are not allowed to view attachments ]

Specify a Windows Startup script as follows:

[ You are not allowed to view attachments ]

and a User Logon script as follows, (Note the 'logon' parameter):

[ You are not allowed to view attachments ]

On first run it will create the file C:\Windows\NetCheck.ini for which the defaults are:

[Main]
TestServer=8.8.8.8
TestPort=53
TimeOut=100
Hotkey="+!\"

It'll try connecting to Googles' DNS server, if it doesn't make a connection within 100ms it assumes there's no access.  You can change it to use your local DHCP server, (port 67 by default), since that's where your laptop IPs come from.
It only reads from the file upon execution, so if you make a change you need to stop then start it again.   You can run it from the CLI - just remember to add the 'logon' parameter since you'll be logged in.
Nothing bad will happen if you forget, it'll just exit immediately because it sees the explorer.exe process.

You can kill it either by right-clicking on the tray icon and selecting Exit, or the default hotkey combination of Shift+Alt+\ .

It still only tries to connect every 5 seconds, I didn't see a need to make it any faster.

The ini file is the only thing it writes to the drive, the tray icons are stored in the exe - I've only added them to the archive in case you want to do some fiddling and recompile.

In theory, if all goes well, on the next reboot you should end up with:
[ You are not allowed to view attachments ]

And after log on:
[ You are not allowed to view attachments ]


Still thinking of trying to make it a service but I couldn't get it to interact with the Desktop - installed and ran OK, was getting all the right answers just didn't display anything - more reading required me thinks.
Title: Re: IDEA: Wireless sensor
Post by: techidave on December 20, 2010, 06:45 AM
Thanks 4wd, I have downloaded it. 

At one of my schools, there is mail and dns that are available internally that are on all the time. 

At another school, we use an external dns there.  However, there are several servers that are available 24/7.

forgive me for not using the quote feature, I seem to be having a senior moment(s) on how it works.  :-[

But 4wd, you said to copy "it", what is "it"?  In the zip file, I only see 5 files of which one is the netcheck.exe.  perhaps that is it?

Title: Re: IDEA: Wireless sensor
Post by: techidave on December 20, 2010, 07:16 AM
AVG just caught it as a virus.  I am sure that there isn't one.  Probably just the autoit script?
Title: Re: IDEA: Wireless sensor
Post by: techidave on December 20, 2010, 07:58 AM
I have joined my domain but now it takes forever to "run the startup script".  Like 5 or 6 minutes.



Title: Re: IDEA: Wireless sensor
Post by: techidave on December 20, 2010, 01:33 PM
I just was playing around with it and discovered that it doesn't work if one just logs off, closes the lid on the laptop, and then opens it up again.  It would be nice because when I just logged in again, the wireless wasn't active so my desktop folder re-direction didn't work.  A simple refresh fixes this.  But my users (student and teachers) don't remember that this can be done.

So the short question is can the icon show up any other time the login window is there without doing a restart or power on?
Title: Re: IDEA: Wireless sensor
Post by: 4wd on December 20, 2010, 05:32 PM
But 4wd, you said to copy "it", what is "it"?  In the zip file, I only see 5 files of which one is the netcheck.exe.  perhaps that is it?
-techidave (December 20, 2010, 06:45 AM)

Yes, sorry, just copy the NetCheck.exe file to the two locations.

AVG just caught it as a virus.  I am sure that there isn't one.  Probably just the autoit script?
-techidave (December 20, 2010, 07:16 AM)

Possibly because AutoIt packs it with UPX by default - attached is a non-packed version.  Try that, if it still complains then the only thing I can think of is because it writes an ini file to the Windows directory - which seems a bit to militant for a anti-virus program - if so, then I can change from an ini file to all command line arguments.

I have joined my domain but now it takes forever to "run the startup script".  Like 5 or 6 minutes.
-techidave (December 20, 2010, 07:58 AM)

Here it only takes a few seconds to run it, the tooltip shows up after the login screen, however it looks like you're using the 'classic' login screen and not the newer XP Welcome type - something that I ought to of thought of but didn't  :-[    So a bit more testing.

EDIT: Just tried again with classic logon and it works OK here.  The logon prompt shows up immediately with tooltip showing up a few seconds later, both when there is and isn't a connection.  The NetCheck.exe should return immediately, (well, it does from a normal CLI), I wonder if it's possible to try running with the RunAs command, (sorry, no experience with that - perhaps SJ can help)?

I don't suppose anyone could tell me how to set up a simple Domain that I could try and replicate this with, (I can set up another laptop as a Domain Controller under XP Pro)?

Caveat: Currently it doesn't reinitialise itself to display on the logon screen if the current user logs off - that's about it.  I'm still looking at fixing this by calling it again, (probably needs higher privileges so it can display on the logon screen again).
-4wd (December 19, 2010, 10:43 PM)

So the short question is can the icon show up any other time the login window is there without doing a restart or power on?
-techidave (December 20, 2010, 01:33 PM)

That's what I'm still looking at fixing ;)
Title: Re: IDEA: Wireless sensor
Post by: techidave on December 20, 2010, 06:25 PM
yeah, the tool tip shows up really quickly too.  I am not sure why the script takes so long to process. 

I am not much of a server guy, even though I do manage some.  So I am probably not the one to ask how to setup a domain.  We have a 3rd party source that I use for the more complicated stuff.

I would think would need Windows 2003 Server or some other server version.  Probably would have to setup Active Directory too.

I cannot wait to try this at the other school since they are on Novell 6.5.  that is where the login problems are more severe since they have continual network problems.  Too much stuff that seems to affect a lot of stuff.  but we will make a big dent in a lot of those problems during the holidays.
Title: Re: IDEA: Wireless sensor
Post by: Stoic Joker on December 20, 2010, 10:02 PM
I have joined my domain but now it takes forever to "run the startup script".  Like 5 or 6 minutes.
-techidave (December 20, 2010, 07:58 AM)

Here it only takes a few seconds to run it, the tooltip shows up after the login screen, however it looks like you're using the 'classic' login screen and not the newer XP Welcome type - something that I ought to of thought of but didn't  :-[    So a bit more testing.
-4wd (December 20, 2010, 05:32 PM)

When Joined to a domain XP & Vista always use the "Classic" logon GINA (Graphical Identification & Network Authorization) interface, The psudo Home Screen styled Other User option for domain members is new for 7. <-Completely off topic, but I thought I'd mention it.)

Does 5 or 6 minutes sound about right for the WiFi card init? I'm wondering if the script is waiting for the program to return. If the ping is every 5 sec, can you (just as a test value) add a sending ping X message to the prog so it's "pulse" can be checked?


EDIT: Just tried again with classic logon and it works OK here.  The logon prompt shows up immediately with tooltip showing up a few seconds later, both when there is and isn't a connection.  The NetCheck.exe should return immediately, (well, it does from a normal CLI), I wonder if it's possible to try running with the RunAs command, (sorry, no experience with that - perhaps SJ can help)?
-4wd (December 20, 2010, 05:32 PM)

This is one of those points where things get fuzzy. Disconnected is easy, and fully connected is easy, however, partially connected (like the not entirely initialized WiFi card) is a bitch. This is where socket behavior goes completely to shit without extreemly robust error checking. If the (above mentioned) ping X message test only counts to 1 in the 5 min script run time ... That would be a WSACleanup(...) on isle 5 after a partially fragged socket mess.


I don't suppose anyone could tell me how to set up a simple Domain that I could try and replicate this with, (I can set up another laptop as a Domain Controller under XP Pro)?
-4wd (December 20, 2010, 05:32 PM)

Active Directory Domain Controller requires Windows server (2k, 2k3, 2k8). But it's the media/network connection's behavior that's the issue, not the logon behavior.

Now if you put the wrong WEP key in your WiFi card and let it partially connect, DHCP should fail leaving you with an APIPA address and roughly the state you need to test with/for/on.

Caveat: Currently it doesn't reinitialise itself to display on the logon screen if the current user logs off - that's about it.  I'm still looking at fixing this by calling it again, (probably needs higher privileges so it can display on the logon screen again).
-4wd (December 19, 2010, 10:43 PM)

Running it on logoff isn't really the issue, because the WiFi card stays on. The trick is to get it to run on wakeup from sleep/hibernation when the connection has dropped because the WiFi card was napping.
Title: Re: IDEA: Wireless sensor
Post by: techidave on December 20, 2010, 10:38 PM

Does 5 or 6 minutes sound about right for the WiFi card init? I'm wondering if the script is waiting for the program to return. If the ping is every 5 sec, can you (just as a test value) add a sending ping X message to the prog so it's "pulse" can be checked?
-Stoic Joker (December 20, 2010, 10:02 PM)

That sounds a bit long for this particular card.  Cannot remember all the details but it is an older Intel 2210 something.  I know its not a 54g card just 54 a/b.


EDIT: Just tried again with classic logon and it works OK here.  The logon prompt shows up immediately with tooltip showing up a few seconds later, both when there is and isn't a connection.  The NetCheck.exe should return immediately, (well, it does from a normal CLI), I wonder if it's possible to try running with the RunAs command, (sorry, no experience with that - perhaps SJ can help)?
-4wd (December 20, 2010, 05:32 PM)

I was running as adminstrator on the local machine.


Now if you put the wrong WEP key in your WiFi card and let it partially connect, DHCP should fail leaving you with an APIPA address and roughly the state you need to test with/for/on.

nope wep key was correct because I could connect to the internet and network once it finally did connected.


Running it on logoff isn't really the issue, because the WiFi card stays on. The trick is to get it to run on wakeup from sleep/hibernation when the connection has dropped because the WiFi card was napping.

I try to remeber to turn off the option to let windows disable the nic to save power, because I know this is an issue on problems like I am describing.  But I didn't check for sure to see if I did disable it.

I won't be back over in that building until later tomorrow.  i will try the latest netcheck at that time
Title: Re: IDEA: Wireless sensor
Post by: 4wd on December 20, 2010, 11:19 PM
I have joined my domain but now it takes forever to "run the startup script".  Like 5 or 6 minutes.
-techidave (December 20, 2010, 07:58 AM)

Here it only takes a few seconds to run it, the tooltip shows up after the login screen, however it looks like you're using the 'classic' login screen and not the newer XP Welcome type - something that I ought to of thought of but didn't  :-[    So a bit more testing.
-4wd (December 20, 2010, 05:32 PM)

Does 5 or 6 minutes sound about right for the WiFi card init? I'm wondering if the script is waiting for the program to return. If the ping is every 5 sec, can you (just as a test value) add a sending ping X message to the prog so it's "pulse" can be checked?
-Stoic Joker (December 20, 2010, 10:02 PM)

The script doesn't send any pings, it just tries to open a connection to a server, (any type of server, just need an IP and port), if it can't make one within 100ms, (default value), then it fails and the script continues.  So in theory, it's not actually waiting for anything to come back unless its connection is accepted in which case the script will continue to progress in under the 100ms wait time.  I could make the 5 second delay between connection attempts shorter, (I didn't want it to get flagged by any security programs as excessive pings sometimes do), or configuable - if I took out the delay then it would attempt connections every 100ms or less.

I guess I can do that as a test case.

EDIT:  Actually, I guess that is 'ping like' in its behaviour.

Caveat: Currently it doesn't reinitialise itself to display on the logon screen if the current user logs off - that's about it.  I'm still looking at fixing this by calling it again, (probably needs higher privileges so it can display on the logon screen again).
-4wd (December 19, 2010, 10:43 PM)

Running it on logoff isn't really the issue, because the WiFi card stays on. The trick is to get it to run on wakeup from sleep/hibernation when the connection has dropped because the WiFi card was napping.

Well, it kinda is at the moment because the instance running from the Startup script event terminates on detection of 'explorer.exe' process.  And the instance running at Logon event is terminated when the 'explorer.exe' process terminates.

So when it drops back to the logon screen, there is no NetCheck program running - this is why I would like to run it as a service if I could get the damn thing to interact with the display  :mad:
Title: Re: IDEA: Wireless sensor
Post by: techidave on December 21, 2010, 04:41 AM
I could also change the server IP to one of my internal servers and see if that makes a difference.
Title: Re: IDEA: Wireless sensor
Post by: Stoic Joker on December 21, 2010, 08:37 AM
The script doesn't send any pings, it just tries to open a connection to a server, (any type of server, just need an IP and port), if it can't make one within 100ms, (default value), then it fails and the script continues.  So in theory, it's not actually waiting for anything to come back unless its connection is accepted in which case the script will continue to progress in under the 100ms wait time.  I could make the 5 second delay between connection attempts shorter, (I didn't want it to get flagged by any security programs as excessive pings sometimes do), or configuable - if I took out the delay then it would attempt connections every 100ms or less.
-4wd (December 20, 2010, 11:19 PM)

Ah! (Port Connection) ...Therein lying the gotcha I mentioned at the beginning.Port Connection's do a 3-way handshake:
SYN (outbount request)
SYN-ACK (target response)
ACK (outbound acceptance)

Slamming the socket shut without the SYN-ACK requires a non-blocking raw socket connection that creates its own thread and uses select(...) to check for writability before timingout and slamming shut... (Which still isn't 100% reliable after XP SP2...) ...otherwise the default timeout (graceful closure) is in the 3-5 min range.

That's why I'd suggested using something strictly local for the initial (test) loop like a system call level iteration of the adapter statuses. While not directly related (it only pulls address info from the first adapter it finds - but you could loop it to get the others), here's an example of the type of function you would need:
Code: C++ [Select]
  1. //===========================================================================================
  2. //============================================================================================
  3. BOOL GetLocalIPAddressRange(SCAN_IP_STRUCT *lpsIP) {
  4.         char szLocalHost[MIN_BUFF] = {0};
  5.         char szNetMask[MIN_BUFF] = {0};
  6.         PIP_ADAPTER_INFO pAdapterInfo;
  7.  
  8.   pAdapterInfo = (IP_ADAPTER_INFO *) malloc(sizeof(IP_ADAPTER_INFO));
  9.   ULONG ulOutBufLen = sizeof(IP_ADAPTER_INFO);
  10.  
  11.    // Make an initial call to GetAdaptersInfo to get
  12.   // the necessary size into the ulOutBufLen variable
  13.   if(GetAdaptersInfo(pAdapterInfo, &ulOutBufLen) == ERROR_BUFFER_OVERFLOW) {
  14.           free(pAdapterInfo);
  15.           pAdapterInfo = (IP_ADAPTER_INFO *) malloc (ulOutBufLen);
  16.   }
  17.  
  18.   if(GetAdaptersInfo(pAdapterInfo, &ulOutBufLen) == NO_ERROR) {
  19.           if(pAdapterInfo) { // Grab the First Adapter we "See", and Run with it.
  20. //                MessageBox(lpsIP->hList, pAdapter->Description, "Adapter Description", MB_OK); // Dev Mgr Name
  21. //                MessageBox(lpsIP->hList, pAdapter->AdapterName, "Adapter Name", MB_OK); // Class ID
  22.                   StringCbCopy(szLocalHost, MIN_BUFF, pAdapterInfo->IpAddressList.IpAddress.String);
  23.                   StringCbCopy(szNetMask, MIN_BUFF, pAdapterInfo->IpAddressList.IpMask.String);
  24.                   free(pAdapterInfo);
  25.           }else{
  26.                   return FALSE;
  27.           }
  28.   }
  29.  
  30.   //----------------------------------------------------------------------------->
  31.   u_long host_addr = inet_addr(szLocalHost); //-+-//-//> Local IP Address
  32.   u_long net_mask = inet_addr(szNetMask);   //-+-//-//-> LAN (Sub)NetMask
  33.   u_long net_addr = host_addr & net_mask;  //-+-//-//+-+-+-+-+-> 192.168.5.0
  34.   u_long bcast_addr = net_addr | (~net_mask);  //-//-+-+-+-+-+-> 192.168.5.255
  35.   net_addr = ntohl(net_addr);  //-+-// Convert Network Addy to Network Byte Order,
  36.   bcast_addr = ntohl(bcast_addr);  // Convert Broadcast Addy to Network Byte Order
  37.                                  //-//-+-+-+-//-+-//-+-//-+-//-//-+-+-+-+-+->
  38.   net_addr +=1; //-//-+-> Add 1 to Get from Network Address to First IP in Subnet,
  39.   bcast_addr -=1; // Subtract 1 to Get from Broadcast Address to Last IP in Subnet
  40.                           //-//-+-+-+-//-+-//-+-//-+-//-//-+-+-+-+-+->
  41.   net_addr = htonl(net_addr); //-+-// Convert Network Addy Back to Host Byte Order,
  42.   bcast_addr = htonl(bcast_addr); // Convert Broadcast Addy Back to Host Byte Order
  43.   //----------------------------------------------------------------------------->
  44.   strcpy_s(lpsIP->szStartIP, MIN_BUFF, inet_ntoa(*((struct in_addr *)&net_addr)));
  45.   strcpy_s(lpsIP->szEndIP, MIN_BUFF, inet_ntoa(*((struct in_addr *)&bcast_addr)));
  46.   strcpy_s(lpsIP->szNetMask, MIN_BUFF, szNetMask);
  47.   //----------------------------------------------------------------------------->
  48.  return TRUE;
  49. }

Note: that is actually the code that Page Countster uses to get the default LM IP address range for the Scan for Printers dialog box.



Caveat: Currently it doesn't reinitialise itself to display on the logon screen if the current user logs off - that's about it.  I'm still looking at fixing this by calling it again, (probably needs higher privileges so it can display on the logon screen again).
-4wd (December 19, 2010, 10:43 PM)

Running it on logoff isn't really the issue, because the WiFi card stays on. The trick is to get it to run on wakeup from sleep/hibernation when the connection has dropped because the WiFi card was napping.
-Stoic Joker

Well, it kinda is at the moment because the instance running from the Startup script event terminates on detection of 'explorer.exe' process.  And the instance running at Logon event is terminated when the 'explorer.exe' process terminates.

So when it drops back to the logon screen, there is no NetCheck program running - this is why I would like to run it as a service if I could get the damn thing to interact with the display  :mad:
-4wd

Damn, that is a sticky one. Apparently "Allow service to interact with desktop" was depricated a while back due to the need for more complete Session 0 isolation - which quickly sinks out-of-my-depth (f0dder...?) - So the new more correct(er) way is to use two applications that pitch-N-catch. The service does the test & pitch, and the User GUI does the catch & display.

Maybe use WMI to look for (signs of life) a wake event?
Title: Re: IDEA: Wireless sensor
Post by: 4wd on December 21, 2010, 05:38 PM
The script doesn't send any pings, it just tries to open a connection to a server, (any type of server, just need an IP and port), if it can't make one within 100ms, (default value), then it fails and the script continues.  So in theory, it's not actually waiting for anything to come back unless its connection is accepted in which case the script will continue to progress in under the 100ms wait time.  I could make the 5 second delay between connection attempts shorter, (I didn't want it to get flagged by any security programs as excessive pings sometimes do), or configuable - if I took out the delay then it would attempt connections every 100ms or less.
-4wd (December 20, 2010, 11:19 PM)

Ah! (Port Connection) ...Therein lying the gotcha I mentioned at the beginning.Port Connection's do a 3-way handshake:
SYN (outbount request)
SYN-ACK (target response)
ACK (outbound acceptance)

Slamming the socket shut without the SYN-ACK requires a non-blocking raw socket connection that creates its own thread and uses select(...) to check for writability before timingout and slamming shut... (Which still isn't 100% reliable after XP SP2...) ...otherwise the default timeout (graceful closure) is in the 3-5 min range.
-Stoic Joker (December 21, 2010, 08:37 AM)

I guess that explains the delay for techidave then, changing the timeout value and/or choosing a local server should ameliorate that?

Also, maybe AVG needs to told that the program is allowed Raw Socket access?

That's why I'd suggested using something strictly local for the initial (test) loop like a system call level iteration of the adapter statuses. While not directly related (it only pulls address info from the first adapter it finds - but you could loop it to get the others), here's an example of the type of function you would need:
Code: C++ [Select]
  1. .....

Note: that is actually the code that Page Countster uses to get the default LM IP address range for the Scan for Printers dialog box.

I can almost understand C++, (only written one very short program in C on the Amiga), but AutoIt has a WiFi UDF that has a lot of functions so I'll see if I can get a status check out of them.

Well, it kinda is at the moment because the instance running from the Startup script event terminates on detection of 'explorer.exe' process.  And the instance running at Logon event is terminated when the 'explorer.exe' process terminates.

So when it drops back to the logon screen, there is no NetCheck program running - this is why I would like to run it as a service if I could get the damn thing to interact with the display  :mad:
-4wd

Damn, that is a sticky one. Apparently "Allow service to interact with desktop" was depricated a while back due to the need for more complete Session 0 isolation - which quickly sinks out-of-my-depth (f0dder...?) - So the new more correct(er) way is to use two applications that pitch-N-catch. The service does the test & pitch, and the User GUI does the catch & display.

Maybe use WMI to look for (signs of life) a wake event?

That's a good idea, thanks.

I did have the connection check part running as a service, (it was just writing an empty file which another program checked for - existance depending on connection), and it worked.  Except I still couldn't get it to work after a logoff, (so it would redisplay on the logon screen again), anything I launched at the logoff inherited the users permissions and was killed on logoff, (just thought of one more idea), and anything I tried to launch when the logon screen was up just didn't interact any more.

Maybe I'll try just putting the program run at Startup to sleep when a logon event is detected and wake it up at a logoff event and see what happens.

Argh!  Windows!
Title: Re: IDEA: Wireless sensor
Post by: techidave on December 21, 2010, 05:50 PM
I did exclude the netcheck folder for AVG.  Also added the files in the windows/system32/... too.  I appreciate all your hard work on this guys!   :Thmbsup: :Thmbsup:

Title: Re: IDEA: Wireless sensor
Post by: 4wd on December 22, 2010, 02:28 AM
@techidave: Haven't forgotten you but don't expect anything before Christmas.

Just a question at the moment:

Is connection only going to be via WiFi, (I might script in wired later but I'm trying to get one thing reliably working) ?
Title: Re: IDEA: Wireless sensor
Post by: techidave on December 22, 2010, 05:42 AM
Oh, I am not expecting anything before Christmas.  Don't worry about that part.  I am just glad that someone has decided to do this. 

The only time these laptops will connect via cable is when I plug them in to image them.  The students will always connect via wifi.

Does a wired connection really need anything like this?  I do not know, I am just asking.   :D :o
Title: Re: IDEA: Wireless sensor
Post by: 4wd on December 22, 2010, 06:08 AM
Does a wired connection really need anything like this?  I do not know, I am just asking.   :D :o
-techidave (December 22, 2010, 05:42 AM)

Actually it doesn't, the routine I'm going to try doesn't seem to differentiate between the two types, (well here it doesn't), and it should be friendlier that what I was using previously since it just interrogates Windows itself.

I've attached a simple executable that says Connected or Not Connected if you want to try it - if it works OK I'll incorporate it into a service.  Just run from the command line both when you have and haven't a WiFi connection.
Title: Re: IDEA: Wireless sensor
Post by: 4wd on January 04, 2011, 06:29 AM
Just to let you know what's happening:

1) Got a service that works and reports whether there's a connection or not, (just by setting/deleting a file - lo-tech approach but it works).
2) I can display the status on the initial logon screen.
3) I can display the status in the SysTray after logon.

The one thing that's screwing everything up is displaying something on the logon screen again after someone has logged off - Windows kills any program that's already running when the user logs off.

There's only one more thing I can try and that's setting a Scheduled Task to run at the next minute after logoff by calling the AT command, (or directly entering into the Task list), this way it should run as LOCAL SYSTEM account.

If that doesn't work then I'm fresh out of ideas and it'll be over to someone with more knowledge of Windows than I've got, (which wouldn't be hard).
Title: Re: IDEA: Wireless sensor
Post by: Stoic Joker on January 04, 2011, 06:49 AM
(Long-Shot> IIRC... the logon screen uses the HKEY_USERS\.DEFAULT profile...Which also has a subkey entry for Software\Microsoft\Current Version\Run

I've used this key/profile decription in the past to enable num-lock on the logon screen, so it could be worth a shot to try running/launching it from there.
Title: Re: IDEA: Wireless sensor
Post by: 4wd on January 04, 2011, 07:25 AM
Thanks SJ, I'll give that a go first as it's easier to do than fool around with Scheduled Tasks.


Addendum:  That didn't seem to work, (no output to a logfile or any other indication it ran), so it's back to the Scheduled Task idea.
Title: Re: IDEA: Wireless sensor
Post by: Stoic Joker on January 09, 2011, 09:05 AM
Okay, this is either the right answer, or the stupidest thing I've ever said...I'm not sure which (be gentile).

But, I ran across this: Displaying server/domain name on the logon screen. (http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2general/thread/aefaceb3-8ab1-4290-a812-cda3dcd5f08b)

So if the service is creating a plain text file, why not have it create an .htm file, and set the logon screen's wallpaper to that. Assuming the page could be made to auto-refresh and display status changes it could work.
Title: Re: IDEA: Wireless sensor
Post by: Ath on January 09, 2011, 09:47 AM
I've used this key/profile decription in the past to enable num-lock on the logon screen, so it could be worth a shot to try running/launching it from there.
-Stoic Joker (January 04, 2011, 06:49 AM)
That was on Windows NT, and for newly created accounts only, from W2K on it (sort of) remembered the last state of num-lock
Title: Re: IDEA: Wireless sensor
Post by: 4wd on January 09, 2011, 10:52 AM
Okay, this is either the right answer, or the stupidest thing I've ever said...I'm not sure which (be gentile).

But, I ran across this: Displaying server/domain name on the logon screen. (http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2general/thread/aefaceb3-8ab1-4290-a812-cda3dcd5f08b)
-Stoic Joker (January 09, 2011, 09:05 AM)

A quick peruse of the thread seemed to indicate that someone wanted the same thing, (dynamically updated logon background), but there didn't seem to be an answer.  I'll have a more indepth peruse when I'm fully awake later today, (0334 here currently).

So if the service is creating a plain text file, why not have it create an .htm file, and set the logon screen's wallpaper to that. Assuming the page could be made to auto-refresh and display status changes it could work.

Is it possible to do that on XP, (have a webpage as a background on the logon screen) ?

I think Active Desktop provides this while a user is logged on, (not that I've ever used it), but from what I've looked at so far, the logon screen appears to be completely static with the exception of being able to put some text on it, the LegalNoticeText, which is also static.

I'm frankly amazed I was able to display something on top of it at the initial appearance, considering nothing I've tried following a user logoff seems to work - even when run as LOCAL SYSTEM using the AT command.
Title: Re: IDEA: Wireless sensor
Post by: Stoic Joker on January 09, 2011, 10:53 AM
I've used this key/profile decription in the past to enable num-lock on the logon screen, so it could be worth a shot to try running/launching it from there.
-Stoic Joker (January 04, 2011, 06:49 AM)
That was on Windows NT, and for newly created accounts only, from W2K on it (sort of) remembered the last state of num-lock
-Ath (January 09, 2011, 09:47 AM)
I never actually played with NT4 much, so I can't say much there. But I do recall using that trick on an XP machine for a client that had an alphanumeric password and couldn't remember to hit numlock.

Also MS still has a KB article for it: How do I enable the NUM LOCK key for the logon screen? (http://support.microsoft.com/kb/154529)
Title: Re: IDEA: Wireless sensor
Post by: Stoic Joker on January 09, 2011, 11:00 AM
Is it possible to do that on XP, (have a webpage as a background on the logon screen) ?
-4wd (January 09, 2011, 10:52 AM)

The gist of the thread seemed to be that it would/did work before (with older OSs), but the OP was having trouble getting it to work on Server08 R2. So I'm hoping that doing it on XP wont be a wild goose chase.
Title: Re: IDEA: Wireless sensor
Post by: 4wd on January 09, 2011, 11:07 AM
Is it possible to do that on XP, (have a webpage as a background on the logon screen) ?
-4wd (January 09, 2011, 10:52 AM)

The gist of the thread seemed to be that it would/did work before (with older OSs), but the OP was having trouble getting it to work on Server08 R2. So I'm hoping that doing it on XP wont be a wild goose chase.
-Stoic Joker (January 09, 2011, 11:00 AM)

I might have a look at bginfo, (and it's forums), then and see if anyone has run across/solved the same problem.

Thanks again.
Title: Re: IDEA: Wireless sensor
Post by: 4wd on January 17, 2011, 03:44 AM
OK, I'm going to have to call 'uncle' on this.

I still cannot get the damn tooltip to reappear on the Windows logon screen after someone has logged off without the computer having to be restarted.

So despite all the help from SJ, (thanks again), the best I can still come up with is a tooltip on the initial Windows logon screen and a SysTray icon that'll appear whenever anyone logs in, (at least that part worked).

Here's my code so far, there's no need for a service since I can't get anything to work after a log off anyway.

Code: AutoIt [Select]
  1. #NoTrayIcon
  2. #Region ;**** Directives created by AutoIt3Wrapper_GUI ****
  3. #AutoIt3Wrapper_UseUpx=n
  4. #AutoIt3Wrapper_UseX64=n
  5. #AutoIt3Wrapper_Res_Icon_Add=On.ico
  6. #AutoIt3Wrapper_Res_Icon_Add=Off.ico
  7. #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****
  8.  
  9. Opt("TrayMenuMode", 1)
  10.  
  11. $loggedon = (ProcessExists("explorer.exe") > 0)
  12.  
  13. HotKeySet("^+!\", "_Exit")
  14.  
  15. If $loggedon Then TraySetState()
  16.  
  18.         If (ProcessExists("explorer.exe") > 0 And Not $loggedon) Then ExitLoop
  19.         $ret = DllCall("WinInet.dll","int","InternetGetConnectedState","int_ptr",0,"int",0)
  20.         If $ret[0] then ; Connected
  21.                 If $loggedon Then
  22.                         TraySetIcon(@ScriptName, -5)
  23.                         TraySetToolTip("Network connected")
  24.                 Else
  25.                         ToolTip("Connected", 0, 0,"Network Status", 1, 5)
  26.                 EndIf
  27.         Else            ; Not connected
  28.                 If $loggedon Then
  29.                         TraySetIcon(@ScriptName, -6)
  30.                         TraySetToolTip("Network disconnected!")
  31.                 Else
  32.                         ToolTip("Not Connected", 0, 0,"Network Status", 3, 5)
  33.                 EndIf
  34.         Endif
  35.         Sleep(1000)
  37.  
  38. Func _Exit()
  39.         Exit

Attached is an archive containing the AutoIt3 code, executable and icons (used in the SysTray).

To work out whether there's a network connection all it does is ask Windows every second - this seems to work fine here whether it's wireless or wired.  So it'll know whether it's connected or not as soon as Windows knows (in theory).  It also means it doesn't need to call third party programs or need network access through a firewall.

You can exit the program by the hotkey combo: Control+Shift+Alt+\   (That should avoid any clashes :) )
Or just kill it in Task Manager.

Set it up in the Group Policy editor as in this post (https://www.donationcoder.com/forum/index.php?topic=24905.msg227737#msg227737) EXCEPT when it comes to the User Logon script entry, it needs no parameters.

It needs no config file since the only thing configurable would be the hotkey, the executable is the only file required and can be copied to the same places as mentioned in the post (https://www.donationcoder.com/forum/index.php?topic=24905.msg227737#msg227737).

Sorry I couldn't give you exactly what you wanted techidave, I'm actually still surprised that Windows allowed me to put anything on the initial logon screen.

It's going to take the likes of mouser or f0dder to solve this problem :P
Title: Re: IDEA: Wireless sensor
Post by: techidave on January 17, 2011, 07:06 AM
Thanks for trying 4wd.  I know you gave it your all!  Thanks to Stoic Joker for all his input too!  Perhaps in the future it will be possible.  :)
Title: Re: IDEA: Wireless sensor
Post by: Stoic Joker on January 31, 2011, 07:13 PM
While not entirely the answer, I just ran across a very interesting structure (while researching something else (semi related)) in the VS2k5 Platform SDK:

Code: C++ [Select]
  1. DWORD GetIfEntry(
  2.   PMIB_IFROW pIfRow
  3. );

One of the members of the MIB_IFROW structure is dwOperStatus, which has these possible values:
ValueMeaning
MIB_IF_OPER_STATUS_NON_OPERATIONAL LAN adapter has been disabled, for example because of an address conflict.
MIB_IF_OPER_STATUS_UNREACHABLE WAN adapter that is not connected.
MIB_IF_OPER_STATUS_DISCONNECTED For LAN adapters: network cable disconnected. For WAN adapters: no carrier.
MIB_IF_OPER_STATUS_CONNECTING WAN adapter that is in the process of connecting.
MIB_IF_OPER_STATUS_CONNECTED WAN adapter that is connected to a remote peer.
MIB_IF_OPER_STATUS_OPERATIONAL Default status for LAN adapters
 
 
I know there were other issues, but this looked handy enough to make a note of for future reference.