IDEA: Wireless sensor

[techidave]

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??? 

[skwire]

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.)?

[techidave]

Yes to both questions. 

[Stoic Joker]

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. }

[techidave]

not sure what your little program means but one school has about 60 laptops that this would need to be done with.

[Stoic Joker]

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.

[techidave]

I may not be following you SJ, but what I need is something that the student can see on the laptop.

[skwire]

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).

[4wd]

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

[skwire]

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.   

[techidave]

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.

[techidave]

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.   

[Stoic Joker]

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.

[4wd]

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  

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.  

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

Addendum: In the meantime, check out CNS 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.

[techidave]

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.   

[techidave]

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.

[4wd]

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 

[Stoic Joker]

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.

Windows Service Template.rar (78.99 kB - downloaded 474 times.)

@4wd - IIRC, all the service will need is the interact with desktop right which is configurable (if need be) in Services.msc

[4wd]

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 

[Stoic Joker]

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 

-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.

[4wd]

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

EDIT2: Argh!  The Tooltip doesn't come back when you log off  

-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.

[techidave]

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.

[Stoic Joker]

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. 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.

[4wd]

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. 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.

[4wd]

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):

IDEA: Wireless sensor

Specify a Windows Startup script as follows:

IDEA: Wireless sensor

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

IDEA: Wireless sensor

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:
IDEA: Wireless sensor

And after log on:
IDEA: Wireless sensor


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.