Looking for Help With a Crazy PC Problem

Equipment Troubleshooting Help Needed
11 replies•323 views
John Hayes avatar
John Hayes avatar
I try pretty hard to solve my own technical problems but I've hit my limit with this one and I'd be grateful if someone here can help to solve a strange PC problem.  I am simply trying to connect my PC through a network cable to an IP power switch so that I can control the switch directly from the PC.  When I set up my 20" scope, this worked perfectly but I ran into a brick wall trying to do the same thing with identical equipment on my GTX130 system.  The attached diagrams show the basics of what I've tried.

Here are some of the things that I've tried:
1) Turned off all Win10 firewalls.  There is no anti-virus software (such as McAfee, Norton, etc.) on this system.
2) Updated Win10 to the latest version.
3) I've used the Win10 network trouble-shooter to address a number of minor issues such as "Local connection does not have valid IP configuration".
4) I've tried connecting to every network connector on the PC and none will connect.
5) I loaded the very latest network device drivers for my system directly from the Intel site.
6) I've swapped cables until I'm blue in the face.  They are good!
7) This network switch easily connects to the PC2 in the 20" system but not with the identical PC that I have for the AP130GTX system.  This implies that the switch is working fine.

All of this convinced me that the network chip on the motherboard must have a problem so I had a new motherboard installed in the PC.  The "repaired" PC1 communicates fine over a wired network connection with a router, which implies that the network chip is working fine, but it still will not connect to the IP switch!

The only thing that is common between the original PC1 and the "repaired" PC1 is the SSD.  I am running exactly the same code, which makes me believe that the problem has to be a software setting.  But if that's the case, why does the PC communicate with a router and not the switch?  PC2 is now in Chile or I'd try swapping disks but that option is no longer possible.

I'm almost bald from tearing my hair out over this problem so let me know if you have any ideas.  My PC Genius award will go to the first person who can provide a solution to this problem!

Thanks!
John




Björn Arnold avatar
Björn Arnold avatar
Hi John,

A few simple thoughts on this:
1. Maybe PC2 has a static IP-Adress and PC1 doesn't. Hence, if PC1 isn't in the same subnet as the IP-Switch it won't be able to route the packages to the IP-Switch. If you connect PC1 to a router, you might get a IP-adress for PC1 from the router (via DHCP).

2. Does your IP-Switch somehow manage who may connect to it? Maybe there is a MAC-filter active somewhere that only white-lists known devices and PC1 isn't one of them?

Björn
David Goldstein avatar
David Goldstein avatar
Two basic things come to mind.  Confirming the iP addresses of your endpoints and the subnet address being used to mask these addresses.

The router will talk to you I am guessing because he is a gateway within your subnet.  However, if the IP on the IP switch is other than the one you are in, it could cause this problem.

I would assume in this example that you are talking about 255.255.255.0 or a /24 mask for all devices in this 192.168.1.0 network.

David
John Hayes avatar
John Hayes avatar
Bjorn and David,
Thanks for your thoughts on this problem!  I can talk to you guys all day about optics but I know less than zero about networks.  Can you tell me specifically how to test your suggestions?  I don't know what a gateway is within a subnet address.  I don't know what a MAC filter is or what it does.  I don't know how to confirm IP addresses  (other than to read it on the screen of the IP Switch).  However, I do know that all of the PCs involved are configured to use a dynamically assigned IP address.  This is why I'm so lost on this issue.  When it doesn't work, I have very little knowledge about where to even begin to look for the problem or how to diagnose it!

Again, if you can give me something specific to try or to reset, that's something that I can handle.

John
John Hayes avatar
John Hayes avatar
OK...never mind!

Out of the blue, I figured it out.  I went into the network adapter properties and changed the IPV4 options to use a static IP address and BINGO...it worked!  Don't mistake this stroke of luck to mean that I knew what I was doing.   I was reading through the IP switch manual and this was a suggestion for when this problem occurs.  Lesson learned:  READ THE MANUAL AND PAY ATTENTION!   I missed it on my first pass.  Sheeze!

Thanks again you guys.

John
David Goldstein avatar
David Goldstein avatar
John Hayes:
OK...never mind!

Out of the blue, I figured it out.  I went into the adapter properties and changed the IPV4 options to use a static IP address and BINGO...it worked!  Don't mistake this stroke of luck to mean that I knew what I was doing.   I was reading through the IP switch manual and this was a suggestion for when this problem occurs.  Lesson learned:  READ THE MANUAL AND PAY ATTENTION!   I missed it on my first pass.  Sheeze!

Thanks again you guys.

John

Glad you found the resolution.  I was thinking about DHCP, which assigns available IPs out of a given block to devices in a subnet.  In this case, it sounds like the IP switch has a fixed address.

