Joe's guide to testing network connections:
- Figure out which port you're trying to connect to.
- Make sure the port's open (netstat in unix, I have no idea in windows)
- Connect to the port from the target machine on loopback
- Connect to the port, from the target machine, on the external ip
- Connect to the port from a remote machine, using the target machine's IP address
- Connect to the port from a remote machine, using the FQDN.
- Attempt to use whatever automated scripts, local to the target machine
- Attempt to use whatever automated script from the remote machine.
Based on how far you get before failing, you can get some idea what might be wrong -- - (nothing should fail at this point)
- The daemon's not running, or whatever needs to be listening
- ditto, or it's not listening on loopback (not all do)
- It's not listening on the external IP
- it's firewalled off, or tcp wrapped, etc.
- DNS isn't set up correctly on the remote machine, or the FQDN isn't in DNS
- The script may be flawed, or misconfigured.
- Ditto, but on a different machine.
Some protocols are trickier to pin down, especially if they result in the remote server connecting back to client (eg, FTP in active mode). I have no idea how TieRegistry works, so it may not have these sorts of issues. | [reply] |
netstat comes with Windows too, at least with the Pro line of OSes. Syntax: netstat -a.
| [reply] [d/l] |
Make sure you are opening the registry read only (KEY_READ) ( the default is read-write).
I did this a while back but don't have the example code handy right now. If you posted your code, someone might see something. Also, you are saying it fails but don't tell us what $! and/or $^E contains -- again posting your code will help.
As for remote execution on remote Windows machines
sysinternals
have some tools to do that.
| [reply] |
Hi, my code is based quite heavily on the code provided here. The extra work I have done involves basically dumping this information into a database.
| [reply] |
Depending on what database you're trying to feed, you might want to check out cpan:DBI. That way you let someone else handle all the lowlevel communication stuff.
| [reply] |