DonationCoder.com Software > Post New Requests Here
IDEA: Wireless sensor
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)
--- End quote ---
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)
--- End quote ---
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:
--- End quote ---
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)
--- End quote ---
Relaunch with logoff script?
--- End quote ---
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)
--- End quote ---
[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)
--- End quote ---
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.
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)
--- End quote ---
[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)
--- End quote ---
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.
--- End quote ---
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.
--- End quote ---
...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).
--- ---#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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version