At any rate, glad it is fixed.  

David
Björn Arnold avatar
Björn Arnold avatar
Hi John,

I'm glad you could fix the problem. Don't worry, not reading the manual is something we're all caught by from time to time smile

I have two suggestions:
1. Always use static IP-addresses in a network with known devices. It makes the network more robust and more easy to trouble shoot.
2. I recommend to get someone with good network knowledge. An ill-configures network might pose a significant security risk.

Good luck and clear skies with your scope in Chile (from your initial post, I'm assuming that your equipment is about to startup soon?)

Björn

PS: I don't want to leave my initial post without a brief explanation because it'll probably cause questions for others as well. 

Roughly speaking, a MAC address is the very basic identifier of a participant in a network that follows the Ethernet protocol/standard. Normally a device can be identified through its MAC address and therefore, network controllers can be configured to allow (white list) or deny (black list) access to the network through this identifier. (there are caveats and details but it gives the basic picture).
MAC addresses are usually configured from the vendor of the network adapter and never changed (through home users).

IP-addresses are part of the Internet Protocol (that's what IP actually stands for) and are the protocol's own identifiers to identify communication participants. IP runs on top of other protocols like Ethernet. To get an IP-address, there are two options: the user enters one manually (static) but has to take care not to assign an IP that's already in use or get an IP-address from a DHCP server (which usually runs in every internet router). The DHCP takes care of not assigning an IP twice. However, it has the effect that you usually don't know the IP-address of your device until you look it up. If there is no static IP-address configured and no DHCP server in the network, the adapter will fall back to a standard IP which usually won't allow you finding any other network participant. (Point 1 in my initial reply).

(Hopefully, I haven't raised more confusion).
Michel Makhlouta avatar
Michel Makhlouta avatar
Hi John,
Static IPs are a good solution, but not manageable if you scale up someday. Your linksys is your DHCP server, responsible for distributing IP addresses. Your Subnet is 192.168.1.1/255.255.255.0 whch means all IP addresses it gives are between 192.168.1.2 to 192.168.1.254. From that subnet, you cannot reach 192.168.0.100 which is your data logger switch.

You can simply change the LAN settings on the linksys to 192.168.0.1 instead of 192.168.1.1 or you can change the switch ip to the 192.168.1.1/255.255.255.0 subnet.

Also it's best to avoid direct pc to pc cables, and get everything connected to where your DHCP server is (linksys). If it doesn't have enough port, a small 8 port switch is a cheap upgrade to give you more ports.

Nice flowchart by the way, you're every IT support's dream smile
Ruediger avatar
Ruediger avatar
Michel Makhlouta:
Static IPs are a good solution, but not manageable if you scale up someday.


Hi Michel,

Please allow me to disagree to some extend. Here my 2 cents.

For all mission critical infrastructures static IP is the way to go, since if the DHCP server has an error all your devices suffer from that problem after some time when the leases must be renewed. Moreover static IP allows you much easier to define the appropriate firewall rules and are often only possible with static IPs. What is also critical, if you want to interact with dedicated devices, you have to implement dynamic DNS in DHCP managed subsets, in order to address machines by their names, since you do not know which IP address is assigned at that moment by the DHCP server.

Next nasty point is, if the DCHP server is not available, some OS start to self-asign wild IP addresses. This turns your remote machines (e.g.Windows) very quickly unreachable.Moreover the sequence of device boot after a power failure or planed reset is essential. The DHCP must be and running first, before the clients are booting.

Also Windows has the nasty habit to identify the network type as "home", "public" and "work". This is very error prone and not reliable, esp. in DHCP controlled environment. In the moment Windows flips to "public" the according firewall rules get applied and definitely will cut off any remote control protocols, which is definitely not the best what can happen on remote sites....

A DHCP server is a single point of failure, as long you do not have a fail over or a defined fall back. You can mitigate the risk by statically assigned DHCP leases, but this makes things even more complicated and for small nets you end up at the same effort as with static addresses, but more risks.

Hence I recommend very strongly NOT to use DHCP in any of the remote controlled sites. Of course it is required to have a good plan and requires some basic knowledge, but DHCP is definitely a very bad idea.

Best practice in professional, critical environment is to have static IP addresses for infrastructure devices. Uncritical and not needed clients may use DHCP. This approach makes things much more robust, error resistant and manageable e.g. by maintaining a "host" file.Also we are talking about a very small subnet.

For my point of view, John is on the right track, because he runs it remotely and needs a fail safe and robust network setup.

Cheers
Rüdiger
Michel Makhlouta avatar
Michel Makhlouta avatar
Ruediger:
Michel Makhlouta:
Static IPs are a good solution, but not manageable if you scale up someday.


Hi Michel,

Please allow me to disagree to some extend. Here my 2 cents.

For all mission critical infrastructures static IP is the way to go, since if the DHCP server has an error all your devices suffer from that problem after some time when the leases must be renewed. Moreover static IP allows you much easier to define the appropriate firewall rules and are often only possible with static IPs. What is also critical, if you want to interact with dedicated devices, you have to implement dynamic DNS in DHCP managed subsets, in order to address machines by their names, since you do not know which IP address is assigned at that moment by the DHCP server.

Next nasty point is, if the DCHP server is not available, some OS start to self-asign wild IP addresses. This turns your remote machines (e.g.Windows) very quickly unreachable.Moreover the sequence of device boot after a power failure or plant reset is essential. The DHCP must be and running first, before the clients are booting.

Also Windows has the nasty habit to identify the network type as "home", "public" and "work". This is very error prone and not reliable, esp. in DHCP controlled environment. In the moment Windows flips to "public" the according firewall rules get applied and definitely will cut off any remote control protocols, which is definitely not the best what can happen on remote sites....

A DHCP server is a single point of failure, as long you do not have a fail over or a defined fall back. You can mitigate the risk by statically assigned DHCP leases, but this makes things even more complicated and for small nets you end up at the same effort as with static addresses, but more risks.

Hence I recommend very strongly NOT to use DHCP in any of the remote controlled sites. Of course it is required to have a good plan and requires some basic knowledge, but DHCP is definitely a very bad idea.

Best practice in professional, critical environment is to have static IP addresses for infrastructure devices. Uncritical and not needed clients may use DHCP. This approach makes things much more robust, error resistant and manageable e.g. by maintaining a "host" file.Also we are talking about a very small subnet.

For my point of view, John is on the right track, because he runs it remotely and needs fails safe and robust network setup.

Cheers
Rüdiger

Hi Rudiger,
All are valid points, and I don't disagree. I did not consider this to be a remote observatory. If I am using something mission critical, I wouldn't use a linksys wireless router, I would setup two small firewalls (pfsense, opnsene, ...) in high availability setup, setup everything with wake on lan, etc... but that's for another discussion. In all cases, DHCP and his network are running on a different subnet than the switch. I would assume this is his problem.

He also needs to set his DHCP range currently running outside of the static IPs to avoid conflicts.

Regards,
Michel
Ruediger avatar
Ruediger avatar
Hi Michel.

totally agreed. There are some checks and configurations to be done on the current config. But I think it is important to keep the complexity as low as possible. Also agreed on that Linksys would also not be my choice. It is definitely a week point I'd feel very uncomfortable about. But on the other hand: All serious router / switches need profound knowledge to setup - and the more options, the more can go wrong. So keep it simple.

CS
Rüdiger
John Hayes avatar
John Hayes avatar
Thanks for the discussion 
Michel Makhlouta:
Hi John,
Static IPs are a good solution, but not manageable if you scale up someday. Your linksys is your DHCP server, responsible for distributing IP addresses. Your Subnet is 192.168.1.1/255.255.255.0 whch means all IP addresses it gives are between 192.168.1.2 to 192.168.1.254. From that subnet, you cannot reach 192.168.0.100 which is your data logger switch.

You can simply change the LAN settings on the linksys to 192.168.0.1 instead of 192.168.1.1 or you can change the switch ip to the 192.168.1.1/255.255.255.0 subnet.

Also it's best to avoid direct pc to pc cables, and get everything connected to where your DHCP server is (linksys). If it doesn't have enough port, a small 8 port switch is a cheap upgrade to give you more ports.

Nice flowchart by the way, you're every IT support's dream

Thanks Michel!  That makes sense; however, the linksys was only used to test the network connection.  It was never used to connect to the switch (as shown in the diagram.)  Regardless, your explanation is helpful.  The thing that threw me completely off is the fact that I've never configured any of this stuff on PC2.  It simply connected, first try.  Either way, this connection is for nothing more than being able to access the switch remotely through the PC, which isn't on a wired network.  My control box (which contains the switch, PC, and power supplies) runs my scope in the driveway and having this connection makes it easy to access the switch from inside through Chrome Desktop.

John


PS. Thanks also to Ruediger and Bjorn for your thoughts as well!  It's nice to learn more about this stuff.
Related discussions
Exposure Failure on ASIAIR Plus
Im curious what equipment people are powering through their ASIAIR? I bought an ASIAIR Plus and set it up with my AM5/2600MC Pro and 270mm guide camera. I was getting Exposure failure messages on ASIAIR and I could here the fan knocking on and off (i...
Discusses powering equipment through ASIAIR, relevant to network-connected power control setup.
Aug 6, 2023